もはやサイバーセキュリティは「Proof of Work（作業証明）」と化している

最近のサイバーセキュリティ業界を見ていると、まるで仮想通貨のマイニングのように、終わりのない徒労感のある作業を強制されているように感じないだろうか。効率的な防御よりも、単なる作業量の積み重ねが評価される現状に警鐘を鳴らしたい。

トニー・ホーアによる適切な引用をひとつ。「ソフトウェア設計には2つのアプローチがある。欠陥が明らかに存在しないほど単純にするか、欠陥が明らかではないほど複雑にするかだ」

プルーフ・オブ・ワーク（作業による証明）みたいな話に見えるね。

懸念すべき点として、1億ドルの予算を与えられたモデルのどれもが、収穫逓減の兆候を見せなかった。AISIは「モデルはトークン予算が増えるにつれて、テストされた範囲内では継続的に進歩している」と指摘している。

つまり筆者は、トークンの消費量と攻撃の成功率には永続的な正の相関がある、と推論しているわけだ。だから、自分の脆弱性を先に見つけるためには、攻撃者以上にトークンを消費する必要があるということになる。

ただ留意すべきは、この調査が「32ステップのネットワーク侵入」という非常に複雑なタスクに関するもので、Mythosというモデルだけが完遂できたという点だ。じゃあ、比較的単純な単一のコードライブラリに対してMythosを向けた場合も同じことが言えるのか？直感的には、単純なタスクであればあるほど、収穫逓減のポイントはもっと手前に来るはずだと思う。

この世界観だと、人気のあるオープンソースプロジェクトは、防御側と攻撃側の双方によって、合計トークン消費量が増えるだろう。そうなれば、収穫逓減のポイントに早く到達するかもしれない。もしそんなポイントが存在するなら、の話だけど。

前のコメントでも詳しく議論したけど、この記事はカテゴリエラーを犯していると思う。商用環境において、日々の情報セキュリティ業務（または予算）の大半は、コード内の脆弱性を探すこととはほとんど関係がないからだ。

実際、コードベース内のすべてのセキュリティホールを見つけてパッチを当てればなんとかなる、なんて考えに基づいたセキュリティプログラムは、LLMが登場するずっと前から基本的に破綻していたよ。

コードベースへのアクセスという問題も残っている。今のところ、最高のLLMサイバースキャン手法といっても実際は非常に原始的だ。単なるbashスクリプトがコードベース内の全ファイルを走査して、ファイルごとに「ここの脆弱性を見つけろ」というプロンプトを実行しているだけだからね。攻撃者はこれよりもさらに少ないアクセス権しか持っていないことが普通で、最初にあるのはネットワークツール、ドキュメント化されていないAPI、あとはせいぜいバイナリくらいだ。

ただ、ソースコード全体を自分で管理しているなら、効率面ではかなり有利に動ける。論理的に関連する変更をすでにPR（プルリクエスト）としてまとめてあるはずだから、LLMに変更したファイルだけを見させることでスキャンコストを節約できる。セキュリティに関連するコードを触るなら、攻撃者が自身のスキャンにかける労力よりも、ファイルあたりのコストをより多くかけるようLLMに指示することだってできる。攻撃者がやるような大規模なスキャンを、固定スケジュールで実行することだって可能だ。攻撃者はそれぞれ個別にスキャンを走らせないといけないけど、こっちは1回スキャンを走らせるだけで、彼らが見つけそうなものをすべて洗い出せる。防御側の「ハードニング（堅牢化）」フェーズと、攻撃側の「エクスプロイト発見」フェーズの間には、圧倒的なコストの非対称性が存在するんだ。

それに、エクスプロイトの成否はバイナリ（0か1か）じゃない。たとえ攻撃者がこちらより潤沢なリソースを持っていたとしても、彼らはシステムの脆弱性を連鎖させて攻略する必要があるのに対し、こちらはその連鎖の中で最も弱いリンクをひとつ潰せばいいだけだからだ。

セキュリティを「どちらがより多くのトークンを燃やせるか」という競争にまで単純化してしまうと、防御側が得られる効率的なアドバンテージは、最高のリソースを持つ攻撃者にしか覆せないものになる。結論として、Mythosクラスのモデルが一般公開されることは、ソフトウェアをよりセキュアなものにするはずだ。

セキュリティなんて昔から、相手がいくら金を積む気があるかというゲームに過ぎない。この記事の結論の多くは、もともとよく理解されていたシステム設計の概念に過ぎないんだけど、なぜかみんなそれを新規性があるもの、あるいはLLMが価格以外のすべてを変えたかのように振る舞っている。

例えばこの記事のここ：

