何が起きたか
Palo Alto NetworksのUnit 42が、OSSの脆弱性を自律的に発見・検証・報告する研究システム「NOVA（Network and Open-Source Vulnerability Analyzer）」の成果を公開した。複数のフロンティアAIモデルと専用の解析ツールを独自のハーネス（実行制御の枠組み）で束ねた構成で、最終レビューまで人間が介在しないとしている。
規模は2カ月で3,915のOSSプロジェクト、確認された脆弱性は14,090件。うち99.4%は公開情報に存在しないものだった。深刻度はCVSS 4.0でHighまたはCriticalが5,600件（39.7%）、CVSS 3.1では4,030件（28.6%）となる。
注目すべきは種類の偏りである。ファザーが得意としてきたメモリ・計算処理の欠陥は557件で全体の4.0%、リソース管理やDoSを加えても1,121件（8.0%）にとどまる。残る92%は、アクセス制御・認可の不備、パストラバーサル、コードインジェクション、プロトタイプ汚染、SSRFといった、コードの意図を読まなければ判定できない論理系の欠陥だった。
エコシステム別では、Goが1,636プロジェクトで3,281件、JavaScript/TypeScriptが2,197プロジェクトで2,836件。一方でPHPは17プロジェクトから2,740件、Java/JVMは14プロジェクトから1,784件と、対象数に対する検出密度が際立つ。
サプライチェーン関連は5,421件で、依存パッケージ自体の欠陥が1,280件、下流アプリケーションから到達しうる露出が4,141件。うち2,776件は下流側から動作するPoCで悪用可能性を確認したという。公開情報と突き合わせて一致したのは85件のみで、その多くはNOVAの発見から2〜8週間後に公表されていた。開示はメンテナやLightwell、Akritesといったクリアリングハウスと連携して進めているとしている。
「the patch window has collapsed」— Unit 42 (Palo Alto Networks)
なぜ重要か
この結果が示すのは、脆弱性の発見コストが桁違いに下がったという一点に尽きる。OSS-Fuzzは2016年の開始から2023年8月までに1,000プロジェクトで1万件超の修正に寄与したが、NOVAはそれに匹敵する規模を単一のキャンペーンで2カ月に圧縮した。Unit 42はこの構造変化を「the patch window has collapsed」と表現する。
問題は、これがUnit 42だけの能力ではないことである。原文は、公開情報との重複がわずか85件だったことを、他の組織も独自にOSSを走査している傍証と読み、脅威アクターも同じことをしていると想定するのが妥当だとしている。さらに、公開されたパッチの差分を解析して悪用コードを組み立てる作業には最新のフロンティアモデルすら要らないと指摘する。修正が公開された瞬間が攻撃の起点になるという構図である。
日本企業の運用の多くは、CVEが採番され、NVDやベンダアドバイザリに掲載され、資産管理台帳と突合してから動き出す。原文はパッチ適用までの業界平均を55日とするが、その55日は公開後の話であって、発見から公開までの空白は含まない。CVE化されない指摘や、メンテナが処理しきれず滞留する指摘が増えれば、この運用は起点となる入力そのものを失う。
副作用も見えている。AI支援の発見が誰にでも回せるようになれば、品質も緊急度も悪用可能性もばらついた報告がメンテナに集中する。多くのOSSは少人数の無償労働で維持されており、報告の増加はかえって修正速度を落としかねない。
R&Rの視点
支援の現場で最初に詰まるのは、技術ではなく社内規程である。脆弱性管理規程やSLAの多くは、対処対象を「CVEが採番され、CVSSがHigh以上のもの」と定義している。この定義のままでは、CVE番号のない指摘はチケットとして起票すらできない。まず対象定義を「悪用可能性が実証された欠陥」へ広げ、CVEの有無は優先度を決める一要素に格下げする改訂が要る。
経営層への説明は、KPIの置き換えが軸になる。「パッチ適用率99%」という指標は、CVE公開を起点にする限り、発見から公開までの空白を測れない。代わりに、悪用可能性が判明してから防御が効くまでの暴露時間を指標に据えるべきだ。これが仮想パッチ（IPSやWAFでの緩和）の予算根拠になるが、日本企業ではIPSの運用主体がネットワーク部門、脆弱性管理はセキュリティ部門という分断が起きやすい。誰がパッチ提供前に遮断ルールを入れる判断をするのかを事前に決めておかないと、技術があっても数日単位で止まる。
調達契約も点検対象になる。委託先へのセキュリティ要求が「既知CVEへの対応」で書かれていれば、未採番の欠陥が見つかったときに責任範囲が曖昧になる。
実務者が今日やること
- 脆弱性管理規程の対処対象がCVE採番済みに限定されていないか、規程本文の定義を確認する
- 自社が依存する主要OSSのメンテナ人数と直近の更新頻度を棚卸しし、滞留リスクを評価する
- SBOMの更新契機がリリース単位になっているか、直近3カ月の更新履歴で実態を確認する
- パッチ提供前にIPSやWAFで遮断ルールを入れる判断者と承認手順を、部門横断で決める
- 委託先契約のセキュリティ要求が既知CVE対応に限定されていないか、条文を洗い出す
出典
- The Frontier AI Vulnerability Burst: Industrializing Autonomous Zero-Day Discovery in Open-Source Software
Unit 42 (Palo Alto Networks)
