NOVAと呼ばれる自動化システムが、オープンソースプロジェクト3,915件のソースコードを2カ月かけて読み込み、14,090件の脆弱性を検出しました。これらはいずれもシステムの検証パイプラインを通じて確認済みのものです。
Palo Alto NetworksのUnit 42に所属する脆弱性研究者たちがこのシステムを構築し、後になって検出結果を公開情報と照合しました。すでに文書化されていた内容と一致したのはわずか85件で、そのほとんどはNOVAが発見してから2〜8週間後に公開されたものでした。
注目すべきは検出件数そのものではありません。2016年にGoogleのOSS-Fuzzが登場して以来、機械による大量のバグ発見はすでに実現していました。2023年8月までに、OSS-Fuzzは1,000件のプロジェクトにわたって1万件以上の欠陥の特定と修正に貢献しています。今回変わったのは、見つかるバグの種類です。NOVAの検出結果のうち、これまでファザーが得意としてきたカテゴリに該当するのはわずか8%にすぎません。残りの92%は、クラッシュという形で自らの存在を知らせることのないバグなのです。
ファザーはクラッシュを見つける。今回見つかったのは壊れた権限管理
ファザーはプログラムに不正な形式の入力を投げ続け、何かが壊れるまで繰り返す仕組みです。そのためメモリ破損や整数オーバーフロー、null参照といった問題の検出には強みを発揮する一方、動作し続けているものに対しては無力です。
「私たちがフロンティアAIの検出結果の分類に用いたタクソノミーでは、最も近いカテゴリであるメモリ・計算関連の問題は557件、全体のわずか4.0%にとどまりました。リソース管理やサービス拒否(DoS)関連の問題を加えても、これらファジングと相性の良いカテゴリの合計は1,121件、全体の8.0%にすぎません」と、Palo Alto NetworksでCloud Delivered Security ServicesのSVPを務めるXu Zou氏は説明しています。
それ以外はすべて、目に見える形では何も壊れないカテゴリからの検出でした。アクセス制御の欠陥では、ソフトウェアがユーザーの身元は確認しても、要求された操作を行う権限があるかどうかまでは確認していません。パストラバーサル、コードインジェクション、プロトタイプ汚染、サーバーサイドリクエストフォージェリ(SSRF)などもこれに含まれます。こうした問題を検出するには、そのコードが本来何をすべきだったのかを推論する必要があります。
その内訳は言語によって異なり、それぞれのエコシステムの構築方法を反映していました。CおよびC++の検出結果はメモリ安全性に集中していました。JavaScriptとTypeScriptの検出結果は、インジェクション、プロトタイプ汚染、SSRFに集中していました。PHP、Java、Pythonの検出結果は、多様な種類のユーザーを扱わなければならないアプリケーションに繰り返し見られる弱点、すなわちアクセス制御の不備が大半を占めていました。
言語別の脆弱性の種類を見ると、それぞれのエコシステムに固有の弱点プロファイルがあることがわかります(出典: Unit 42)
依存関係の欠陥1件が、4,000件の露出を生む
調査対象となったパッケージエコシステムにおいて、このパイプラインはサプライチェーン関連の検出結果を5,421件生み出しました。そのうち1,280件は依存パッケージ自体の欠陥です。残る4,141件は下流での露出、つまりアプリケーションのコードが脆弱な依存関係に到達してしまうケースでした。
覚えておくべきはこの比率です。パッケージにおけるおよそ1,300件の欠陥が、4,000件を超える下流での露出を生み出したのです。そしてそのうち2,776件は、依存関係グラフから推測されたものではなく、下流のアプリケーションから実際に起動した動作するプルーフ・オブ・コンセプト(PoC)によって検証されました。ソフトウェア構成分析(SCA)ツールは脆弱なバージョンの存在にフラグを立てるものです。今回の検証は、その欠陥がアプリケーションの実際の使用箇所から実際にトリガーできることを裏付けたことになります。
パッチと悪用の間にある溝こそが問題のすべて
「NOVAでの経験から明らかになったのは、構造的な変化が起きているということです。パッチ適用までの猶予期間は崩壊しました」とZou氏は記しています。同氏のチームの推計によれば、従来型のパッチ展開にかかる業界平均日数は55日です。
攻撃者はこの状況を利用するのに、最新のフロンティアモデルを必要としません。修正プログラムが公開されれば、旧バージョンと新バージョンの差分によって捜索範囲は数行にまで絞り込まれます。パッチから逆算して悪用コードを作り出すことは、バグをゼロから見つけ出すことに比べればはるかに安上がりな作業です。発見が速まればパッチも増え、パッチが増えれば攻撃の起点も増えることになります。
CVEはなく、検証する手段もない
Unit 42は、オープンソースのメンテナーや、LightwellやAkritesといった脆弱性クリアリングハウスと連携し、発見した欠陥の上流での修正を進めていると述べています。しかし、影響を受けたプロジェクトを一つも名指しせず、CVE識別子も公開せず、14,090件の欠陥のいずれについても、いつコードの管理者に報告されたのかを明らかにしていません。
この見出しを飾る件数も、その内訳が極めて偏っていることを覆い隠しています。対象となった6つのエコシステムグループのうち4つは、合わせても対象プロジェクトが100件に満たないにもかかわらず、検出結果全体の半数以上を生み出しました。大規模で密度の高いコードベースはまとまって欠陥を生み出す傾向があるため、この合計件数はオープンソース界全体に散らばる1万4千件のばらばらな驚きを意味するわけではありません。実際には、少数の大規模アプリケーションが一度に大量の欠陥を露呈し、それに加えて数多くのパッケージが少しずつ欠陥を露呈しているという構図です。
深刻度は、どの物差しを使うかによって変わります。CVSS 3.1では、検出結果のうち4分の1をやや上回る割合が「高」または「重大」と評価されました。CVSS 4.0では、この割合は5分の2をやや下回ります。同じバグでも、算出方法が違えば結果も変わるのです。
翻訳元: https://www.helpnetsecurity.com/2026/08/05/code-review-ai-vulnerability-discovery/
