すべて緑、なのに穴が残る——ライブラリの「組み合わせ」が生む脆弱性

全部直したはずだった

依存関係をスキャンし、赤が出たライブラリを片っ端からアップグレードする。CVEのチケットを閉じ、ダッシュボードが緑に変わる。完了——のはずだった。

ところが、その緑になった状態に穴が残っていることがある。しかも、当てたパッチのどれ一つとして間違っていない。個々のパッチは、それぞれのCVEに対して正しく、完全だ。にもかかわらず、それらが同じシステムの上で組み合わさった瞬間、単体では見えなかった新しい攻撃経路が生まれることがある。

これは「パッチのバグ」の話ではない。正しい修正が組み合わさった結果、システム全体として新たな悪用可能性が現れる——という、直感に反する現象の話だ。

なぜ誰も気づかないのか

理由ははっきりしている。今のツールは、ライブラリを一つずつ、点（ノード）として見ているからだ。

SCAもスキャナも、「lib X のCVEは塞がれた／塞がれていない」という、ノード単位の答えしか返せない。データモデルがそうなっている。パッチ済みのライブラリAと、パッチ済みのライブラリBの、あいだ——両者が接する相互作用面——を表現する言葉を、そもそも持っていない。

だから全部が緑でも、ノードとノードのあいだに開いた穴は、レポートのどこにも現れない。

先日Aikidoが「upgrade trap（アップグレードの罠）」という記事で、「とにかく最新版に上げろ」という助言がいかに機能しないかを書いていた。あれは同じ近視眼が、製品の挙動として表に出たものだ。ツールが点しか見ないから、助言も「その点を上げろ」にしかならない。組み合わせは、誰の視界にも入っていない。

三つの実例——すべてパッチは正しい

デシリアライズのgadget chain。 あるライブラリをセキュリティ修正のために更新する。それ自体は正しい。ところが、アップグレードによってクラス構成が変わり、クラスパス上の別のライブラリとの組み合わせで、それまで成立していなかった攻撃の連鎖（gadget chain）が成立することがある。悪用可能性は、個々のライブラリではなく「同居している顔ぶれ」から生まれる。

パーサの解釈差（request smuggling）。 フロントのプロキシとバックのアプリサーバは、それぞれ自分の仕様に忠実にリクエストを解釈する。片方の実装をRFC準拠へ近づける——正しい修正だ。だが、その結果として、もう片方との解釈のズレが広がり、リクエスト密輸の隙間を開けることがある。二つの正しさの「あいだ」に穴が空く。

prototype pollution。 汚染を起こせるライブラリ（source）と、その汚染が伝播し、危険な動作へ到達してしまうライブラリやアプリケーションコード（sink）。それぞれ単体では問題が顕在化しなくても、組み合わさることで初めて攻撃が成立することがある。npmの依存グラフには、この手の「二者で初めて成立する」危険が無数に眠っている。

どれも、単体のスキャンでは永遠に見えない。見るべきは点ではなく、点と点のあいだだからだ。

AIは、この問題をどう変えるか——そして変えないか

ここで多くの人が期待する。「AIが賢くなれば、組み合わせの穴も自動で見つけてくれるのでは」と。

半分は当たっている。実際、Google Project ZeroやOpenAIなどの研究では、最先端のモデルが実在のCVEの発見や悪用可能性の検証に成果を上げている。与えられた対象の中を深く掘り、コールグラフを追い、悪用可能性を実証するところまでやる。深さは、もう十分に強い。

だが、肝心の部分でAIはまだ弱い。膨大な組み合わせ空間の中から、「このAとこのBは危ない」という候補を自律的に見つけ、優先順位を付けることは、現在のモデルが最も苦手とする仕事の一つだ。

理由は構造的だ。何度推論を重ねても、それは与えられた枠の内側での探索になる。「この枠組み自体がおかしいのでは」「ここに見えていない関係があるのでは」という、不在への気づきを自分で生み出すことは容易ではない。

少なくともこれまでのところ、深さをいくら積み重ねても、その延長線上に俯瞰が自然に現れた例は見えていない。だから、「AIがもっと賢くなれば勝手に見つかる」と考える保証は、少なくとも今のところない。

だから、地図は人間が持つ

やることは一つ。人間が俯瞰して仮説を立てる。「このパッチ済みの二つは、同居すると怪しい」。その一組をAIに渡し、「組み合わせて、徹底的に検証しろ」と網羅を任せる。

人間が地図を描き、AIに小道を歩かせる。人間＝仮説とスコープ、AI＝深さと網羅。これはまさに「Human in the Right Loop」そのものの一事例だ。攻撃側の「連鎖して届くか」と、防御側の「どの組み合わせが本当に効くか」は、同じreachability解析であり、そこに人間の俯瞰を最初に注入できるかどうかで、見えるものが変わる。

必要なのは「ライブラリの安全性」を判定するツールではなく、「システム全体の相互作用」を評価するツールだ。ノードではなくエッジを見るデータモデルへの転換が、次のSCAには求められている。

セキュリティで希少なのは、手を動かす検査そのものではない。どこを疑うか、という設計だ。 検査はAIに委譲していい。だが「どこを疑え」という地図だけは、人間が手放してはいけない。全部緑のダッシュボードの、点と点のあいだを覗き込むのは、まだ人間の仕事なのである。