それが一つの結果かもしれない、特にこの分野に詳しい大手ベンダーにとってはね。俺が本当に興味があるのは、脆弱性研究者たちのフィールドがどうなるかだ。

その圧力は予測される脆弱性の爆発の結果としてしか起こらないし、その前には起こらないよ。それにはコストがかかるし、脆弱性の検索を行うためには専任でやる気のある人が必要だ。修正を適用して、次のデプロイの前に何も出てこないまで再チェックする必要がある。予測としては、数ヶ月以内にコーディングエージェントがエクスプロイト開発の実践と経済を劇的に変えるだろう。フロンティアモデルの改善はゆっくり進むものじゃなくて、ステップ関数になる。高影響の脆弱性研究が、エージェントをソースツリーに向けて「ゼロデイを見つけて」って打つだけで行われるだろう。

この非対称性はかなり重要な問題だと思う。特に、攻撃者は一つの成功パスが必要だけど、防御者はすべてのパスを閉じる必要がある。実際には、パッチの速度はリリースサイクルやQAの問題、回帰リスク、そして確認が必要なコードベースの数によって制限される。

バグトラッカーが常に空っぽな状態に入ったのはいつからだろう？バグ削減の制約要因は発見ではなく、修正だよ。開発者のスモークテストでも、バグが見つかるスピードは修正できるよりもずっと早いし、実際のQAはもっとそう。公平を期すために言うと、修正の制約要因は通常、再現可能なテストケースを見つけることなんだけど、脆弱性は必然的にそれを必要とする。でも、ほとんどのシステムには再現可能なテストケースがついているバグがたくさんあると思うし、それが修正リソースのボトルネックになっているんじゃないかな。もちろん、設計上不安定なシステムをセキュリティにすることは、これまで大失敗だったってこととは別の話だけど。

もしLLMが本当に俺のソフトウェアの脆弱性をたくさん見つけられるなら、なんでそれを使って脆弱性を修正して、完璧に安全なソフトウェアを作らないの？多分、それをするのは犯罪になるからだろうね。少なくとも、犯罪の脅威があるから。企業が自分たちのソフトウェアのセキュリティがどれだけ悪いかを社会が公然と議論するのは恥ずかしいことだから。俺たちは企業の便利さのために国家の安全を犠牲にしてる。システムのセキュリティをテストすることは許されていない、なぜならそれは企業の責任だから。システムを所有している企業は、そのシステムが不安定で国の個人データの半分が漏れたときでも、責任を問われない。これがどういうことか分かる？検証可能でテスト可能なセキュリティがトップへの道を邪魔することは許されない。常にシステムが安全であることを期待するのも無理だよ。みんなで協力して、データが月に二回漏れているのに、セキュリティの脆弱性を見つけて責任を持って報告することができると思うかもしれない。でも、システムは企業のもので、彼らが唯一の責任者なんだ。でも、（これが非常に重要なんだけど）彼らは責任を負わず、特に金銭的な責任もない。

攻撃者は一度成功すればいいけど、防御者はずっと成功し続けなきゃいけないってこと？

何かを壊すのは直すより簡単だよね。

見つけてからパッチを当てるのは、バグを新しく作るよりも早く修正できる場合にしか機能しない。一部の組織はこれができるけど、できないところもある。

あなたが出荷するパッチは、リリースや依存関係の動いているトレッドミルの上に乗ることになる。新しいコードが古いゴミにくっついて、古い仮定が次のバージョンに漏れ出す。攻撃者はあなたと同じモデルを実行できるから、バグを見つけて修正するギャップは縮まっていく。あなたのチームは機械に対して清掃作業をしているようなものだ。「完全に安全な」ソフトウェアは哲学のセミナーであって、結果ではない。バグのプールをかなり減らすことはできるけど、潮は引かず、砂のお城は崩れ続ける。

前に働いてた会社では、Linuxマシンで作業したいからって、中古のThinkPadを300ドルで買うのに反対されたことがあったんだよね。でも、脆弱性を見つけるために無限にお金を使うことには躊躇しないみたい。遅すぎるってなってからじゃないとね。

セキュリティの問題は、パッケージやゾーン、サービス、セッションなどの境界で発生することが多い。静的解析はこれをキャッチできるかもしれないけど、俺の視点ではそうは見えない。バグはしばしば連鎖していて、それには多くの創造性や計画が必要だ。論理エラーやレースコンディションを考慮する必要があるからね。LLMがこれらを見つけるのは不可能ではないけど、多くの相互作用を明らかにするためにはプログラムの制御フローを追う必要があると思う。人々はLLMを無料だと考えている気がするけど、手を動かさない分、そう感じるのかも。俺はちょっと違うと思うし、これらの脆弱性に対するコストが下がったら、誰もトークンの支出をしたがらない気がする。すでに多くのハッカーが自分のワークフローにAIを使っているけど、それでもかなりの労力がかかるんだよね。

