Mythos時代において、セキュリティはランタイムに宿る

セキュリティの歴史のほとんどにおいて、防御側を救ってきたのは「時間」でした。脆弱性が公表され、パッチが提供されるまでの間、攻撃者が信頼性の高いエクスプロイトを構築するには数か月から数年を要していました。その時間差こそが、スキャン・パッチ適用モデル全体を支えてきた緩衝材だったのです。

その緩衝材は、もはや存在しません。Zero Day Clockによると、脆弱性の公表から兵器化されたエクスプロイトが登場するまでの平均時間は、2018年時点でおよそ2年半だったのに対し、2026年には数時間にまで短縮されています。その要因となっているのが、Mythosのようなフロンティアモデルです。コードの欠陥を発見するのと同じシステムが、そのまま動作するエクスプロイトを書き上げてしまう。しかも、それらすべてを機械の速度でこなしてしまうのです。

これにより、正反対の方向へ引っ張り合う二つの問題が同時に生じています。

一つ目は「未知の攻撃」です。フロンティアモデルは、参照すべきCVEもパッチも存在しないまま、皆さんのアプリケーションやAIエージェント、それらが呼び出すツール、あるいはその依存関係の中にゼロデイを発見できます。標的がAPIキーやデータベースへのアクセス権、さらにはコード実行能力まで備えたエージェントである場合、発見から侵害までの距離はわずか数秒で縮まってしまいます。カタログ化されたことのない欠陥である以上、スキャンして見つけるべき対象すら存在しないのです。

二つ目は「既知の脆弱性の氾濫」です。新規の欠陥を発見するのと同じ能力が、脆弱性レポートを何千件と生成してしまいます。すでに手に負えなくなっていたバックログは、さらにあふれかえることになります。チームはリスクではなく勘に頼ってパッチを適用するようになり、本番環境では決して到達し得ない脆弱性に費やす1時間は、実際に到達し得る脆弱性のために使われるはずだった1時間を犠牲にしているのです。

ここで注目すべきは、どちらの問題も「静止状態のコード」を眺めるだけでは解決できないという点です。スキャナーは、まだ存在しないゼロデイにフラグを立てることはできません。また、既知のCVEが実際に稼働中のシステムで到達可能かどうかもスキャナーには判断できないため、あらゆるものにフラグを立て、それを「入念な対応」と呼んでいるにすぎません。両者に共通する盲点は同じです。成果物を検査するツールは、そのソフトウェアが実行時に実際に何をしているかについて、まったく把握していないのです。

だからこそ、Mythos以後の世界で通用する唯一のアプローチは「実行ベース」の手法です。コードのどこに問題がありそうかを推測するのではなく、そのコードとエージェントがランタイムにおいて実際に何をしているのかを、リアルタイムで監視するのです。あらゆるプロンプト、あらゆるツール呼び出し、あらゆるAPIリクエスト、あらゆるライブラリの呼び出し、そして触れられるあらゆるリソースが対象になります。

実行状況を監視すれば、CVEを必要とせずとも未知の問題に対処できます。実行状況の監視は、既知の脆弱性の氾濫を抑える効果もあります。まず、ゼロデイをブロックするのと同じ要領で、望ましくない挙動をブロックすることができ、これにより修正までの時間を稼げます。さらに、どの関数が実際に実行され、到達可能なのかが見えるようになれば、皆さんの環境で本当に悪用可能な脆弱性と、机上の存在にすぎない何千もの脆弱性とを切り分けられます。到達不可能なCVEの管理には、これまで多大なコストがかかっていましたが、このアプローチを取れば、そのコストは文字通りゼロになります。そして、到達可能なCVEにこそ注意が向けられるようになります。優先順位付けは、もはや当てずっぽうではなくなるのです。

かつて「予防」とは、悪いものが実行される前に締め出すことを意味していました。しかし、人間のどんな対応よりも速く、攻撃がオンデマンドで生成される世界においては、予防とは、悪意ある挙動が発生した瞬間にそれを認識し、止めることを意味しなければなりません。制御すべきポイントは、境界線やパイプラインからランタイムへと移っているのです。

この流れが逆戻りすることはありません。フロンティアモデルの速度に対抗できる唯一の防御策とは、そのモデルが生み出すエクスプロイトが最終的に実行される場所、すなわちランタイムそのものに宿る防御策なのです。