SchneierのAI脆弱性発見に関する主張、ソフトウェア修正に圧力
Bruce Schneierが11月2日に公開した記事の概要は、驚くべき主張に注目を集めている。過去に記録された重大なソフトウェア脆弱性の3%が、1か月以内に発見されたという。彼のAI Vulnerability Finding投稿から提供された抜粋では、年間およそ10万件の追加発見も予測されている。これらの数値は本稿では未検証だが、文書化された発見結果はすでに、ソフトウェアの修正を担うチームに圧力をかけている。
中心となる対立は、発見速度と修正能力の間にある。セキュリティ上の欠陥を見つけることは、ユーザーを守る機会を生む。同時に作業も生む。誰かが報告を検証し、影響範囲を評価し、修正内容をレビューし、アップデートを提供しなければならない。発見の自動化が、その後に続くすべての意思決定を自動的に加速するわけではない。
Anthropic、Google、Mozillaは有用な比較対象となるが、それぞれの数値は異なる事柄を測定している。各社の公開資料は、より限定的ではあるものの重要な結論を裏付ける。自動化されたセキュリティ研究は実際の発見を生み出している一方、集計手法とその後の結果は精査を要する。開発者と企業の購買担当者にとっての問いは、発見の高速化が露出リスクの低減につながるかどうかだ。
AI Vulnerability Findingの主張が実際に示すもの
見出しの統計値は調査の手がかりであり、世界の重大なソフトウェア欠陥について独立して確立された測定結果ではない。
Schneierの脆弱性発見に関する投稿に関連する提供抜粋では、この数値はコメントとして提示されている。本レビューでは元のページを取得できなかった。そのため、この抜粋からは、誰がその割合を算出したのか、どの記録を数えたのか、報告期間をどう定義したのかは確認できない。
この区別は、主張から責任を持って導ける内容を限定する。印象的な割合が、特定のデータベースを正確に表していても、これまでに発見されたすべてのセキュリティ脆弱性を表しているとは限らない。読者が元の分母をより広い母集団に無意識に置き換えれば、誤解を招くこともある。
発見、開示、データベースへの掲載は異なる出来事である。研究者は、ベンダーが確認する前に非公開で欠陥を特定する場合がある。公開文書は、ソフトウェアアップデートと同時または後に公開される可能性がある。したがって、月間の掲載急増は、基礎となるすべての欠陥がその月に発見されたことを示すものではない。
「記録された歴史全体」という表現には、未解決の境界も加わる。監査可能な計算には、名称が明示されたデータベース、日付付きのスナップショット、一貫した収録基準が必要だ。また、重複レコード、却下された提出、公開後に深刻度が変化した脆弱性についての説明も求められる。
年間予測には別の仮定がある。最近のペースが継続するという仮定だ。元の月間件数が正確だと判明したとしても、この仮定は検証に値する。集中的な研究キャンペーン、公開の滞留、協調的なリリースは、安定した年間ペースを示すことなく一時的な急増を生む可能性がある。
カテゴリの問題もある。抜粋は重大な脆弱性から始まるが、その後はより広くバグと過去の脆弱性総数に言及している。基礎となる計算を確認せずに、これらのカテゴリを交換可能なものとして扱うことはできない。ソフトウェア欠陥、確認済みのセキュリティ脆弱性、重大な脆弱性は、それぞれ異なる母集団を指す。
こうした制限はいずれも、より広い展開の重要性を損なうものではない。むしろ、信頼できる範囲がどこで止まるべきかを示している。擁護可能な論点は、正確に測定された歴史的転換点について裏付けのない主張ではなく、文書化された発見活動とその運用上の影響に関するものだ。
ソーシャル投稿を通じてAI Vulnerability Findingに触れる読者にとって、この区別は有益な洞察を守る。セキュリティチームには、今すぐ自らの能力を検討する理由がある。自分たちの発見・修正プロセスの均衡が崩れつつあるかを調べる前に、未検証の割合を受け入れる必要はない。
Anthropicの報告結果は、重要な境界を伴いつつ規模を示す
Anthropicが公開した数値は大規模な発見という主張を裏付けるが、コメントにある歴史的割合や月間からの外挿を検証するものではない。
Anthropicは10月6日のcyber verification program発表で、4月から7月にかけてパートナー全体で少なくとも12万9,000件の検証済みソフトウェア脆弱性が見つかったと報告した。また、4月から10月にかけてのオープンソーススキャンから、5,500件の検証済み発見を別途報告している。
同社によれば、3万3,000件超の検証済み脆弱性が重大または高深刻度と評価された。これは企業が報告した結果であり、独立して再現された調査ではない。期間とカテゴリも、1か月以内に発見された重大な脆弱性についての提供コメントの主張とは異なる。
Anthropicは重要な制限も開示している。影響に関する報告は33のパートナーから得られた部分的な情報に基づき、組織ごとに異なるトリアージ手法が用いられた。修正済み件数を提供した組織は半数未満だった。そのため同社は、報告された修正率を大幅に不完全なものとして説明している。
これらの境界が重要なのは、異なる測定値が異なる問いに答えるためだ。発見件数は報告された発見のアウトプットを測る。確認済み件数には検証の段階が加わる。修正済み件数はその後の結果を示し、展開の証拠は影響を受けたユーザーが実際に保護を受けたかを扱う。
したがって、競争上の意味合いは限定的にとどめるべきだ。Anthropicは、自社モデルを利用する参加組織からの結果を報告している。Googleの脅威研究者は、より広範な開示と悪用の傾向を調査している。これらの公開資料は補完的な視点を提供するが、どちらも、どのベンダーがより優れたセキュリティ成果をもたらすかを証明する統制比較ではない。
購買担当者にとって、発見件数は結論ではなく議論の出発点となるべきだ。より多くの発見を生むベンダーは、見落とされていた問題を見つけるかもしれない。同時に、特に報告に明確な再現証拠や影響を受けるバージョンの情報が欠けている場合、顧客側のレビュー時間をより多く必要とする可能性もある。
有用な評価では、新たに受理された脆弱性を、既知の問題や重複報告と区別する。また、提案された修正とレビュー済みの修正も分ける必要がある。こうした区別は比較を難しくするが、技術的アウトプットを顧客が担うべき作業へと結び付ける。
専任の大規模なセキュリティスタッフを持たずに重要なソフトウェアを所有する組織には、特に大きな圧力がかかる。発見能力は購入または借用できる。しかし、報告を受け入れ、製品を変更する責任は、元の分析が自動的に届いた場合でも、どこかに残る。
これは、報告された規模から導かれる分析上の含意であり、業界全体の人員配置の結果を測定したものではない。受け取る検証済み報告が増え、レビュー能力が固定されたままであれば、未解決のキューは増大する。正確な割合は、各組織のソフトウェア、ツール、そして安全な変更を加える能力に左右される。
そのため、Anthropicの発表に対する最も有用な追跡調査は完了状況に関するものとなる。受理された発見のうち、サポート対象リリースに到達したものはどれだけあったのか。未解決のままどれほど長く残ったのか。比較可能な回答がなければ、大規模な発見件数は、露出リスクの低減よりも活動量を明確に示すことになる。
ソフトウェア保守者は発見後の作業を引き継ぐ
脆弱なソフトウェアを保守する組織は、報告を保護へと転換する運用上の負担を担う。
NISTが4月15日に発表した脆弱性データベースの変更は、セキュリティ業務を取り巻く情報インフラへの圧力を示している。同機関によれば、脆弱性の提出件数は2020年から2025年の間に263%増加した。処理能力を高めても、ペースには追いつけなかったという。
NISTは、脆弱性情報の公開リポジトリであるNational Vulnerability Databaseにおけるエントリーの拡充方法を変更した。拡充には、深刻度スコアや影響を受ける製品といった詳細の追加が含まれる。改訂されたアプローチでは、選定カテゴリが優先され、他のエントリーは即時の拡充なしに掲載されたままとなる。
同機関は、既知の悪用済み脆弱性、連邦政府内で使用されるソフトウェア、定義済みの重要ソフトウェアを優先した。また、この基準では潜在的に重大なすべての問題を網羅できないことも認めている。この変更は能力上の制約を記録するものであり、AIが根本的な提出件数増加を引き起こしたことを立証するものではない。
より広い意味合いは、増加する発見の流れにはデータベース行の追加以上のものが必要だという点にある。保守者と顧客には、何に注意を向けるべきか判断するための信頼できる文脈が必要となる。文脈が欠けていたり遅れたりすれば、解釈の作業が、自らのシステムを評価する責任をすでに負うチームへ移る可能性がある。
ソフトウェア保守者にとって、信頼できる報告を受け取ることは、その結論を読むだけでは済まない複数の義務を生む。影響を受ける挙動を理解しなければならない。提案された修正は周辺の設計に適合する必要がある。サポート対象バージョンと依存コンポーネントには、それぞれ別個の判断が必要になる場合がある。
企業ユーザーは、さらに一層の解釈を迫られる。脆弱なコンポーネントは、直接保守するのではなく購入する製品の内部に含まれていることがある。どの導入済みバージョンが影響を受けるのか、脆弱な挙動に到達可能なのか、サプライヤーがどの対応をサポートするのかを把握する必要がある。
これらは、すべての組織が同じバックログを経験しているという発見ではなく、運用上の依存関係を示す例である。その重要性は、発見と、脆弱性を修正または低減するプロセスである修復との違いから生じる。報告は、誰かがそれについて情報に基づく判断を下せる場合にのみ価値を持つ。
インセンティブの不一致には注意が必要だ。発見プラットフォームはすぐに発見をアピールできる一方、保守者は慎重なレビューや問題なく完了したアップデートによって得られる可視性の高い評価が少ない。購買者は、報告量と保守品質がセキュリティに対する異なる貢献であることを認識すべきだ。
意思決定がチームをまたぐ場合、共有ドキュメントが有用になる。検索可能なナレッジベースは、技術記録、責任者による判断、裏付けとなる証拠を結び付ける助けになる。調整を支援するが、検証とリリース承認には引き続き適切なエンジニアリングプロセスが必要だ。
実務上の圧力は、技術的であると同時に組織的でもある。発見の高速化は、報告、修正、展開に関する意思決定について、より明確な責任の所在を求める。これらの責任が曖昧なままであれば、正当な発見がより多く流入することで、製品を改善する前に対応プロセスの弱点が露呈する可能性がある。
Mozillaが示す、発見に完全な修復プロセスが必要な理由
Mozillaの説明は、AI支援による発見が出荷済みソフトウェアの変更へ結び付いた具体例を示している。
MozillaのFirefox hardening pipelineに関する報告は、モデルをテスト基盤およびセキュリティバグのライフサイクルに統合した取り組みを説明している。同チームによれば、有用な規模を実現するには、再現可能なテスト、重複検出、トリアージ、追跡、リリース作業が必要だった。Firefox 150でMythos Previewの発見271件を修正したと報告している。
同じアカウントは、データベースの合計値を慎重に扱うべき理由も説明している。Mozilla は、内部で報告された複数のバグを共通の脆弱性識別子にまとめている。そのため、同社の報告するバグ件数は公開識別子の数と直接対応しない。この関係を説明せずにどちらかの集団を数えると、読者を誤解させるおそれがある。
Mozilla はまた、重大なバグと実際に成立する侵害を区別している。多層的なブラウザ設計により、攻撃者は保護境界を越えるために複数の脆弱性を必要とする場合がある。高深刻度の分類は対処すべき問題を示すが、完全な攻撃がすでに構築されたことを意味するものではない。
こうした報告の詳細は、発見件数だけよりも有用なケーススタディとなる。自動化された発見からリリースまでの間に何が起こるのかを、メンテナーが議論していることを示している。また、ユーザーに修正が届く前にモデルの出力が取り込まなければならない組織的知識も浮き彫りにする。
分析上の教訓は、モデルの能力と組織の能力は相互に掛け合わさるということだ。本物の問題を見つけるシステムでも、再現や評価を行う人がいなければ、提供できる保護は限られる。成熟した対応プロセスは、エンジニアが利用できる形で届く証拠から、より大きな効果を得る。
この関係は、調達時の比較も複雑にする。慎重に準備されたプロジェクト環境で評価されるモデルは、ビルドツール、テスト基盤、コードを理解するメンテナーの恩恵を受ける。同じモデルを未知のアプリケーションに向ければ、顧客も同等の結果を得られるとは限らない。
広く再利用されているライブラリに関する仮説的な報告を考えてみよう。初期の証拠は、テスト環境でクラッシュが発生することを示すかもしれない。それでもメンテナーは原因を理解し、影響を受けるバージョンを特定し、提案された修正が根本的な問題に対処しているかを判断する必要がある。
既知の欠陥が再び持ち込まれるのを防ぐ確認であるリグレッションテストは、修正を維持する助けになる。リリース時の告知では、影響を受ける動作を正確に説明する必要がある。その後、下流の利用者には、そのライブラリを組み込む製品に適した更新経路が必要となる。
この仮説的な例は、追加の実世界インシデントを主張するのではなく、ワークフローを説明するものだ。同じ発見が、研究者、ライブラリのメンテナー、製品ベンダー、企業の運用担当者に作業を生じさせる理由を示している。各参加者は、保護に至る経路の異なる部分を管理している。
ここには好循環が生まれる可能性がある。より良い証拠は報告の解釈に費やす時間を減らし、実際の修正により多くの注意を向けられるようにする。レビュー済みの修正と有用なテストは、続く自動分析で利用できる環境を改善し得る。この循環が実現するかどうかは、実装と測定された成果に左右される。
逆の展開もあり得る。整理の不十分な発見は、より強力な報告を解決するために必要な注意力を消費しかねない。重要な区別は、単に人間による研究か自動化された研究かではない。メンテナーが行動する助けとなる証拠か、未解決の調査作業を受け手に移す出力かである。
深刻度ラベルでは検証の隔たりを埋められない
クリティカルというラベル、公開識別子、実際に観測された悪用は、セキュリティ問題の異なる側面を表す。
Common Vulnerability Scoring System（CVSS）は、定義された技術的特性を通じて脆弱性の深刻度を記述するためのフレームワークである。FIRST の深刻度スコアリング仕様では、クリティカルのスコアは 9.0 から 10.0 の間に置かれている。この分類だけで、攻撃者が特定の組織で脆弱性を悪用しているかどうかは確認できない。
同様に、Common Vulnerabilities and Exposures の識別子である CVE は、公開された脆弱性に共通の参照先を与える。それは同一の技術的範囲を測る普遍的な単位ではない。件数は、問題がどのように割り当てられ、表現されるかにも一部依存する。
したがって、元の割合を厳密に評価するには、時点をまたいで一貫したルールが必要となる。分子と分母には、互換性のある対象集団と深刻度の定義を用いなければならない。そうでなければ、計算は正確に見えながら、異質な記録を組み合わせることになる。
同じく重要なのがタイミングの問題である。分子が最近公開された記録を数えるなら、それは公開活動を測っている。これを発見活動と呼ぶには、根本の問題がいつ見つかったかについて追加の証拠が必要だ。報告の遅延によって、これらの出来事は切り離され得る。
Google が 9 月 30 日に公開した開示と悪用に関する分析は、より広い文脈を提供している。研究者らは、2026 年 1 月の開示件数が 5,045 件、8 月には 10,740 件だったと報告した。また、割り当て方針とベンダーの公開サイクルが、生の合計値の解釈を複雑にすると警告している。
研究者らは悪用を別途追跡し、CVSS の分類ではなく独自のリスク評価を用いた。この方法論上の違いは重要である。分析におけるリスク区分を、クリティカルな深刻度スコアと黙って言い換えてはならない。表現が似ていても、異なる分類体系を互換的に扱えるわけではない。
これらの発見は、因果関係の主張に慎重であるべきことを裏付ける。開示件数の増加は AI 利用の拡大と同時に起こり得るが、AI がその増加全体を説明することを立証するものではない。報告行動、対象範囲、公開慣行の変化も検討が必要である。
観測された悪用にも限界がある。監視データセットに存在しない脆弱性が、必ずしも安全または未使用とは限らない。逆に、開示件数が大きいからといって、成功した侵害が同じ規模で増えたことは示されない。研究者が観測できるものには、可視性とサンプリングが影響する。
したがって、最も強固な懐疑的立場は、本物の技術的進歩を認めつつ、規律ある測定を求める。すべての企業報告を退ける必要はない。特に、その結論が過去の合計値や将来の年間成果にまで及ぶ場合、証拠が提示された具体的な結論を支持しているかを問う立場である。
AI Vulnerability Finding において未解決なのは、自動化システムが実在する脆弱性を特定できるかどうかではない。引用されたプロジェクトの記録は、すでにその限定的な主張を裏付けている。不確実なのは、比較可能な対象集団全体での規模、増加に対する責任の所在、そして発見が永続的な保護へ転化される割合である。
この区別は公開の議論を形作るべきだ。すべての脆弱性を即時の大惨事として扱えば、優先順位付けが圧倒されかねない。不確実な集計統計を理由に、文書化された発見を無視するのも反対側の誤りである。証拠が、主張の範囲と対応の緊急性を決めるべきだ。
確認済みの修正、リリース時期、独立した再現を注視する
次に有用な証拠は、発見の出力を受理された指摘、提供された修正、再現可能な結果へ結び付けるものになる。
今後数か月はまず、Anthropic と参加組織による、より完全な報告に注目したい。有用な進展とは、どの発見が受理され、修正され、サポート対象のリリースに含まれたかを示す対応付けられた件数である。比較可能な報告があれば、既存の発見に関する主張を評価しやすくなる。
より強い説明では、重複報告と関連する欠陥をどのように扱ったかが明示される。非公開で保守されるソフトウェアと、文書を検証できる公開プロジェクトも区別されるべきだ。また、重複する期間や規模の異なる期間を比較しないよう、報告期間を明確に特定する必要がある。
この情報が、完了した修復を伴う発見の増加を示すなら、防御能力の改善を支持する根拠は強まる。確認済みの発見が対応するリリース証拠なしに蓄積するなら、発見が対応を上回っているという懸念を強める。報告が不完全なだけでは、結果は不確実なままだ。
次に、受理された報告から利用可能な更新までの時間に注目したい。パッチ、すなわち欠陥を修正することを目的としたソフトウェア変更は、中間的な到達点である。サポート対象のリリースによって修正はユーザーに提供され、導入によって影響を受ける環境に届くかどうかが決まる。
これらの間隔が重要なのは、個々の問題が長く待たされる状況でも処理能力は向上し得るからだ。チームは全体としてより多くの報告を完了できても、難しい案件のキューを増やし続ける可能性がある。完了済みの修正だけを報告すれば、こうした未解決の項目は隠れてしまう。
短く持続可能な修復サイクルの証拠は、自動化された発見が運用上のセキュリティを改善できるという主張を強める。未解決キューの増加や、以前の修正への繰り返しの訂正は、その主張に疑問を投げかける。どちらの結果も、見出しを飾る発見件数と併せて注目に値する。
第三に、保守リソースが異なるプロジェクト間での独立した再現に注目したい。広範にテストされたブラウザからの結果は有益だが、すべてのアプリケーションやライブラリで同等の結果が得られることを示すものではない。より幅広い証拠には、文書化された環境、受理された発見、必要となった作業の明確な説明が求められる。
メンテナーがベンダーの合計値を単に支持するのではなく、自ら評価を公表する場合、再現は特に有用となる。発見の妥当性と修正についての一致は、説得力のある出力を生むデモンストレーションよりも多くの情報を提供する。不一致は、集計統計では見えない限界を明らかにし得る。
これらの指標は、最終的に誰が最も利益を得るかという予測に頼らず、進捗を評価する方法を示す。攻撃者と防御側は関連する能力を利用できるが、その目的と運用上の制約は異なる。結果は、アクセス、実装、そして保護的な変更が影響を受けるシステムへ届く速さに左右される。
元のコメントは AI Vulnerability Finding を巡る驚きを捉えているが、驚きは精査の出発点である。その割合の裏にあるデータセットを求めよう。どの深刻度ルールが適用され、日付が発見を示すのか公開を示すのかを問おう。そして、確認、修正、リリースを通じて発見を追跡しよう。セキュリティツールを評価するなら、自チームで再現でき、メンテナーが認識できる成果の証拠を求めるべきだ。ソフトウェア供給者に依存するなら、影響を受けるバージョンと完了した修正をどのように伝えているかを尋ねよう。年間予測を繰り返す前に、基礎となるプロジェクトの記録を読もう。有用な問いは具体的である。発見が加速する際、あなたのソフトウェアに責任を持つ組織は、その証拠を保護へ転換できるのか。