静的解析で全てのバグを捕まえるのはハルティング問題を解決することになるから、絶対に無理だよ。

いい質問だね。ファザーは新しい脆弱性をたくさん生み出したし、特に機関のファズィングクラスターが立ち上がった後や、AFLみたいなカバレッジガイドファザーに収束した後はそうだった。で、安定した均衡点に達して、ファズィング前と比べても脆弱性研究や発見はそんなに大きく変わらなくなった。注目すべき二つのことがあるよ。* まず、ファザーは大量の未検証のクラッシャーを生成し続けているから、syzkallerのクラッシュアーカイブに行けば実際に動くクラッシャーが見つかるよ。私の主張は、モデルは単なる仮想的な脆弱性を生み出すだけじゃなくて、実際に使えるエクスプロイトも生み出すってこと。* 次に、4.6やCodexが脆弱性を見つけるために使っているメカニズムはファザーとは全然違う。ファザーは脆弱性を見つけたことを「知っている」わけじゃないから、単純な刺激/反応テストなんだ（シーケンスが入って、クラッシュが出るか出ないか）。ほとんどのクラッシャーはエクスプロイト可能じゃない。モデルはファザーを使って何かを見つけることができるけど、（少なくともAnthropicのレッドチームに関しては）まだそうしてないのが意外だよ。でも、私が理解している限り、一般的にはそういうことはしてないみたい。もっと静的解析に近いことをやってる。

この記事のどこがこの質問を引き起こしてるの？むしろ、この記事はメモリ安全な言語が勝ってるってことをはっきり示してると思う。非決定的なプログラムに自分のコードの安全性を評価させるのはかなりの不利だよね。

彼らはPythonやJavascriptが得意で、ツールもたくさんある。私のアイデアは、Xから安全な言語への翻訳ツールを作ること。Xは最初はPythonとJavascript。ツールには得意なことをどんどん生成させて、シンプルな翻訳ツールが安全で速くする。CやJavaに翻訳すれば、静的解析やテスト生成のための数十年分のツールを使えるし、PythonやJavascriptでは人間が分析したりライブデバッグするのが簡単になる。翻訳ツールが作れれば、いろんな面で勝利だね。

みんなが同じモデルを使っているなら、ホワイトハットや防御に有利じゃない？状況は不安定だから（このコメントは投稿する頃には古くなってるかも）、でも私が読み取れるのは、防御的なコーディングパターンを提供することへの抵抗感だと思う。おそらく、彼らが防御しようとしている欠陥を明らかにしてしまうから。欠陥が広まっていると、そのパターンは観察力のある目にとって攻撃を安くすることになる。最近の強化された能力を見て、私の陰謀論は、モデルが理想的な緩和策を含む経路を確かに通っているけど、ガードレールにぶつかると共通のアンチパターンに戻ってしまうってこと。見たものの中には驚くべきものがあって、私のレーダーには敵対的として登録されてる。

私は懐疑的になりがちだけど、Carliniとのポッドキャストを聞いて、彼がすごく信頼できる人だと思った。セールスの人でもAIの終末論者でもなくて、重度にファズされたコードの中で本物のエクスプロイトを見つけるのにどれだけ少ない作業で済んだかを話してた。多くのアプリは攻撃するのが面倒だと思うけど、以前思ってたよりも早く起こると思う。

最近、Nicolas Carliniが先週行った講演の動画がYouTubeにあるよ。目から鱗だよ。それを見た後にLLMがサイバーセキュリティの分野を変えるとは信じられないなら、手の施しようがないね。

大体間違ってはいないけど、「脆弱性を見つけて」っていうのはこの分野を正確に表現してるとは言えないな。脆弱性を見つけるのは、LLMが登場する前から、なんか雰囲気的なものになってた気がする。みんなが「これは重要なセキュリティパッチだ！」って言うけど、実際の脆弱性は「特定の条件下で、物理的にデバイスにアクセスできる攻撃者が特別な入力を作成してサービスをクラッシュさせることができる」みたいな感じで、結局それだけなんだよね。SpectreやMeltdownみたいなものも、LLMが特に投機的実行攻撃について知らない限り、自力で見つけるのは難しいと思うし、使うのもすごく難しい。JavaScriptから使えるって騒がれたけど、重要な情報を漏らすにはメモリのレイアウトや他の情報を知っておかないといけない。だから、LLMが表面的な脆弱性をパッチすることはできても、攻撃者にとってはほとんど役に立たないものばかりだよ。現代のシステムはめちゃくちゃ安全だからね。逆に、LLMが知らないことは、利用される可能性がある。例えば、log4shellがまだ見つかっていないとして、ログステートメントがデフォルトでインターネットからJNIオブジェクトを引っ張って実行できるとしたら、LLMはlog4jを使ったログステートメントのコードを喜んで書いて、脆弱性チェッカーを通すだろうけど、バイトコードレベルでもその脆弱性が存在することを理解することはないと思う。全体的に、ライスの定理のおかげで、プログラムが完全に悪用可能かどうかは、実際に何らかの形で実行しないとわからない。LLMはこれを助けることができるけど（もちろん完全には無理だけど）、実行して入力をファジングしたりメモリトレースを観察したりする必要がある。でも、スレッドやタイミング実行みたいなものを導入すると、結果に影響を与えるから、さらに難しくなる。さらに、LLM自体が今や攻撃ベクトルになってる。もしAPIコールを何とか傍受して、コードや他の命令を挿入できたら、開発者がそのコードに脆弱性を仕込むことになる。だから、今のところこの分野は拮抗してると思う。