Karpathy: 従来のソフトウェアエンジニアリングは「依存関係は良いものだ（レンガを積んでピラミッドを作るように）」と信じさせてきたが、個人的にはこれを再評価すべきだと思っている。だからこそ、十分シンプルで可能な場合はLLMを使って機能を「拝借（yoink）」する方を好むようになっている。

「leftpad」について聞いたことがあるか、Goプログラマであれば（「少しのコピーは少しの依存よりも優れている」というのはまさにGoの格言だ）、こんなのは常識だ。

最近HNに投稿された別の記事では、セキュリティのためにコードをクローズドソースにする企業が取り上げられていたけど、「隠蔽によるセキュリティ（security through obscurity）」が誤りであることは、オープンソース界隈では何十年も前から共通認識だよ。

この記事は第三者分析として「AI Security Institute」を頻繁に引用している。初めて聞く団体だったので「About」ページを見てみたけど、基本的にはAI業界出身者（元DeepmindやOpenAIのスタッフなど）で構成されていて、セキュリティ業界の人間は一人も記載されていなかった。セキュリティの状況が進化しているのは確かだとしても（Big SleepやProject Zero参照）、「システムを堅牢化するにはトークンを多く消費する必要がある」という結論は、別の角度から見たAIの販促にしか聞こえない。なぜ他の代替案（形式検証など）が記事やAISIのレポートで全く触れられていないのか、疑問だよ。

NVIDIAがGPUをたくさん売るためにこの論点を取り上げたと言われても驚かないね。

システムを堅牢化するには、攻撃者がそれを利用するために費やすコストよりも、エクスプロイトを見つけるために多くのトークンを費やす必要がある。

私はかつてNFL（ナショナル・フットボール・リーグ）のフロントオフィス向けに、フロントエンドを通じてTicketmasterを完全自動化するスクリプトを作成したことがある。日曜日に雨が降ると予想される場合は価格を下げるなど、動的なチケット価格設定を可能にするためだった。TicketmasterのAPI開発は遅れていたし、法的な理由でAPIを開発するまでは許可を出せないと言われたが、「全力で阻止する」とまで言われた。

彼らはPerimeterXを導入したが、突破するのに3日しかかからなかったよ。

先週、ChatGPTがCloudflare Turnstileを使っているという記事がここに投稿されたけど、あれには誤解がある。第一に、記事には動作原理に関する間違いがある。第二に、私は[AI企業の製品]とChrome DevTools Protocol (CDP)を使って、スクリプトが評価される前に、それらを傍受して書き換える仕組みを構築した。PerimeterXを3日で攻略したのと同じ方法だ。さらに、フィンガープリントを制御してプロファイルを完全に管理するソルバーも作成した。その後、ChatGPTを無料で公開するためのAPIプロキシも作った。手法について少しだけコーチングが必要だったが、AIが作業のほとんどを3時間で終えてくれたよ。

これらの企業は何千万ドルもの金をそうした製品に費やしているけど、OpenAIがセキュリティについて豪語している内容を考えると、結局それらは無価値なんだ。

信頼できるソフトウェアを作るコストがあまりに高くなりすぎて、インフラ系のスタートアップは、ソフトウェアの堅牢化に何百万ドルも費やしたと証明できない限り、事実上死滅することになるだろう。

ソフトウェアのエコシステムは二極化すると予測する。ファイアウォール内部のソフトウェアはこれまで以上に安価になるが、外部公開されるものはハッキングへの懸念から指数関数的に高価になるはずだ。

見落としがあるかもしれないけど、「完璧に安全である必要はなく、侵入する労力に見合わない程度に安全であればいい」という考え方もあるはずだ。

（国家レベルの工作員ではなく）犯罪者の場合、たいていは「同業他社と同じくらいのセキュリティレベル」であればいい。なぜなら、彼らは最も費用対効果（ゲイン/労力）が良いターゲットに時間を割くからね。

もしOSSライブラリに依存する企業が、トークンを費やしてそれらをセキュアにするなら、個人の予算でやるよりはるかに安全になるだろう。

それはかなり大きな「もし」だ。多くの企業は自分たちが使っているOSSすら把握していないし、OSSを「自分たちでメンテナンスするコストを外注（肩代わり）するために」使っているケースが多いからね。

私が期待しているのは、騒ぎが落ち着いた後に、脆弱性検知の精度が高いOSSのSASTツールが増えることだ。修正案まで提案してくれるならなお良い。OSS開発者は企業ネットワーク全体を横断するような20段の連鎖攻撃なんて気にしない。彼らが気にしているのは、自分たちが作ったアプリをセキュアにすることだけだ。そして、そのアプリ自体が堅牢化されていれば、それが攻撃者が越えられない唯一のリンクになるかもしれない。