TITLE

AIが14,090件のOSS脆弱性を発見 ― Unit 42「NOVA」が変える脆弱性対応の前提

投稿日：2026.08.09

NOVAの仕組み ― 発見から開示までを自動でつなぐパイプライン

NOVA(Network and Open-Source Vulnerability Analyzer)は、Unit 42が "fully autonomous vulnerability discovery system" と位置づける調査システムです。対象OSSプロジェクトの来歴確認から、脆弱性候補の特定、概念実証(PoC)の作成、検証、パッチ生成、開示報告までの一連の工程を、複数のAIモデルのアンサンブルを使って自動で進めます。

この工程のうち、候補を絞り込むトリアージや、実際に動作するPoCを組み立てる検証作業、修正パッチの作成は、いずれも対象コードへの理解を要する工程です。NOVAが示したのは、この一連の工程をAIモデルのアンサンブルでつなげられる、という実例です。

14,090件、99.4%が未報告という数字の意味

3,915のOSSプロジェクトという解析対象の規模に対して、14,090件という検出数はプロジェクト当たり平均3.6件に相当します。重大度で見ると、脆弱性の深刻度を数値化する業界標準指標CVSS(Common Vulnerability Scoring System)の3.1基準でHigh〜Critical相当が4,030件(28.6%)、CVSS 4.0基準では5,600件(39.7%)にのぼりました。

対象言語・エコシステム別の内訳は次のとおりです。

言語/エコシステム	プロジェクト数	検出脆弱性数
Go	1,636	3,281
JavaScript・TypeScript	2,197	2,836
PHP	17	2,740
C/C++	39	1,925
Java/JVM	14	1,784
その他	12	1,524

PHP、C/C++、Java/JVMはプロジェクト数が少ない一方で検出件数が多く、プロジェクト当たりの検出密度が高くなっています。

ここで押さえておきたいのは、「未報告」が「無害」を意味しない一方で、「発見された」がそのまま「悪用可能」を意味するわけでもない、という点です。99.4%という数字は既存の脆弱性データベースへの登録有無を基準にした集計であり、実際の悪用可能性とは別の軸で測られています。それでも、これまで既存データベースで見えていた脆弱性は、この解析対象に限れば全体の0.6%、いわば水面上に出ていた氷山の先端に過ぎなかったことになります。この「99.4%の空白地帯」という事実は、「OSSのセキュリティはコミュニティの目によって十分にカバーされている」という前提を見直す材料になります。

92%が意味論的欠陥 ― 従来の自動化ツールの死角

NOVAが検出した欠陥のうち92%は、意味論的・論理的な欠陥(semantic/logical flaws)でした。この分類が重要なのは、既存の静的解析ツールが得意とする領域とほぼ重ならないためです。

静的解析ツールの多くは、既知の危険なパターン(未検証の入力をそのままクエリに渡す、といった典型的な書き方)への一致を探す仕組みで動いています。構文やAPIの使い方としては正しいコードの中に埋め込まれた、業務ロジックの前提の崩れ、権限チェックの抜け、状態遷移の想定漏れといった欠陥は、パターンマッチでは拾いにくい領域です。AIモデルのアンサンブルがコードの「意味」を理解した上で候補を絞り込めるのだとすれば、この死角を埋める方向に働くことになります。

開発チームが見直すべき3つの視点

この調査結果を受けて、開発チーム・DX担当者が着手すべき見直しは、検知の量への対応力を上げることではありません。むしろ、検知の後工程の設計です。

検知から検証への重心移動

これまでの脆弱性対応は、既知のCVEデータベースと突き合わせて「該当するか・しないか」を判定するトリアージが中心でした。しかし意味論的な欠陥は、機械的な突き合わせだけでは真偽を判定しづらく、対象コードのロジックを理解した検証が要ります。トリアージ担当者に求められる役割は、件数をさばくことから、検証の優先順位をつけることへ移ります。

静的解析だけでは埋まらない穴の自覚

SCA(Software Composition Analysis)ツールや静的解析は、既知の脆弱性パターンと依存関係のバージョンを突き合わせる仕組みが中心です。これらのツールが「グリーン」であることは、意味論的な欠陥が無いことを保証しません。導入済みのセキュリティツールがどの種類の欠陥をカバーし、どの種類をカバーしていないかを、検出方式のレベルで把握しておく必要があります。

パッチ供給の急増に耐える受け入れ体制

自律型システムによる脆弱性発見が普及すれば、OSSメンテナへの報告・パッチ提案の件数自体が増える可能性があります。これは良い変化である一方、受け取る側の開発チームには、届いたパッチや開示情報を検証してから適用するレビュー体制が要ります。パッチの生成が自動化されても、それを自組織のコードベースに安全に取り込めるかどうかの判断は、依然として人間の検証が必要な工程です。

まとめ

まず着手できる一歩は、自社が依存しているOSSコンポーネントについて、現在のチェック体制が静的解析やSCAツールのみに依存していないかを洗い出すことです。その範囲が権限チェックの抜けや状態遷移の想定漏れといった意味論的な欠陥をどこまでカバーできているかを確認するところから、検証体制の見直しは始められます。見つける力がAIによって底上げされるほど、この洗い出しの解像度そのものが対応速度の実質的な上限を決めることになります。

出典

Unit 42(Palo Alto Networks)「The Frontier AI Vulnerability Burst: Industrializing Autonomous Zero-Day Discovery in Open-Source Software」 https://unit42.paloaltonetworks.com/frontier-ai-vulnerability-burst/
ITmedia エンタープライズ「従来型テストの限界があらわに 3915件のOSSを解析して判明した『99.4％未報告』の実態」(2026年8月7日) https://www.itmedia.co.jp/enterprise/articles/2608/07/news026.html

※ この記事は AI を使用しています。Leadeas が自社開発した AI エージェント基盤で下書きを作成し、人間のレビューを経て公開しています。AI ネイティブ開発会社として自社の技術をそのまま実演する目的で、この手法を用いています。(詳しくは AI 利用ポリシー)