すでにtrufflehogみたいなツールがあって、漏れた秘密を見つけることができる。macOSはまだライブラリフォルダに生のGitHubプライベートキーを含んでるし、「ああ、俺の神レベルのAWSキーをウェブサイトのJSに入れちゃった」とか、「ああ、フロントエンドにSupabaseキーを入れちゃった」とか、「ああ、ホスティングされたパスワードマネージャーのメンテナーなのに、CMEKキーを持って帰っちゃった」とか。

ソフトウェアを悪用するための生産性の掛け算が高くなるほど、開発者は厳しく対抗できなくなる。ソフトウェアを悪用するのは誰かのフルタイムの仕事だけど、エンジニアはすでにそれを作るための仕事を持ってるからね。これを数値で表すと、開発者が自分のソフトウェアの脆弱性を見つけるために費やす努力（作るのではなく）をD、攻撃者がそのソフトウェアを悪用するために費やす努力をAとすると、最初はA = D × 5が妥当だと思う。一方で、開発者は自分のコードをよく知ってるけど、そのコードはオープンで、ほとんどのソフトウェアエンジニアは基本的に作ることを好むから、そっちに時間を使うことが多い。これはもちろん新しいことではなく、昔からそうだよね。新しい要素は、国家に雇われている攻撃者がいて、彼らは保護されていて、与えられたダメージの量によって生計がかかっている可能性があること。開発者側には同じようなプレッシャーがないから、A = D × 10に調整することになる。×10は攻撃者と開発者の間の初期の力の差だ。さて、その努力にLLMからの生産性向上を反映した定数Lを掛けよう。10にしよう（多くの人がLLMが脆弱性発見で×10以上の生産性を上げると言うだろうけど、ここでは控えめに）。さらに、開発者/攻撃者がLLMを使って最も深刻な脆弱性を見つけるためのスキルを反映した変数DS/ASを掛けよう。適当な推測として、AS = DS × 5としよう。攻撃者はこの目的のためにLLMを専ら使っているから。これらの数値を代入すると、Xが新しい力の差になる：X = (A × L × AS) ÷ (D × L × DS) X = (D × 10 × 10 × DS × 5) ÷ (D × 10 × DS) X = 50。もし計算が合っていれば、攻撃者と開発者の間の力の差が10から50に跳ね上がる。もしLLMが生産性を×100にするなら、新しい差は500になる。多くの（特に小規模な）開発者は、専用のハッキングチームと同等の計算能力を持つリソースすらないかもしれないことを考慮していない。バランスを戻す方法としては、OSSモデルを捨てて「信頼できるコンピューティング」に全力を注ぐことが考えられる。どちらの対策も、攻撃者が費やす必要がある努力（計算）を増やすけど、どちらも企業にますます権力とコントロールを与えるため、非常に人気がない。こういう意味で、LLMの台頭は確かに彼らの利益を進めているね。

世界はレガシーソフトウェアに依存していて、LLMに脆弱性を見つけてもらうための予算すらないし、修正することは言うまでもない。確かに守る側に有利になるべきだけど、実際には多くの重要なケースで守る側が存在しないから、これは大惨事だよ。

そうだね、同意する。混乱の時期を経て、攻撃者と守る側の間に新しい均衡が生まれるだろう。LLMが既存のソフトウェアについての知識をエンコードしているけど、新しいものについてはそうでないという新しい「メタ」を考慮すると、新しく書かれたソフトウェアは、実際のセキュリティの観点からは設計が悪いとしても、LLMによって本質的に悪用されにくくなると思う。

そうそう、記事では攻撃者が一気にいろんな攻撃を試せるから有利に見えるけど、防御側は一つの製品だけ守ればいいからその点では有利だよね。ただ、攻撃者がパッチが難しいソフトウェア（組み込み系）で穴を見つけやすいってのは、確かに問題だね。