深夜に脆弱性スキャナがCVSS 9.8の警告を出し、緊急でベンダーに連絡した。翌朝、委託先から返ってきた回答が「報告されている関数が、そのバージョンのコードに存在しません」だった——という状況が、現実に起こりはじめています。
対応そのものは空振りで済みます。問題は、空振りだと分かるまでに投じた時間と、深夜に叩き起こした人の信頼です。そしてこの空振りは、今後増えます。
6件の「重大な脆弱性」が、まるごと作り話だった
セキュリティ企業のJFrogが、SQLiteに関する重大な脆弱性として報告されていた6件を調査したところ、すべてが実在しないものだったという結果を公表しました（SQLite Critical CVEs or LLM Slop? — JFrog Security Research）。
いずれも深刻なメモリ関連の不具合として、最大9.8のスコアが付けられていました。しかし調べると、問題があるとされた関数が、指定されたバージョンのコードに存在しない。 添付されていた実証コードを動かしても、クラッシュしない。報告の体裁は整っているのに、中身が対応していませんでした。
さらに調べると、新しく作られた1つのGitHubアカウントが、数日のうちに55件の脆弱性報告を投稿していました。そのうち54件が捏造だったと結論づけられています。文面を生成AI判定ツールにかけたところ、機械生成と判定されました。
公的データベースに載った時点で、本物と同じ扱いになる
GitHub上の投稿だけなら、無視すれば済みます。実際に厄介なのは、これらが米国の公的な脆弱性データベースであるNVDに到達していたことです。
NVDでは重大と記録され、CISAのチームによる情報の付加まで行われていました。そしていったんここに載ると、世界中のスキャナと防御側はそれを本物として扱います。 自社の脆弱性管理ツールが警告を出すのは、この経路を通ってきた情報です。
つまり、警告を受け取る側から見れば、真偽の判定はもう終わったものとして届きます。「公的データベースに載っている重大な脆弱性」と言われて、それを疑うことを前提にした運用を組んでいる会社は多くありません。
真贋を確かめる4つの確認
幸い、見分けるための確認は特別な技術を必要としません。JFrogが捏造を見抜いた方法は、そのまま現場で使えます。
| 確認すること | 本物なら | 偽物によくある兆候 |
|---|---|---|
| 該当の関数・コードが実在するか | 指定バージョンのソースに存在する | 関数名が見つからない、別バージョンにしかない |
| 実証コードが再現するか | 想定どおりの異常が起きる | 何事もなく完走する |
| 報告者の履歴 | 過去の報告や所属が追える | 新規アカウントが短期間に大量投稿している |
| 上流プロジェクトの反応 | 開発者が確認・修正している | 議論の形跡がない、または否定されている |
このうち最初の2つは、委託先に依頼すれば数十分で回答が出ます。 「該当関数は存在しますか」「PoCは再現しますか」の2問です。緊急対応に入る前にこれを挟むだけで、空振りの大半は止まります。
4つ目も見落とされがちですが有効です。本当に重大な脆弱性であれば、そのプロジェクトのIssueやコミット、メーリングリストに必ず動きがあります。公的データベースには載っているのに、上流のリポジトリが静かなままという状態は、それ自体が強い違和感です。
保守契約で決めておくこと
この種の警告が増えると、保守を委託している会社では「誰が最初に判断するのか」が曖昧なまま夜間対応が発生します。決めておくべきは3点です。
一次判定を誰が行うか。 警告を受け取った時点で緊急対応に入るのか、それとも実在確認を経てから入るのか。ここを決めていないと、スキャナが鳴るたびに全員が動きます。
緊急対応の起点をどう定義するか。 「CVSSが9.0以上」を起点にしている契約は、いまや偽の報告でも発火します。スコアではなく、影響の確認が取れたことを起点にする書き方に改めておくのが妥当です。
空振りだった場合の扱い。 実在しない脆弱性の調査も作業ではあります。それを保守の範囲に含めるのか、都度の作業として扱うのか。決めていないと、あとから請求の議論になります。取り決めの範囲そのものの整理は脆弱性をAIが見つけて直す時代 — 発注側が保守契約で決めておくことで扱いました。
AIエージェントに直させるときが、いちばん危ない
もう1つ、実務で効いてくる話があります。修正をAIエージェントに任せている場合です。
存在しない関数の脆弱性を渡されたエージェントは、素直に対処しようとします。該当箇所を探し、見つからないので近いものを推測し、パッチを当てる。実在しない問題を直すために、実在するコードが書き換えられる。 人間なら「そんな関数はない」で止まるところが、止まりません。
自動修正を組み込んでいるなら、脆弱性情報の入口に実在確認を1段挟む必要があります。エージェントに渡す前に、対象のコードが本当に存在するかを機械的に照合するだけでも、この種の事故は防げます。AIが書いたコードを誰が点検するのかという論点はAIが書いたコードのセキュリティは誰が見るのかで扱っています。
依存パッケージの更新を急がず一定期間待つという考え方はDependabotが既定で3日待つで紹介しましたが、今回の件はその判断を後押しする材料でもあります。すべての警告に最速で反応する運用は、偽の警告にも最速で反応します。
いま確認しておくこと
自社で使っている脆弱性管理の仕組みが、警告を出したあと誰の手に渡るのかを一度たどってみてください。スキャナ → 通知 → 誰か、の「誰か」が決まっていない、あるいは自動で対応が走る設定になっているなら、そこが今回の話の入口です。
放置された脆弱性が本当に危険であることは変わりません。React2Shellから半年、CVSS 10.0がいまも放置サイトで生きているで書いたとおり、対応しないことのリスクは実在します。変わったのは、警告そのものを一度確かめる工程が必要になったことです。
脆弱性対応の判断フローを保守契約の形に落とし込みたい、自動修正を入れる前の確認工程を設計したい——そうしたご相談は、グリームハブの開発・AI・自動化のご相談で承っています。要件によって最適な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
