本動画は、人気のあるオープンソースカレンダーアプリ「Cal.com」が、AIによるセキュリティリスクの増大を理由にコアコードをクローズドソース化した出来事をきっかけに、ソフトウェア開発におけるオープンソースの未来と直面している危機について解説したものである。AIモデルの進化により、ソースコードから脆弱性を発見するコストが激減し、セキュリティ確保が「どれだけトークン（コスト）を消費できるか」というプルーフ・オブ・ワークのような経済的競争に変貌しつつある現状を指摘し、それでもなおオープンソースを支持し守り抜く重要性を強く訴えかけている。
Cal.comのクローズドソース化という衝撃
最近の私の動画を見てくれているなら、私が以前にも増してオープンソースの強い支持者になっていることをご存知でしょう。もちろん以前からそうではなかったわけではありませんが、私たちがソフトウェアをオープンソース化し、オープンソースのコミュニティを支援し、そして互いの技術の上に積み上げていけるような方法で開発を進めることが、今かつてないほど重要になっていると思うのです。私たちが自分たちの作ったものをオープンソース化するのをやめてしまい、毎日頼りにしているソフトウェアがどんどん劣化してずさんになり、それを修正する手段すらなくなるような未来を、私は本当に恐れています。だからこそ、Cal.comのチームからの今回の発表には、恐怖を感じているのです。ご存知ない方のために説明すると、Cal.comはCalendlyのオープンソースの代替となるサービスです。少なくとも以前はそうでした。なぜなら、今はもうオープンソースではなくなってしまったからです。
そして、これは本当に多くの理由で最悪な出来事です。Cal.comは最初期のT3スタックアプリの一つでした。T3スタックという概念が生まれる前から存在していたほどです。そして私たちはよく、Calこそがこのスタックがどのようなものかを示す最高の例の一つだと冗談交じりに話していました。彼らは一時期、パフォーマンスを向上させるためにスタックを改善する目的で、tRPCのクリエイターであるAlexを雇用していたことさえありました。彼らは歴史的に、これを優れた大規模なTypeScriptアプリケーションにおける最高のフルスタック例の一つとして維持してきました。大規模なオープンソースのフルスタックTypeScriptによるNext.jsアプリの最良の例の一つであるため、コンパイラのテストやデモ、TypeScriptからGoへの書き換えの変更などにも使われてきたほどです。
そして、それがもう使えなくなってしまったのです。これは本当に最悪です。特に、オープンソースがいかにビジネスにとって素晴らしいものであり、私たちが進むべき方向であるかについて2つの動画を出したばかりのその直後ですからね。ここで皆さんには、少し内情をお話ししようと思います。私はCalのチームとは良い友人関係にあります。この件については少し前から彼らと話し合っていましたし、私が先ほどの2つの動画を撮影した時も、彼らとの会話が絶対に頭の中にありました。だからこそ、ビジネスはオープンソースの上に構築すべきであるという直近の動画で、Calを例として挙げたのです。私は、この変更を防ぐためのプレッシャーをかけられるのではないかと期待していましたが、失敗に終わりました。そして、なぜ彼らがそう決断したのかについて、深く掘り下げて話したいと思います。なぜCalはソースをクローズにすることが最善の策だと考えているのか、そしてそれがどのようにソフトウェアの未来を破滅させる可能性があるのか。この問題は私を恐怖させますが、議論すべき重要なテーマです。
スポンサーメッセージ：WorkOSの紹介
そして、もし私が大切に思っているオープンソースのプロジェクトを作り続け、資金を提供し続けるつもりなら、何らかの方法でその費用を捻出する必要があります。皆さんから料金を取る代わりに、今日のスポンサーのために少しだけ時間をいただきます。T3 ChatやCursor、そしてVercelの全てが全く同じ間違いを犯したと言ったら、皆さんはおそらく混乱するでしょう。そして、私たちが皆同じ方法でそれを解決したと言ったら、さらに混乱するはずです。この引用だけではあまり助けにならないことは分かっていますが、説明させてください。私が今挙げた会社は全て、認証システムで失敗しました。T3 ChatとVercelは独自の認証システムを構築し、CursorはAuth0を採用しました。そして私たち全員がそれを後悔しました。その後、私たち全員がWorkOSに移行し、今は皆、はるかに満足しています。
ずっと前のことになりますが、Guillermoが私を脇に引き寄せました。というのも、私が独自の認証システムをホストするという認証の混沌を経験し、それが間違いだったと気づいた後、彼もVercel全体について同じような後悔を抱えており、そのことについて話したかったからです。私はプライベートな情報を共有したくなかったので、このことについて話すのをとても恐れていました。しかしその後、彼はWorkOSのチームにも全く同じことを伝え、今ではそれが彼らのウェブサイトに掲載されています。Guillermoによれば、もっと早くWorkOSと提携していれば、もっと多くのビジネスを展開できていたはずだそうです。このサービスは信じられないほど好評を得ており、最初の100万人のユーザーは無料なのですから、WorkOSから始めない理由はありません。私たちが犯したような間違いをしないでください。ぜひ、sidyv.link/workosで認証を正しく設定してください。
オープンソースが直面するAIによる新たな脅威
「オープンソースは死んだ。」これは、私たちが口にするとは思いもしなかった言葉です。Calはオープンソースの上に構築されました。それが私たちの製品、コミュニティ、そして成長を形作ってきました。しかし、世界は私たちの原則が追いつけないほどの速さで変化してしまいました。AIはセキュリティの状況を根本的に変えてしまったのです。かつては時間と専門知識、そして意図が必要だったものが、今では大規模に自動化できるようになりました。コードはもはや単に読まれるだけのものではありません。ほぼゼロのコストでスキャンされ、マッピングされ、悪用されるものへと変わったのです。そのような世界において、特に大規模な場合、透明性はそのまま露出というリスクになります。
多くの熟考の末、https://www.google.com/search?q=%E7%A7%81%E3%81%9F%E3%81%A1%E3%81%AFcorec.comのコードベースをクローズにする決断を下しました。これはオープンソースが私たちに与えてくれたものを拒絶するものではありません。AIがもたらすリスクに対する対応なのです。私たちは引き続きビルダーたちを支援し、趣味で開発する人やハッカー向けに、新しいMITライセンスのオープンソースプロジェクトとしてコアコードを公開します。しかし、私たちの現在の優先事項はシンプルです。いかなる犠牲を払ってでも、顧客とコミュニティを守ることです。これは最も人気のある決断ではないかもしれませんが、多くの企業が同じ結論に至ると私たちは信じています。
現在起きているあらゆる混乱をすべて結びつけて考える上で、Project Glass Wingは考慮に値するものです。もしご存じない方で、私がAnthropicのMythosについて出した動画を見ていない場合は、まずそちらを見ることをお勧めします。また、ソフトウェア全体のセキュリティに関する私の動画も合わせて見てください。なぜなら、セキュリティの分野は現在、根本的なレベルで変化しているからです。
歴史的に見て、ソフトウェアとソフトウェア内のセキュリティを十分に理解している人の数は非常に限られていました。それは単に何が間違っているかを見つけ出し、企業がそれを修正するのを手伝うためだけでなく、すべてのソフトウェアに存在するような深いセキュリティ上の欠陥を実際に構築し、悪用できるレベルの知識を持つ人のことです。ソフトウェアを効果的に悪用するためには、ソフトウェアを深く理解する必要があります。エクスプロイトについてよく理解している必要があるのはもちろんですが、自分が悪用しようとしている特定のソフトウェアがどのように機能し、その境界がどこにあり、各パーツがどのように相互作用しているかなど、多くのことを理解していなければなりません。
バイナリをリバースエンジニアリングしたり、私たちが毎日使っているコンパイルされたソースやJavaScriptのアプリを調べたりすることで、外部からそうした事柄についてある程度の理解を構築することは可能です。自分が侵入したり、ハッキングしたり、エクスプロイトを見つけようとしているシステムについてより深い理解を築くための戦略はたくさんあります。しかし、ソースコードを読むことができ、それらのパーツ間の関係性を確認できれば、そうした作業はずっと簡単になります。そして、AIが同じような理解を構築できるとすれば、それはさらに容易なものになります。
ドメイン知識の壁を破壊するAI
エクスプロイトがどのように発生するかという仕組みは、比較的シンプルです。ある人のセキュリティに関する知識に、その人のドメイン固有の知識を事実上掛け合わせたものです。この2つの組み合わせが、大規模なエクスプロイトを生み出します。自分が扱っている領域を理解している人。それが、実際に扱っているコードのソースであれ、コードが実行されるシステムやそのシステムの癖であれ、自分が狙いを定めているドメインの知識は、セキュリティの知識と同じくらい本当に重要なのです。歴史的に見て、この2つの知識のどちらかを持っている人は少数でした。ですから、ある特定のドメインにおいて、そのドメインとセキュリティの側面の両方を理解している人は、さらに少なかったのです。
そのため、Cal.comのようなものは、それほど良いターゲットではありませんでした。セキュリティを熟知している人たちが、大規模なフルスタックTypeScriptプロジェクトの読み解き方を知らなかったからです。ですから、それがオープンソースであることは、平均的なセキュリティ研究者のドメイン固有の知識を意味のある形で変えることはありませんでした。彼らはフルスタックTypeScriptを理解していなかったからです。フルスタックのTypeScriptのコードベースがあったとしても、そのコードベースやそのプロジェクトに対する彼らの能力が大きく変わることはありませんでした。
ここのチャットにいるほとんどの人は開発者だと思います。ですから、皆さん全員に、セキュリティ研究者としての自分の能力にどれくらい自信があるか、0から10の間の数字をチャットに書き込んでほしいと思います。もしコードベースを与えられたとして、そこに存在する可能性のあるセキュリティ上の問題を見つけ出し、特定できる自信はどれくらいありますか？
3より高い数字はまだ見ていませんね。マイナス100というのも見えました。私が文字通り自分の仕事のセキュリティ監査をするためにお金を払っているNMGでさえ、6と書き込んでいます。ここにある数字のほとんどは、著しく低いものです。これが問題なのです。どちらか一方の側、例えばここでのドメイン側で強い人、つまりTypeScriptが本当に得意な人の場合、セキュリティが得意である可能性は下がります。逆に、セキュリティが本当に得意な人の場合、TypeScriptについて何も知らない可能性も下がるのです。
つまり、AIは必ずしもセキュリティに関する知識を豊富に持っているわけではありませんが、その他のすべてに関して奇妙なほどドメイン知識を持っているのです。ですから、フルスタックのTypeScriptアプリケーションのソースがあれば、AIはそのドメイン固有の事柄を理解することができ、あとは本当にエクスプロイトを見つけて一線を越えるためのほんの少しのセキュリティ知識があれば十分なのです。
以前はエクスプロイトを見つけるために、両方の分野で10段階中7くらいのレベルが必要でした。しかし今ではモデルが非常に優秀になったため、ドメイン固有の知識の面では文字通り0か1でも構わなくなりました。セキュリティ知識の面でも、おそらくもっと低くて済むでしょう。壁に向かってとにかく大量の処理を投げつけることができるので、10段階中4くらいでも十分かもしれません。そして今、このレベルの知識で、現実の深刻で合法的なエクスプロイトを見つけることができるのです。
これはとてつもなく大きな変化です。この能力を持つ人が世界に数千人しかいなかった状況から、過去にCTF（キャプチャー・ザ・フラッグ）をやったことがある人の大半が突然その能力を持てる状況になったのです。このギャップこそが、ここで非常に恐ろしい点です。AIは、必要とされるドメイン固有の知識の最低ラインを底まで下げてしまいました。そして、必要とされるセキュリティ知識の量もかなり下がりました。
これが、コードの質が悪いフルスタックTypeScriptの開発者だけの問題だと思っているなら、Mythosのプレビュー版がOpenBSDから27年前の脆弱性を発見したことを思い出してほしいと思います。OpenBSDは、世界で最も慎重に作成され、維持されているコードベースの一つです。これはLinuxよりもはるかに安全であるとほぼ間違いなく言える唯一のLinuxの代替であり、私たちのルーターやファイアウォールから送電線に至るまで、あらゆるものを動かすための信頼できるコアとなることに焦点を当てています。そのOpenBSDがAIに乗っ取られたというのは、本当に恐ろしいことです。
しかし、AIがそれを実行できた理由の一部は、ソースコードをターゲットにしたからです。Anthropicがこれらの脆弱性を見つけた方法は、コードベース内のすべてのファイルを調べ、エージェントを立ち上げて「私たちはこのコードベース内でCVE（共通脆弱性識別子）や潜在的なエクスプロイトを探している。このファイルから始めてシステムをトレースし、何か興味深いものがないか見つけ出せ」と指示するスクリプトを書くことでした。彼らは事実上、コードベース内の各ファイルを起点として、もっと多くの出力を生み出すためのシード関数のようなものとして使っているのです。
そして、この処理をコードベース内のすべてのファイルに対して実行するだけで、念のために言っておきますが、実行時にその1つのファイルに留まっているわけではありません。それは単なるエントリーポイントです。この1つのファイルから始めて、他の要素を探すためにコードベース全体を調べていくのです。彼らは以前にもOpusでこれをやりましたが、今回はMythosでこれを実行し、恐ろしいほどの脆弱性を大量に見つけ出しました。これらの作業はどれも、狂気的なハッキングの専門知識を必要としません。それは、15歳のバイブコーディングをする若者のほとんどが思いつくような気の利いたアイデアにすぎません。
そして誰かが、「つまり、ハッカーを手助けするためにAIを訓練しているということか？」と言いました。いや、絶対に違います。それは彼らがトレーニング中に行ったことではありません。それはモデルが訓練された後に彼らが行った実験です。彼らはモデルにハッキングを教えたわけではありません。コーディングを教えたのです。ここで私が言いたいのは、モデルのコーディング能力が向上したということは、この方程式の半分が崩壊したということを意味しているということです。
一般の人が巨大なエクスプロイトを見つけて世界を乗っ取るための2つの障害は、セキュリティについて十分な知識がないことと、ドメインについて十分な知識がないことでした。今や、ドメイン知識はもはや問題ではありません。ですから、唯一の障害はセキュリティ知識だけです。そしてそのハードルさえも下がってしまいました。今や必要なのは、ほんの少しの賢さと、トークンを燃やすための十分なお金を持つことだけです。それだけです。そしてそれが恐ろしいのです。
そして、ここでうまくいく方法の一つが、モデルにすべてのファイルから始めてすべてをトレースするように指示することによる総当たり攻撃だとするなら、ファイルを手元に持っている方がはるかに簡単になります。これらのAIモデルや、彼らが使用するエージェントやテスト用ハーネスは、信じられないほどの難読化解除作業を行うことができます。コンパイルされたプログラムや縮小化されたJavaScriptを取り込み、根本で何が起きているかを理解し、いくつかのセキュリティ上の問題を見つけることができるような形で元の状態に戻すことができるのです。
しかし、これらのモデルは、ソースコードに直接アクセスできる場合のほうが、その作業をはるかにうまくこなします。もう一度ここに戻りますが、私たちが考えているこの関数において、コードがオープンソースであれば、モデルはそのソースを持っているため、そのドメインを乗っ取るために必要なツールとテクニックをすべて持っていることになります。モデルはソースコードのナビゲートの仕方をよく知っています。コードを理解しており、ここでは圧倒的な力を発揮します。
しかし、難読化解除やリバースエンジニアリングについてはそれほど理解していません。ですから、既存の既知のソースコードを解析するのと同じくらいうまく逆コンパイルすることはできないでしょう。したがって、ソースを隠せば、ここでうまくやるために必要なドメイン専門知識のレベルは、今のところ10段階中4くらいに跳ね上がるでしょう。しかし、モデルの難読化解除と逆コンパイルの能力が十分に向上したらどうなるでしょうか？これもまた1レベルに落ちてしまうでしょう。
ですから、Calがここでやったことに対する私の最初の反論は、単に彼らが時間を稼いだだけであり、しかも大した時間を稼げてはいないということです。彼らは、エクスプロイトを見つけるためのハードルが下がることを恐れています。だからこそ、そのハードルを一時的に少し上げるためにこの変更を行ったのです。5年前のレベルではありませんが、このAI技術がいかに強力であるかを考慮すれば、少しは理にかなったレベルです。しかし、この優位性もすぐに失われると私は推測しています。
スクラピングと時間の制約を超えて
ここでAidenから良い指摘がありました。「これは、フロントエンドのクライアントからバックエンドのエンドポイントや技術をスクレイピングして見つけ出せない限り、逆コンパイルする対象となるバイナリを常に持っていることを前提としていませんか？」
その通りです。それがここでの重要なポイントです。その差の一部を補うために、十分なスクレイピングを行うことは可能です。一方で、クライアントは、クライアントが接続するすべてのものへのアクセスを提供してくれます。この場合、使用しているすべてのエンドポイントですね。ですから、そこから多くの情報を得ることができますが、バックエンドのコードは手に入りません。しかし、アクセスされるすべてのサービスと、無限の時間を手に入れることができます。
これが、先ほどここには含めなかった、絶対に含める価値のあるもう一つの要素、時間です。これらのものをテストし、実行するための時間をどれくらい持っていますか？セキュリティの知識とドメイン固有の知識の両方に長けている人は、往々にして時間が足りないものです。ですから、そうした人々が、ランダムなオープンソースのプロジェクトを乗っ取るための十分な空き時間を持っている可能性は非常に低かったのです。
しかし、時間を気にしないエージェントの群れがいて、一度に何時間も夜通し稼働させたままで、常に悪用できそうなものを探し続けるループを実行させることができたらどうなるでしょうか。そのとき、私たちが今日直面しているようなCVEの嵐に行き着くのです。
では、他の人たちはこの件について何と言っているでしょうか。Tannerはほぼ即座に議論に加わり、こう言いました。「AIがあなたのオープンソースコードを読むことがビジネスに悪影響を与えているなら、あなたはおそらくオープンソースを哲学としてではなく成長戦略として利用しているのだろう。そして今、それをクローズにしたからといって安全になるわけではない。単に、善意の開発者があなたのコードを堅牢にする機会が減り、より多くの悪意ある攻撃者があなたの本番サーバーにAIを向けるようになるだけだ。」
いやあ、これは見事な意見ですが、これにはいくつか層があります。コードを堅牢にするという話題については、これも話す価値があることです。
セキュリティはプルーフ・オブ・ワークへ
今日、OpenAIが新しいモデル「GPT-5.4 Cyber」を発表しました。このモデルの目的は、事前にコードベースを堅牢化するために使用できるというものです。アクセスするにはホワイトリストに登録される必要があると思います。私でさえまだアクセス権を持っていませんが、その目的は、重要なソフトウェアを構築している企業やビジネス、開発者が、エージェントが彼らに対して使用される前に、自社のソフトウェアを簡単に堅牢化できるようにすることです。
セキュリティというのは常に、ソフトウェアを守ろうとする人たちと、それを悪用しようとする人たちとの間の軍拡競争です。そのループはより短くなろうとしており、OpenAIとAnthropicの両社が、これらのツールが悪意を持つ可能性のある攻撃者の手に渡る前に、このソフトウェアを構築している人々がそれを修正するチャンスを得られるよう、特別な努力を払ってくれていることに感謝しています。攻撃者と防御者というのが公式な業界用語ですね。私がこうした話題を話している時に、的確な指摘をしてくれるNMGに感謝します。
逆コンパイルに関しては、将来的には常に収束していくだろうと合理的に予想できます。しかし、セキュリティのエクスプロイトに関しても同じかどうかはわかりません。特にバックエンド側では、逆コンパイルはそれほど重要にはならないと思いますが、フロントエンド側を逆コンパイルして、どのエンドポイントが叩かれているかを把握し、それらの要素を総当たりで突破しようとすることは可能になるでしょう。
ここには非常に現実的なセキュリティ上の問題があります。私が知る最高の開発者たちでさえ、私たちのほとんどが、私たちがどれほどひどい状況に置かれているかを本当に理解できていないと思います。私たちが常に乗っ取られずに済んでいる唯一の理由は、幅広い知識を持つ本当に賢い人たちによる、あまりにも多くのエリートレベルの注意と努力が必要であり、彼らにとって適当なプロジェクトからエクスプロイトを見つけることは、時間を費やす価値がなかったからです。それが変わってしまったのです。そして、その変化こそが恐ろしいのです。
しかし、ここでPeterが言うように、もしご存じない方のために説明すると、PeterはOpenCallのクリエイターで、現在はOpenAIにいます。「GPT-5.4 Cyberのクローズドソースの仕組みをリバースエンジニアリングする能力を見るなら、残念な知らせがある。しかし、その痛みはとてもよくわかる。OpenClawの穴を突こうとするチームは何百と存在する。私たちの対応は、コードの堅牢化を急速に繰り返すことだった。それによって時折リグレッションを引き起こし、そう、皆さんはそのことで私に怒鳴り散らしてきたわけだが、私はこれ以外に前に進む道はないと考えている。この作業を無視し、アドバイザリを公開しない他のオープンソースプロジェクトやハーネスには、非常に気をつけるべきだ。」
Sim Wilsonもここで議論に加わり、Drewの非常に興味深い記事をリンクしました。彼は、LLMによる分析を通じてソフトウェアを保護するコストがかかるからこそ、オープンソースは今、より価値が高まっていると主張しています。サイバーセキュリティは今やプルーフ・オブ・ワークのように見えます。さて、セキュリティの側は、攻撃者よりも多くのトークンを消費するのでしょうか？
プルーフ・オブ・ワークという言葉に馴染みがない方のために説明すると、これは主に暗号資産の世界で一般的な概念ですが、CAPTCHAのようなものにも使われています。これは、否定的で有害な作業を遅らせるための方法です。暗号資産においては、その取引を署名し承認するために実際の計算処理が行われたことを証明することで、取引が本物であることを証明する方法です。より伝統的なCAPTCHAの場合、あるアクションを実行することを許可される前に、実際のCPU使用率を要する複雑な問題を解決させる方法です。
ですから、もし私たちがT3 Chatにプルーフ・オブ・ワークのCAPTCHAを実装した場合、あなたのコンピュータは、あなたが望むアクションを実行する前に、それが本物のアクターであることを証明するためにプロセッサを回転させて何らかの処理を行う必要があります。なぜこのようなことをしたいかというと、自分のサービスを攻撃するコストを高くしたいからです。もしT3 ChatにCAPTCHAがなかったら、皆さんは無料枠の適当なエンドポイントを叩いてレスポンスを生成するだけで、事実上無料で私たちのエンドポイントを使って何かを生成できてしまいます。
プルーフ・オブ・ワークは、単にボットで自動化できないようにすることで、それをあまりにも高コストなものにする方法なのです。パズルを解き、作業を行い、実際に計算処理が行われたことを証明して承認を得るには、実際の処理能力を持つコンピュータが必要になります。ですから、「サイバーセキュリティは今やプルーフ・オブ・ワークのように見える」と言うのは、これが資金力に行き着くと言っているのです。誰がより多くのお金を喜んで支払うかということです。
もしあなたが私のエンドポイントを1つ使って私に1ドルのコストをかけさせることができ、プルーフ・オブ・ワークに50セントしかかからないなら、あなたは私のエンドポイントにスパムを送ることで、自分の支出を50％節約する方法を見つけたことになります。ですから、攻撃しようとする側が、攻撃の成果よりも多くのコストを費やさなければならないように、このバランスを取るのです。
それが複雑なバランスというものです。もし私から1ドルを奪うのに50セントしかかからないなら、あなたは私からたくさんのお金を奪うでしょう。しかし、私から1ドルを奪うのに2ドルかかるなら、あなたはそのようなことを頻繁には行わないはずです。そしてそれが、私たちがサイバーセキュリティで向かっている方向なのです。どちらがより多くのお金を使っているか？セキュリティ側か、それとも攻撃者か？これは非常に恐ろしいと同時に、非常に現実的な枠組みです。
Anthropicの脅威的なセキュリティ能力
先週、私たちはAnthropicのMythosについて知りました。これはコンピュータのセキュリティタスクにおいて驚くほど高い能力を持つ新しいLLMであり、Anthropicはこれを一般公開しませんでした。その代わり、重要なソフトウェアの製作者にのみアクセス権が与えられ、彼らのシステムを堅牢化する時間が提供されました。
私たちは、AIに関する大げさな主張を処理する標準的な段階をあっという間に通り抜けました。ショック、実存的な恐怖、誇大宣伝、懐疑論、批判、そして最後に次の話題への移行です。私は人々に、様子見のアプローチを取ることをお勧めします。なぜなら、セキュリティ機能は印象的なデモを行うために特別に調整されていることが多いからです。エクスプロイトを見つけることは、明確に定義され、検証可能な検索問題です。複雑なシステムを構築するのではなく、すでに存在するシステムをつつき回すのですから。これは、数百万のトークンを投げつけるのに非常に適した問題です。
昨日、AI安全研究所からの最初の第三者分析が発表され、大部分においてAnthropicの主張を裏付ける結果となりました。Mythosは本当に優れています。サイバーパフォーマンスがすでに急速に向上していた環境において、以前のフロンティアモデルからさらに一段階レベルアップしています。彼らのレポート全体は一読の価値がありますが、彼は、さまざまなモデルがシミュレートされた複雑な企業ネットワーク攻撃を成功裏に完了する能力を詳述したこのグラフに焦点を当てたいと考えています。
これは恐ろしいことです。OpusとMythosは、リバースエンジニアリングや暗号分析のようなタスクに到達するために完了できるステップ数において、意味のある改善を遂げました。5.4はウィキのエクスプロイトや認証情報の再利用のラインをわずかに超えているだけです。ええ、これは非常に恐ろしいグラフです。
「ラストワンズ」と呼ばれるこのベンチマークは、初期の偵察からネットワークの完全な乗っ取りに至るまでの32ステップにわたる企業ネットワーク攻撃のシミュレーションであり、ASIは人間が完了するには20時間かかると見積もっています。しかもこれは、自分が何をしているかを本当に理解している有資格の人間の場合です。実線は複数回の実行における平均パフォーマンスで、Mythosは10回、Opus、GPT-4o、5.4の最大値を示す線は各バッチの最高結果を表しています。
Mythosは、10回の試行のうち3回タスクを完了した唯一のモデルでした。そして、それがこの線が意味するものです。最大値は成功を意味し、完全なネットワークの乗っ取りを実行できたのです。これまでそれを達成できたモデルはこれだけです。恐ろしいことです。
このグラフは、興味深いセキュリティの経済学を示唆しています。システムを堅牢化するためには、攻撃者がエクスプロイトを実行しようとして消費するトークンよりも、多くのトークンをエクスプロイトの発見に費やす必要があります。ASIは1回の試行につき1億トークンの予算を割り当てました。これはMythosの1回の試行につき1万2500ドルです。彼らが行った10回の実行すべてで12万5000ドルです。つまり、10回の実行のうち3回が実際に成功するために、12万5000ドルがかかったということです。
これは大金ですが、それでも本当に恐ろしいことです。憂慮すべきことに、1億トークンの予算を与えられたモデルのうち、収穫逓減の兆候を示したものはありませんでした。テストされたトークン予算全体にわたって、モデルはトークン予算が増加するにつれて進歩し続けました。お金を投入し続ける限りエクスプロイトを見つけ続けるのであれば、セキュリティは残酷なまでに単純な方程式に還元されます。
システムを堅牢化するには、攻撃者が実際にエクスプロイトを行うために消費するよりも多くのトークンを、エクスプロイトの発見に費やす必要があるのです。賢いからといってポイントがもらえるわけではありません。より多く支払った方が勝つのです。これは、成功が純粋な計算作業に結びついている暗号資産のプルーフ・オブ・ワークのシステムと呼応するシステムです。これは温度の低い宝くじのようなものです。トークンを買い、おそらくエクスプロイトを見つける。うまくいけば、攻撃者よりも長く試行を続けることができます。
第一に、オープンソースソフトウェアは依然として極めて重要です。AIマキシマリストに触れたことがない人にとって、この発言は馬鹿げているように聞こえるでしょう。しかし最近、LightLLMとAxiosのサプライチェーンの恐怖の後、多くの人がコーディングエージェントを使用して依存関係の機能を再実装することを主張しています。
これはつい数週間前のKarpathyの言葉です。「古典的なソフトウェアエンジニアリングは、依存関係は良いものだと信じ込ませようとします。私たちはレンガでピラミッドを構築しているのだと。しかし彼の意見では、これは再評価される必要があり、だからこそ彼は依存関係をますます嫌うようになり、可能であれば単純な機能はLLMを使って引き抜いてくることを好むようになっています。」
もしセキュリティが純粋にシステムにトークンを投げつけるだけの問題であるなら、「十分な目があれば、すべてのバグは浅い」というリーナス・トーバルズの法則は、今やトークンを含むように拡張されます。オープンソースライブラリに依存している企業が、それらを保護するためにトークンを消費するなら、あなたの予算が許すよりも安全になる可能性が高いでしょう。
そうですね、事実上、双方の予算を合算しているからです。ここでの例に戻ると、これらの実行には1億トークンの予算がありました。10回のうち3回が成功しました。しかし、それを10の異なる組織、10の異なる攻撃者が消費していると想像してみてください。一人の消費が他の人の利益になることはあり得ません。ですから、加算されるわけではありません。しかし、10の異なるグループがプロジェクトのセキュリティ保護に1億トークンずつ貢献すれば、それらは加算されます。
ですから、50パーセンタイルのエクスプロイトを見つけるための基準が2億トークンであり、セキュリティ側でも大体同じだと仮定すると、3人が1億トークンずつ投入すれば、平均して、ハッキングに2億トークンを費やす1人に対して、比較的よく保護されることになります。したがって、多くの企業がセキュリティ確保に努力を注いでいるこれらのオープンソースプロジェクトは、より安全になるはずですが、ここには複雑さがあります。広く使われているオープンソースプロジェクトをクラッキングすることは、一度きりの実装をハッキングするよりも本質的に価値があるため、攻撃者はこれらの大きなオープンソースのターゲットにさらに多くの資金を費やす動機付けとなるのです。
新たな開発サイクルとオープンソースの責務
第二に、堅牢化はエージェントによるコーダーにとって追加のフェーズになるでしょう。すでに開発者がプロセスを開発とコードレビューの2つのステップに分け、各フェーズに異なるモデルを使用することが多くなっているのを目にしています。これが成熟するにつれて、このパターンに合わせた専用のツールが登場してきています。Anthropicは、1回のレビューにつき15ドルから20ドルかかるコードレビュー製品を発表しました。これは依然として馬鹿げた価格ですが、そう、前述のMythosの主張は妥当です。
私は、開発、レビュー、そして堅牢化という3段階のサイクルが見られるようになると予想しています。開発とは、機能を実装し、人間の直感とフィードバックに導かれて素早く反復する段階です。レビューとは、文書化、リファクタリング、その他の整理作業を非同期で行い、各プルリクエストでベストプラクティスを適用する段階です。そして堅牢化とは、予算が尽きるまで自律的にエクスプロイトを特定する段階です。
決定的なのは、最初のフェーズの制限要素は人間の入力であり、最後のフェーズの制限要素はお金であるということです。この性質により、これらは本質的に別々の段階になります。何かを作り上げる前に、なぜ堅牢化にお金を使うのでしょうか？以前は、セキュリティ監査はまれで、個別の、一貫性のないものでした。今、私たちは、最適と思われる予算内で、常にそれらを適用しなければなりません。
コードは、安全である必要がない限り、安価なままです。推論が最適化されてコストが下がったとしても、モデルがセキュリティ面での収穫逓減点に達しない限り、攻撃者よりも多くのトークンを買い続ける必要があります。コストはエクスプロイトの市場価値によって固定されているのです。そう、これは驚くほどうまくまとめられた記事であり、私たちが依存しているものにはもっと多くの支出力が必要だということに同意します。つまり、今こそオープンソースにさらなる努力を注ぐ必要があるということです。
これはまた、オープンソースプロジェクトがこの支出の方法をよりうまく受け入れる必要があるということも意味しています。もしFFmpegのようなプロジェクトが、セキュリティの発見に費やされる支出を「CVEの残飯」と呼ぶようなことがあれば、私たちは問題を抱えることになります。Googleはオープンソースソフトウェアのエクスプロイトを見つけるために、莫大な資金を費やしました。そして彼らはFFmpegに対し、FFmpeg内でほとんど使われていないコーデックに見つかったエクスプロイトについて、3ヶ月以上もの余裕を持たせて警告しました。
そのコーデックはFFmpegのほとんどのインストールに含まれています。ですから、これは非常に現実的で正当な問題なのですが、彼らはそれを低重要度とフラグ付けして無視したのです。そしてそれが公開されたとき、彼らはGoogleに対して怒り狂ったのです。
これはうまくいきません。事実上、セキュリティに多額の費用をかけることが必要となるこの新しいシステムの一部として、オープンソースのメンテナは対処しなければならない新たな負担を抱えることになります。そして私はその部分が嫌なのです。オープンソースプロジェクトが以前よりも多くの作業を負担しなければならないというのは、本当に最悪です。
なぜなら、今や彼らは優れたプロジェクトを作ろうと努め、イシューなどを通じて寄せられるあらゆる面倒な問題に対処し、それを安全にするために最善を尽くさなければならないだけでなく、あらゆる種類のさまざまなチャネルを通じて寄せられるこれらのセキュリティレポートのすべてに対処し、それらに遅れずについていき、維持するために最善を尽くさなければならないからです。
それは報われない仕事です。重要な仕事です。しかし、この作業は重要ではないふりをして、こうしたことを報告してくる人々を、AIを使ってCVEの残飯を作り出していると呼ぶのは馬鹿げています。ええ、FFmpegのTwitterアカウントを運営している人間が嫌な奴なので、私が5,000ドルを寄付した後、FFmpegは私をブロックしましたよ。でもそれは別の話です。
FFmpegのTwitterアカウントはメンテナによって運営されているわけではないので、Twitterの運営者について私に不満を漏らしてきたFFmpegのさまざまなメンテナについて皆さんにすべて話したくなる衝動を抑えることにします。ただ言ってみただけです。いずれにせよ、私たちはこのような態度を取るべきではありません。だからこそこれが問題なのです。
もしハッカーたちが、FFmpegがプロジェクトをより堅牢で安全なものにしようとする試みを無視していることに気づけば、彼らはエクスプロイトでそれを標的にするでしょう。オープンソースソフトウェアのメンテナからエクスプロイトを実行する許可を得る必要はありませんが、ソフトウェアのバグやセキュリティ問題を修正するには、絶対に彼らの許可が必要です。ですから、もしメンテナが潜在的なセキュリティ問題に関するフィードバックを受け入れる意志がないなら、ハッカーたちはその隙をついて悪用するでしょう。
この件について言いたいことはすべて言ったと思います。ここでCalのチームがどういう立場にいるのかは理解していますし、他のビジネスが、彼らがトークンを使ってシステムを保護するための資金援助に興味を持たないだろうということも理解しています。しかしそれでも、素晴らしいオープンソースプロジェクトがクローズドになるのを見るのは嫌なのです。そして、私たちがこの種の出来事を見るのは、これが最後にはならないだろうという嫌な予感がします。
オープンソースのために戦い続けてください。私たちが使い、頼りにしているプロジェクトを支援するために、できる限りのことを続けてください。さもなければ、未来は閉ざされたものになってしまうでしょう。私は今でも、ほとんどのビジネスにとってオープンソースが最良の選択だと信じています。それについてもっと詳しく知りたい場合は、私の前の動画を見てください。
しかし今は、これが今後の正しい選択であると企業に納得させるために、強く働きかけなければなりません。なぜなら、ますます多くの企業がこれらのエクスプロイトを目にし、「オープンであることは悪いことだ」と思い込み、そしてこれを閉鎖してしまうからです。
そして、私たちは決してそれを許してはなりません。恐怖を煽ることでオープンソースが殺されるのを許してはいけません。ですから、正しいことのために戦い続け、物事をオープンに保つようにプッシュし続け、私たちが使うツールを安全で、信頼性が高く、素晴らしいものに保つために働き続けてください。それでは次回まで、ピース、ナードたち。
コメント