AIの進化によりソフトウェアの脆弱性がかつてない速度で発見・悪用される現状を解説する。従来の90日間の開示猶予期間やオープンソースのセキュリティ文化が崩壊しつつある事態に警鐘を鳴らし、エンジニアや一般ユーザーが取るべき自衛策について考察している。
崩壊するセキュリティの前提と蔓延するエクスプロイト
主要なすべてのLinuxディストリビューションにおいて、732バイトでルート権限を取得できるCopy failの脆弱性が発見されました。さらにCopy fail 2、Xfirmを経由した非特権Linuxのローカル権限昇格、Dirty fragによる普遍的なLinuxの権限昇格などが続いています。進行中のサプライチェーン攻撃により、84のTanstack関連npmパッケージが侵害されました。Damned OBと呼ばれる、一般に公開されていながらまだパッチが当てられていない、スラブメモリから抜け出すことを可能にする攻撃もあります。Mythosがcurlの脆弱性を発見し、Whizのリサーチチームは、たった1回のgit pushでgithub.com上でリモートコード実行が可能になる脆弱性を発見しました。このGitHubの欠陥により、他のユーザーや組織に属する何百万ものリポジトリへの不正アクセスが可能になっていました。
私は皆さんに、セキュリティのアルマゲドンが来ると言っていました。しかし、ここまで残酷なものになるとは予想していませんでした。私たちが依存しているすべてのソフトウェアにおいて、これらの不条理で恐ろしいエクスプロイトが発見され始める速度は、信じがたいほどです。さらに信じがたいのは、問題が表面上よりも深刻であるということです。ありがたいことに修正されつつあるとはいえ、あらゆる場所でこれほど多くのエクスプロイトが発生しているだけでなく、業界としてこれまで考慮したこともなかった新しい攻撃ベクトルが登場しているのです。
私が警告を鳴らしているように聞こえるかもしれませんし、物事を大げさに言ったり言葉を大きくしたりすることで知られているのは分かっています。そんなことはどうでもいいのです。これは本当に大きな問題であり、なぜ人々がもっとこのことについて話さないのか私にはわかりません。私たちが今すぐこの問題に立ち向かわなければ、これは私たちが知っているソフトウェアの終わりを意味します。そして、過去数十年にわたって私たちが依存してきたセキュリティの文化は、現在の時代においてはもはや全く意味をなしません。ここで深く掘り下げるべきことがたくさんあります。ソフトウェアがどのように変化しているか。それに追いつくために私たちがどのように変化し続ける必要があるか。AIがどのようにしてこれらの発見や潜在的なハッキングすべてを加速させているか。そして最終的に、最も多くのトークンを持つ者が勝つ仕組みについてです。
私は気が狂いそうになっていますし、正直なところ、この動画でスポンサーの宣伝を入れることすら心苦しく感じています。しかし、私がソフトウェアを利用し、それに依存できる未来がないのであれば、どうにかして請求書を支払わなければなりません。ですから、少しだけ休憩を挟んでから、本題に入りましょう。
スポンサーメッセージ：BlacksmithによるCIの高速化
現在T3 Code、特にnightlyビルドを使用している方は、左下にあるアップデート利用可能という小さなボタンにお気づきかもしれません。良くも悪くも、それは今日のスポンサーであるBlacksmithのおかげです。彼らは私たちのCIを非常に高速化してくれたので、実際のコードが出荷されるたびにnightlyビルドを変更することにしました。Mac OSのビルドは非常に長く、Intelのビルドはほぼ9分、Mac ARMのビルドは6分以上かかっていました。そしてBlacksmithがMac OS用のランナーを追加してくれました。現在、私たちの総ビルド時間はわずか10分です。ARMとx64のビルドははるかに高速になりました。Macのビルド時間はほぼ半分に短縮され、ARMビルドは3分32秒になりました。Intelビルドについては半分以下に短縮され、3分34秒になりました。
この体験をしたのは私たちだけではありません。Ashbのような企業は、デプロイメントの回数を倍増させ、CIのコストを4分の3削減しました。はるかに高速で信頼性が高いだけでなく、失敗した場合でも、何が問題だったのかを把握するためのはるかに優れたコンソールが用意されています。さまざまなジョブで何が起こっているかを示す実際のログがあることがどれほど素晴らしいかご存知でしょうか。以前はGitHub Actionsを使用していて地獄のような思いをしていたので、これがどれほど良いものか知りませんでした。開発者とエージェントは、より優れたCIを利用する権利があります。今日、soy.v.link/blacksmith.h で入手してください。
Copy failの衝撃とエクスプロイトの容易化
今回はかなり狂った内容になります。フラッシュバン警告です。Copy failは終わりの始まりです。このエクスプロイトは本当に、本当にひどいものです。Linuxカーネル6の最新バージョンとカーネル7に存在するため、ほぼすべてのLinuxディストリビューションに存在する脆弱性です。どちらもアップデートされていますが、ディストリビューションがカーネルを定期的にアップデートしないことは非常に一般的です。そのため、ディストリビューションレベルでさらに多くのパッチを適用する必要がありました。Linuxディストリビューションと、それらがこれらの問題によってどのように不当な影響を受けているかについては、後ほど詳しくお話しします。
このエクスプロイトは、ネイティブなバイナリコードだけでなく、小さなPythonスクリプトのような単純なものを通じて、ルートへの些細な昇格を可能にします。これがどれほど危険かを説明すると、人気のあるPythonライブラリの配布者は、732バイトの恐ろしいけれども簡単に難読化できるPythonコードを含めるだけで、多くの人を簡単に乗っ取ることができたはずです。これは本当に、本当に深刻です。
エクスプロイトは非常に単純です。利用可能な長いウィンドウがあるメモリ内の特定のポイントから開始します。そこを通過し、実際よりも多くのメモリが利用可能であるかのように見せかけて操作を行います。インデックスを下っていくとウィンドウがスライドし、アクセスしてはいけないはずのメモリ領域を取得できてしまいます。これにより、ルートへの昇格からシステムファイルの書き換えまで、あらゆることが可能になります。これは本当にひどい状況です。ありがたいことにパッチが当てられましたが、それでもCopy fail 2やDirty fragなど、これと同じコア部分の上に構築された同様のエクスプロイトがすでに追加で現れています。
セキュリティ文化の崩壊とAIの台頭
つまり、非常に簡単に悪用できる新しいエクスプロイトが存在するということですね。いいえ、問題はさらに深いところにあります。私が、私たちはもう終わりだと言うとき、皆さんに理解していただきたいのです。私はここで単にクリック数を稼ごうとしているわけではありません。この動画は私に多くのお金をもたらすことはないでしょう。実際、おそらくある程度の信頼を失うことになりますが、今は本当に状況がひどいので、その事実を受け入れています。あらゆるソフトウェアエコシステムで起きているセキュリティ問題の膨大な量は、言葉で表現するのが難しいほどです。しかし、問題はその量だけではありません。プロセス全体がどのように覆されてしまったかということです。
ソフトウェアが安全に機能するために、私たちがソフトウェアの世界で依存してきた重要な真実がいくつかあります。第一の真実は、高給取りの専門家だけがエクスプロイトを発見できるというものでした。それはもはや真実ではありません。エージェントを正しい方法で、正しい場所で十分に長いループで実行させ、トークンに費やす十分なお金があれば、今日の実際のソフトウェアでエクスプロイトを見つけることができます。これは本当に恐ろしいことです。これについてはすでにたくさん話しましたが、以前から懸念していた2つの新しい問題があり、その懸念がエスカレートする速度が本当にひどいのです。
第二の真実は、90日間の開示プロセスで十分であるというものでした。ご存知ない方のために説明すると、エクスプロイトを発見した対象の企業やメンテナーに通知し、修正のための時間を確保し、パッチを配布し、世界中のシステムをアップデートさせ、最終的にこれを公に開示できるようにするためのCVEを申請することが一般的にベストプラクティスと考えられています。もしかしたら、その作業に対して報酬が支払われるかもしれません。しかし、それすら今はほとんど起きていません。パッチが当てられていないもの、あるいはパッチは当てられているけれどもまだ安定版にマージされていないものを開示している見知らぬブログ記事を何度見たかわかりません。
ああ、これは興味深いですね。この記事には以前もっと多くのデータが含まれていましたが、著者が実際に多くを編集して削除しています。以前は、このエクスプロイトはその後パッチが当てられたが、そのパッチは安定版には入っていないと言及されていました。そしてこれは、彼が自分のブログに投稿した単なる公開エクスプロイトです。良いことではありません。
しかし、2つ目のポイントは重要な3つ目のポイントと結びついています。パッチからエクスプロイトを作成するのは難しいということです。これが意味するのは、90日間の猶予期間に関連しています。あるカーネル、あるOS、あるプログラムにおけるメモリの割り当て方にバグがあり、あなたがこのエクスプロイトを発見し、そのプロジェクトのメンテナーに開示したと想像してみてください。彼らは、大規模なセキュリティホールを修正するというようなコミットを出すことはありません。X、Y、またはZにおける予期しない動作をパッチするというような、非常にシンプルなメッセージのコミットを出すでしょう。
そのパッチはプロジェクトに静かにマージされ、次のバージョンで配布され、一定の割合のユーザーがそのパッチを適用した時点で、公に開示されることになります。これは、ここでの1番目と2番目のポイントに連動する要素に依存していました。つまり、これを解明するためには一定レベルの知識と能力が必要だったということです。さらに重要なことに、これを悪用するためには、オープンソースであるすべての重要なプロジェクトのすべてのコミットに目を通し、セキュリティ問題をカバーするためのものかもしれないコミットを見つけるために時間を費やす必要がありました。
これにより、パッチがマージされてから実際に公開されて人々がアクセスできるようになるまでの間、そして人々がその問題を悪用できるようになるまでの間に、確実な時間的猶予が生まれていました。もちろん、もし本当にLinuxをハッキングしたくて、メーリングリストに多くの時間を費やし、すべてのコミットに目を通せば、何かを見つけることができるかもしれません。なぜなら、ほとんどのLinuxディストリビューションは比較的古いバージョンのカーネルを出荷しており、それ以上長く待つことはできないからです。これは本当に悪い状況です。
エンバーゴの形骸化とAIによるパッチ解析
ジェフ・カウフマンのこの記事は、90日間の開示プロセスの崩壊と、パッチからエクスプロイトへの移行という、最後の2つの脆弱性文化の要素が壊れつつあることの深刻さを浮き彫りにしています。1週間前、Copy failの脆弱性が公開され、フン・ウー・キムは修正が不十分であることにすぐに気づき、同日にパッチを共有しました。この際、彼は特にネットワーキング分野におけるLinuxの標準的な手順に従いました。バグをオープンな場で静かに効率的に修正しながら、クローズドなLinuxセキュリティエンジニアのリストとセキュリティへの影響を共有したのです。
彼の目的は、生の修正だけを公開することで、深刻な脆弱性が存在するという事実をエンバーゴ状態にすることでした。対処する立場にある人々は知っていますが、彼らは数日間何も言わないことに同意しています。しかし、他の誰かがその変更に気づき、セキュリティ上の意味合いを理解して、それを公に共有しました。ちなみに、それがCopy fail 2です。公開されてしまったため、エンバーゴは終了したとみなされ、今では完全な詳細を見ることができます。
脆弱性に対する2つの異なるアプローチの間の緊張関係を見るのは興味深いです。そして、AIの加速によってこれがどのように変化する可能性が高いかを考えてみてください。一方には、協調的な開示文化があります。これはおそらくコンピュータセキュリティにおいて最も一般的なアプローチです。セキュリティバグを発見した場合、非公開でメンテナーに伝え、修正するために一定の時間、多くの場合90日間を与えます。目標は、誰もその穴について知る前に修正が公開されることです。
もう一方には、バグはバグであるという文化があります。これはLinuxで特に一般的で、カーネルがすべきでないことをしているなら、どこかの誰かがそれを攻撃に変えることができるかもしれないという主張です。注意を引くことなく、可能な限り早く修正するだけです。あまりにも多くの変更が行われるため、人々は気づかないことが多く、マシンのパッチを適用する時間がまだあります。このアプローチは完璧に機能したことはありませんでしたが、AIが脆弱性の発見に優れてきている今、それははるかに大きな問題となっています。
現在、非常に多くのセキュリティ修正が公開されているため、コミットを調べることははるかに魅力的です。シグナルとノイズの比率が高くなっています。さらに、各コミットが通過する際にAIに評価させることは、ますます安価で効率的になっています。しかし、長いエンバーゴもうまくいっていません。歴史的な検出ペースは遅いものでした。何かを発見してベンダーに報告し、90日間の開示ウィンドウがありました。その間、他の誰も気づかない可能性が非常に高かったのです。
しかし現在、非常に多くのAI支援グループがソフトウェアの脆弱性をスキャンしているため、もはやそれは止まりません。今回のケースでは、キムがESPの脆弱性を報告してからわずか9時間後に、クァンティン・チェンも独立してそれを報告しました。繰り返しますが、9時間後です。2つの別々のグループが互いに9時間以内に同じ巨大なセキュリティエクスプロイトを発見することが、どれほど前代未聞のことかお分かりでしょうか。これは全く新しい前例のない事態です。
エンバーゴはリスクを増大させる可能性があります。誤った緊急性の欠如を生み出し、どの関係者が欠陥の修正に取り組めるかを制限してしまいます。著者は、これをどのように修正すべきか見当もつかないと述べています。私も同じです。しかし、非常に短いエンバーゴは、少なくとも良い出発点のようです。そして、時間とともにさらに短くならざるを得ないかもしれません。幸いなことに、ここではAIが攻撃者だけでなく防御者もスピードアップさせることができ、以前なら短すぎて役に立たなかったようなエンバーゴを可能にします。
大部分において同意します。ここには他にも多くの問題があり、特にシステムメンテナンスに関する問題があります。皆さんはどうかわかりませんが、私は今このアパートにある複数のデバイスで、複数のLinuxカーネルを動かしています。誰もすべてのLinuxマシンを十分に確実にアップデートしていないため、これらはほぼ確実にまだCopy failバージョン1に対して脆弱です。
しかし、この投稿の最も恐ろしい部分は、実はこの脚注です。脚注は、AIがパッチを適用している可能性のある潜在的なエクスプロイトを見つけるためにコミットを評価する能力が、どれほど優れているかを議論しているセクションに対するものです。記事の著者は、Copy fail 2のエクスプロイトを修正したコミットを取り上げました。それは、まともなメッセージといくつかの非常に小さな変更が含まれる比較的単純なコミットで、文字通り4行のコードが変更されただけでした。
彼らはこのコミットをGemini 31 Pro、GPT Thinking 5.5、そしてClaude Opus 4.7に渡しました。3つすべてが、コミットからすぐにそれを理解しました。コンテキストが少なくてもdiffがすぐに公開される仮想の未来を想像して、diffだけを与えた場合。Geminiはそれがセキュリティ修正であると確信していました。GPTはおそらくそうだろうと考え、Claudeはおそらく違うだろうと考えました。ああ、Claude。いずれにせよ、全体を通してみると、それらすべてが理解しました。しかし、コミットメッセージがなくても、コミットの変更そのものだけで、3つのうち2つ、最も性能の低いGemini 31 Proでさえ、これがセキュリティ関連である可能性が高いことを把握できたのです。
これは何が可能かを示すための非常に簡単なテストです。検索なしのプロンプトでそれぞれ1回実行しました。これはセキュリティパッチのように見えますか。対照群はありません。そして、モデル間の比較をあまり信用しないでください。はい。はい。ええ。これがどれほど悪いことか理解できますか。Linuxに入るパッチを監視し、それがセキュリティ関連であるかどうかをチェックするボットを、今や極めて簡単に立ち上げることができるのです。そして今、潜在的な脆弱性への早期アクセスと、それを悪用する能力を手に入れたことになります。
これらのAIが、パッチが当てられたものを利用するエクスプロイトを書くほど賢くないと思いますか。現実的に考えましょう。明らかに彼らにはそれができます。そしてそれが問題なのです。パッチからエクスプロイトへ移行することは、以前は困難でした。なぜなら、まずその変更がセキュリティ問題のパッチであることを特定しなければならなかったからです。次に、そのパッチがどのレイヤーを修正しようとしているのか、そしてどのような潜在的なエクスプロイトがそれを利用できるのかを解明しなければなりません。それからそのエクスプロイトを構築し、配布しなければなりません。
私たちが話しているのは、npxの何らかのコマンドを実行したり、Pythonの世界でuvxの何らかのコマンドを実行したりするのと同じくらい簡単に引き起こされるエクスプロイトについてです。これらのエクスプロイトはそれほど複雑ではありません。私が1日のうちにランダムなnpxコマンドを実行する回数は、おそらく多すぎるくらいです。これが問題です。
情報の非対称性とディストリビューションの危機
そして、もしこれらのパッチがカーネルコードに存在するものの、あなたが使っている特定のディストリビューションにまだ出荷されていない場合、あなたは完全に終わりです。なぜなら、今回開示を受けているのはLinuxのセキュリティエンジニアだからです。カーネルのセキュリティに取り組んでいる人々であり、私たちのディストリビューションを作っている人々ではありません。Ubuntuをメンテナンスしている人々、Arch Linuxをメンテナンスしている人々、CashiosやMint、Red Hat、あるいはそういったものをメンテナンスしている人々は、これらのセキュリティ問題について開示を受けていません。
一部のLinuxセキュリティエンジニアがそれを行うことが重要だと考え、通常の手順を回避して行えば、個人的に開示されることはあるかもしれません。しかし、ディストリビューションのメンテナーはこれらのことを知らされていません。彼らは何も知らないため、単にカーネルを更新し続けるよう丁重にお願いされるだけです。彼らはカーネルをメンテナンスしていないため、プロセスの外に置かれているのです。つまり、その上に構築している全員もまた、ある意味で終わっているということです。
ちなみに、これはLinuxに限った話であり、このような問題に見舞われているのはLinuxだけではありません。これらによってどれだけのものが影響を受ける可能性があるか、全くもって不条理なほどです。ディストリビューションのビルダーやメンテナーは、攻撃者が行っているのと同じように、gitのコミットや記事を監視して事態の深刻さを把握することはできないのでしょうか。
ええ、できるでしょう。しかし、ランダムなLinuxディストリビューションのメンテナーが、早く出荷すべき重要なパッチについての早期情報を得るために、ハッカーのように考えなければならないとは思いません。それはおそらく、ディストリビューションのメンテナーとLinuxカーネルの作者やメンテナーとの間に多くの軽蔑を生み出すでしょう。しかし、これが問題なのです。何ヶ月、何年もかかっていたタイムライン全体が数時間に短縮され、それに参加できる人数はごく少数から事実上無限にまで膨れ上がりました。
サプライチェーン攻撃の激化
そして繰り返しになりますが、これに対処しなければならないのは彼らだけではありません。JavaScriptの世界でもこれが起きています。私がライブ配信を始める直前に、Socketが84のTanstackパッケージが侵害されているのを発見しました。Tanstackチームも気づいていると私は信じています。公の詳細はまもなく発表されます。もう発表されているかもしれません。この攻撃は非常にニッチなCIキャッシュのエクスプロイトで、攻撃者がnpmにプッシュするためのトークンを潜入させるのではなく、彼らに代わってそれを行うPRを提出することを可能にするものでした。
Socketはその後、84の名称にわたってさらに121の侵害されたパッケージを発見しました。つまり、これは多くの人に影響を与えています。なんてことだ。もう終わりです。VercelのハッキングやCanvasのハッキング、その他の主要なハッキングについてさえ話していません。公にはまだ開示されていないものをいくつか知っていますが、私は幸運にも早い段階で知ることができたため、もし共有すれば自分が窮地に立たされる可能性があります。
しかしありがたいことに、私が知っているものはユーザーに直接影響を与えていないので、そうでなければ絶対にエンバーゴを破って共有していたでしょう。しかし、これほどひどい事態にはならないと私たちが信じていた企業が攻撃を受けているという事実は、これらの問題がどれほど深刻かを示しています。これは本当に、本当にひどい状況です。
AIがもたらす自動化された脅威
サプライチェーン攻撃がどのようにAIと関連しているのかについて、多くの人が懐疑的になっているのを見かけます。これらのことがAIなしで簡単に自動化できると思いますか。セキュリティ企業で働くのではなく、悪意を持ってこのようなことを行う能力を持つ人々の数が、それほど多いと思いますか。
AIのおかげで、これらのことを行う可能性は大規模に高まりました。AIのおかげでタイムラインは崩壊しました。AIのおかげでそれを行うために必要なスキルのレベルははるかに低くなりました。そして、提出されているパッチのようなものを発見する能力は、AIのおかげで非常に簡単になりました。以前は才能ある人々が時間をかけて多くの注意を払う必要があったあらゆる作業が、今ではforループで実行できるようになりました。それは恐ろしいことです。
私は、これがオープンソースからホスティングサーバー、ローカルシステム、ローカルネットワーク、そしてCanvasのハッキングが起きたときに地元の小学校が乗っ取られたらどうなるか、より多くの病院がランサムウェアの被害に遭ったらどうなるかなど、あらゆるものにとって何を意味するのかについて深く考えてきました。私たちが使用するすべてのソフトウェアがすでに侵害されていると想定しなければならない世界で、何が起こるのでしょうか。
この問題について2つの道筋で考えていきたいと思います。念のため言っておきますが、私はこの問題で精神的な限界に近づいています。夜も眠れないほど、本当に本当にひどい状態です。私がしていることについて話し、また業界レベルで何ができるかについても話します。まずこちらから始めましょう。私がしていることについては後ほど話します。
新しい情報開示の階層構造の必要性
では、ここで実際に何ができるのでしょうか。私たちが抱えている問題を見てみましょう。以前は、高給の専門家だけがエクスプロイトを発見できました。90日間の開示プロセスで十分でした。そして、パッチからエクスプロイトへの移行は困難でした。新しいものを構築するために、これらの3つの重要な要素の何らかの尊厳を取り戻すには、ソフトウェアの運用方法を根本的に変える必要があります。最初の要素は死にました。それはもう終わったことです。
Mythosがプライベートであり、公開で使用できないようにしたり、APIを叩いて操作したりできないようにすることや、Opus 4.7がセキュリティに関しては何もできないように強く制限されていることなど、この現実を軽減するための努力はあります。それらはある程度役立ちますが、オープンウェイトモデルもこれらのことを解明できるポイントに近づいています。たとえば、Kimmy K26のようなモデルにCopy fail 2のコミットを指し示して、それを悪用する方法を解明できなかったとしたら、私は本当に驚くでしょう。オープンウェイトモデルは、ここのパート2と3に関する作業を十分にこなせるため、状況は変化し、発見されるエクスプロイトのレベルは信じられないほど高くなっています。
したがって、1番目が事実上死んでいることを知った上で、2番目と3番目にどう対処すればよいでしょうか。これらのアイデアの何らかの形をどのように復元するのでしょうか。まず、この90日間の開示プロセスについて話すべきです。開示プロセスにはいくつかの問題があります。第一に、開示されるべきすべての人が開示を受けているわけではありません。これは先ほど話したLinuxディストリビューションのメンテナーや、さまざまな企業のITチームのような人々です。
情報が公開される前に彼らに通知される良いプロセスが存在しません。ただ2つの層があるだけです。開示を受けるのはメンテナーですが、ディストリビューションのメンテナーではなく、エクスプロイトされた特定のもの自体のメンテナーだけです。その上や下の誰も知ることはできません。そして、その他のすべての人々という層です。
私たちはこれらの間に新しい層を必要としています。中間層としての信頼できるアクターが必要です。検証済みであり、私たちが何らかの形で安全であると確認したデバイスのみを使用し、これらの人々が何らかのセキュリティプロセスを経て、監査を受け、SNSやIDなどを共有しているという知識の範囲で、できる限り安全であることが確認されている人々です。企業や重要なもののメンテナーが、公に開示される前に事態の深刻さを知るために、開示される当事者として含まれる機能が必要です。
以前は悪意のあるアクターが物事を悪用するのにかかる時間に依存していましたが、その時間がゼロになってしまったため、ここに中間のウィンドウが必要です。ですから、情報開示を受けることができ、事態の影響を受ける人々の新しい層が必要です。これはオープンソースがより多くのお金を稼ぐ方法にもなる可能性があります。Microsoftのような企業がこの情報を得るために、Linuxのメンテナーによる認定を受けるためにお金を払わなければならないというのは非常に理にかなっています。
しかし、私たちはこのようなことをしなければなりません。Ubuntuを作っている人々が北朝鮮のハッカーと同じタイミングで開示を受けるようなパイプラインでは生きていけないからです。それは機能しません。私たちがインストールしなければならないアップデートを作っている人々が、ハッカーと同時にこの情報を発見するような世界で長く生き残ることは絶対に不可能です。ハッカーはそれらの必須ソフトウェアのメンテナーほど速くは動かないかもしれませんが、彼らは確実にあなたや私が実際にシステムをアップデートするよりも速く動きます。ですから、より多くのリードタイムが必要です。私たちがここで行うことはすべて、より多くのリードタイムを確保するための試みです。
オープンソースの運用モデルの変革
しかし、これはほんの始まりに過ぎません。そしてここから、多くの人を怒らせるであろうことを話し始めます。オープンソースは根本的に変わる必要があります。これは辛いです。私はこれが嫌いです。これには多くの理由があります。そして、本当に奇妙な例を挙げます。皆さん、聞いてください。Claude Codeと、そのソースコードが現在2回漏洩していること、そして彼らがまだそれをオープンソース化していないことがどれほど不条理かについて少し話します。
Cloud Codeチームがコードをオープンソースとしてリリースしないことを選択した理由はいくつかあります。これには当然、ソースコードが漏洩した場合に発見される可能性のあるセキュリティ問題などの理由が含まれます。私たちは今、ソースコードを持っています。そこには大したことはありませんでした。あなたのマシン上で動作します。Bunで実行されています。比較的良好です。彼らが実際に懸念している主なことは、Claude Codeで彼らが取り組んでいる不完全で実験的なものを人々が見てしまうことです。
彼らが従業員や開示された当事者のみがアクセスできる新機能を出荷してテストし、それが機能しなければ非推奨にするということが何度も行われています。しかし、人々はこれらのことを見て非常に興奮したり、もしそれがオープンソースであれば、自分たちで追加しようとしたりするでしょう。私はチームについての知識と、そこで話をした人々に基づいて推測しています。しかし、彼らがソースを分割することが簡単な世界を想像してみてください。
彼らの公式なソースであり、私たちが公開バージョンで使用するすべてのものを含むオープンソースバージョンが存在しますが、彼らは時折まだオープンではない更新バージョンをリリースするでしょう。そして、このまだオープンではないバージョンが、彼らがおそらくアルファ版やnightly版として公開しているものになるでしょう。そして、それが一定の確信の閾値に達するか、クリーンアップされるか、あるいは配布の準備が整ったときに、彼らはそれをオープンソースバージョンに押し出すのです。プライベートなフォークリポジトリを持ち、一定のケイデンス、リリースサイクル、またはそうすることに快適なレベルに達したときに変更をアップストリームにマージするという、このようなことをすでに行っている企業は存在します。
私たちはさらに先へ進む必要があると思います。これまでの複数の動画で言ってきたように、より良いGitHubが必要だと思いますが、それはプロジェクトをオープンにでき、そのバージョンを構築するために必要なすべてがオープンであると同時に、新しい機能をステージングでき、特定のファイルをステージングでき、特定のPRをステージングして隠すことができるという、オープン性の粒度についてより優れたアイデアを持つGitHubです。すべてのコードがまだ公開されていなくても、後でそのコードを共有できるようなケイデンスで、公開リリースを行うことができます。もしかしたら、この信頼できるアクターのグループにいる人々にその一部を早期に共有するかもしれません。
私が想像しているのは、このようなフローです。ステップ1、Linuxのようなプロジェクトでセキュリティのエクスプロイトが発見される。ステップ2、彼らはそれにパッチを当て、ロールアウトがどのようになるか、そして現時点でどれだけ公に開示するべきか、あるいはすべきでないかを決定する。ステップ3、彼らはこの変更を、プライベートで半一時的にクローズされたステージングブランチにデプロイする。カーネルの新しいビルドを出荷する。そしてステップ4、これらの様々なディストリビューションをメンテナンスしている人々である信頼できるアクターに通知し、やあ、私たちは今出荷したばかりのこの変更を持っている。コードはまだ共有していない。私たちの言葉を信じてくれ。これはセキュリティ問題だ。できるだけ早く配布してくれ、と伝えるのです。
そして、もし何らかの理由で一部のメンテナーがそれができない場合は、別のレベルでそれから防御するプロセスを通じて彼らを導く。この安全が確保されたバージョンのソフトウェアが十分なレベルの配布に達したと判断されたら、彼らは公開通知を出し、これらのパッチをプライベートからパブリックに変更することができます。そしてそれでも、これは一時的な修正にすぎません。
このようなことは、オープンソースコードのライセンス形態から、プラットフォームによる配布方法、さらには2つのグループの間にいる信頼できるアクターである人々をどのように検証し確認するかまで、非常に複雑なものになるでしょう。ここには多くの複雑さがあります。私が提案していることが正気の沙汰ではないように思えることは分かっていますが、何もしないことはさらに狂気じみていると思います。
Gitはそのような仕組みにはなっていません。Apacheライセンスはそのような仕組みではありません。MITは、何が公開されていて何が公開されていないかをあまり気にしないため、少しはそうかもしれませんが、とにかく自分のやりたいようにやります。しかしそれでも、私たちが今日依存しているシステムはどれも、このようなことを可能にするようには構築されていません。しかし、私たちが今日依存しているシステムはどれも、私たちが現在経験している問題に対処するようには構築されていませんでした。
そして私たちは選択しなければなりません。すでに経験している差し迫った破滅に対処するために、オープンソースの考え方を変える覚悟があるのか。それとも、これは難しすぎるとして、問題はそれほど大きくないふりをし、世界中がオープンソースソフトウェアへのすべての信頼を失うのを見ているのか。なぜなら、私はどちらか一方しかないと思うからです。その中間はないと思います。
個人の自衛策とネガティブゼロトラスト
そこで、私が日々の生活の中で何をしているのか、そしてこの状況についてどう考えているのかについてお話ししようと思います。最初の大きなこと、そしてこれは辛く、最悪なことですが、すべてのシステムが侵害されているとして扱うことです。現時点では、私は自分の個人的な情報はすべて公開されていると単に仮定しています。私はインターネット上でそこそこ人気のある人物であり、私をからかうのが大好きな非常に技術的な視聴者を持っているので、これについては少し早めに気づいていました。ですから、すべてのデータを半ば公開されたデータとして扱わなければならないことには慣れています。
しかし、私はさらに踏み込んでいます。多くの人々はまだ、自分が大切にしているものが漏洩したり盗まれたりするのをどうやって防ぐかという状態にいると思います。私はその段階を過ぎました。自分が持っているものはすべて漏洩し、盗まれたと仮定しています。私が今防ぎたいのは、ランサムウェア型の攻撃です。多くの人が私のデータを持っていると予想しています。最悪ですが、それが現実です。
私はその逆を心配しています。私のデータの唯一のコピーが他の誰かに所有されていたらどうなるでしょうか。私や私のチームにとって重要なパイプライン、例えばYouTubeチャンネルや私たちが依存しているすべての資産、あるいは私たちが協業しているすべてのブランドとの取引やその進捗を追跡するすべてのデータベースがどうなってしまうのか。私のデータが侵害されて盗まれるだけでなく、破壊されて奪われてしまったらどうなるのかということです。
NCのこの枠組みは素晴らしいです。殺人鬼がすでに家の中にいると仮定すれば、より良い時間を過ごすことができます。つまり、物事のやり方についてある意味で狂ったように振る舞う必要があるということですが、これはもはやゼロトラストでさえありません。私たちはマイナス1トラストのような状態にいます。ただ、すべてがすでに侵害されていると仮定しなければならないのです。
では、そのように仮定したらどうすればよいのでしょうか。バックアップです。大量のバックアップです。私はメインのSynologyに直接接続する、あるいは外部デバイスとして、ネットワークから切り離して2週間に1回程度だけ接続するローカルのオフラインバックアップを持つためだけに、もう一台Synologyを買おうかというところまで来ています。これ以上何ができるかわかりません。他の場所でもオフラインバックアップを行っています。重要なデータが入ったドライブを家族に送っています。できる限りの場所ですべてをバックアップしています。エアギャップでさえ、今の時点ではほんの始まりに過ぎないというのは狂気じみていますが。
しかし、私たちは実際に今、すべてがすでに侵害されているかのように扱わなければならないポイントにいるのです。1Passwordがインストールされているのと同じマシンでnpxを実行するのはリスクがあります。今は最悪な状況です。しかし、最も重要なこと、そしてこれは私がインターネット上で人気があるためにすでにやらなければならなかったことですが、私たち全員がしなければならないのは、あなたの家族と話すことです。
これから起ころうとしていることの深刻さを誰も理解していません。私の両親ならなおさらです。私はこれらのことを説明するために多くの時間を費やさなければなりませんでしたし、私の両親は、私がソフトウェアがすべての未来だと考えていたことは間違っていて、自分たちが正しかったと言って大喜びしていました。実際そうなのですが、私は今でもそう信じています。これには、あなたの身元を確認するための安全な言葉を家族と設定することや、彼らが知っているであろうことについて話しているあなたの声による電話が、たとえあなたの電話番号からのものであっても、必ずしもあなた本人であるとは限らないという事実を彼らに認識させることが含まれます。
これは、SIMスワップがどのように機能するかを説明し、彼らの回線をそれから保護するのを助けるようなことです。これは、大家から受け取っているものや不動産に関するもの、車やその他の高価なものの売買記録など、重要な文書やデータの紙のバックアップを確実に持たせるようなことです。あなたは単刀直入に彼らに尋ねるべきです。今日、すべてのコンピュータが動かなくなり、そこにあるデータがすべて消えてしまったら、何のバックアップを持っておけばよかったと思うか、と。そして、それらすべてのものをバックアップするのを手伝ってあげてください。
もし私の懸念が杞憂だったとしたら
皆さんのストレスを少し和らげるために、最後にもう一つ話しておきたいことがあります。もし私が間違っていたらどうでしょうか。もし私のこの分析が行き過ぎていたとしたら。それはどのような状況になるでしょうか。私が考え直し、自分がただ過剰反応しているだけだと気づくためには、どのような情報が必要でしょうか。これは、私が物事に対して強い意見やスタンスを持っているときに常にやろうとしていることです。自分が間違っていると納得させられる情報は何か。
最初の可能性として、そして私はこれが起こることを本当に望んでいますが、CVEの旋風が収まることです。現在、この種のセキュリティ問題の数が大規模に増加しているのを目の当たりにしています。動画の最初で取り上げたものはすべて、ここ1週間ほどのものにすぎません。そして、少なくとも私はさらに悪化するだろうと信じています。しかし、そうならないかもしれません。すべてのプロジェクトに何十ものセキュリティ問題があるように感じますが、もしかしたら10個程度しかないのかもしれません。中には全くないものもあるかもしれません。
Linuxカーネルのように10回エクスプロイトされたプロジェクトがある一方で、本当に不可欠なものでまだ一度もエクスプロイトされていないものもあります。これらすべてが、いつ発見されてもおかしくなかった低い位置にある果実だったという可能性は十分にあります。そして変わったのは、発見に5年かかっていたものを、代わりに3週間でやってしまったということだけなのです。それは完全にあり得る話です。
そして、もしそうだとすれば私たちが見ることになるのは、これらすべての特定の問題に対処した後、公になるインシデントの数が急速に減少するということです。LinuxカーネルでAIが発見できる問題が10個しかなく、すでにそのうちの8個を見つけているとすれば、あと2つでこの問題について聞かなくなるということであり、それは素晴らしいことです。
とはいえ、月ごとのCVEの作成数を見ると、この考えにはあまり希望が持てません。もしその減少が良いことだと思っているなら、それは私たちがまだ月の3分の1しか経過していないからです。心配しないでください、それは上昇するでしょう。おそらくすでにそこまで到達しています。しかし仮の話として、これが収まり、私たちがこのことについて話したり心配したりするのをやめられるようになる可能性は十分にあります。
私たちを救い、私がこれについて正しかったと感じるのを防いでくれる可能性のある次の道筋は、メンテナーたちが最初から対処できるようになることです。もし彼らが自分たちの開発サイクルの中でより多くのこれらの問題を発見し、これらの種類のバグがそもそもマージされるのを防ぐか、誰もそれを知る前にパッチを当てることができれば、そうなる可能性は十分にあります。それを行うには、大量のトークンのための多額の資金が必要であり、おそらくそれらのモデルの制限解除されたバージョンが必要になるでしょう。
OpenAIはDaybreakの発表をしました。これは設計段階からのより安全で回復力のあるソフトウェアのためのものです。OpenAIに脆弱性スキャンをリクエストして、プロジェクトを精査し、特に一般には公開されていない5.5 cyberのモデルを使用して潜在的な問題を見つけることができます。Daybreakは朝の最初の陽光です。サイバー防御において、それはリスクを早期に発見し、より早く行動し、設計段階からソフトウェアの回復力を高めることを意味します。サイバー防御の次の時代は、脆弱性を見つけてパッチを当てるだけでなく、設計上それらに対する回復力を持たせることによって、最初からソフトウェアに組み込まれるべきであるという前提から始まります。
つまりこれは、これらの種のものが少なくなるようにソフトウェアを設計する必要があるという全体的な考え方です。それは、C++のような言語ではなくRustで書かれるソフトウェアが増え、メモリ安全性によってこれらのカテゴリーのエクスプロイトの多くを防ぐことを意味します。それは、クライアントからデータベース全体にアクセスするような方法でシステムを構築しないことを意味します。これはまさにSupabaseやFirebaseのあらゆるエクスプロイトが発生した原因です。これは私たちのコアでより良いプリミティブを設計し、その上にこれらのクラスの問題がこれまでのように積極的に発生するのを防ぐためにより良いアーキテクチャを構築することを意味します。
ここで私のポイントが伝わったことを願っています。もし私たちが文化を迅速かつ積極的に変え、このような大きなリスクを生み出しているAIツールを作っている研究所が本当にお金を出して、すべてを構築しているメンテナーたちがプラットフォームを再考し、最初からより安全なソフトウェアを作るのを支援すれば。それは大きな助けになるでしょう。しかし、ソフトウェアセキュリティが常にそうであったイタチごっこは、危険な方法ではるかに速く動くようになりました。
パッチ適用のジレンマと今後の生き残り方
持ち物を最新の状態に保つという話題についてですが、ちょうどNMGから通知がありました。Tahoeの最新アップデート26.5に多数のセキュリティパッチがあり、Mac OS全体で79の個別のCVEを修正しているそうです。1つのリリースで79です。彼らがMythosにアクセスできたからだと推測していますが、これらの開示の多くは内部の人間からのものではありません。ですから、おそらくこれは他の人が見つけているものなのでしょう。ああ、これはClaudeとのコラボレーションによるものです。このうちどれだけがClaudeによるものでしょうか。なるほど、ClaudeとAnthropicを直接引用しているのは2つだけですね。いずれにせよ、OSにパッチを当ててください。これは悪い状況です。
ああ、家族と話すことやできることについてですが、パッケージを除いてすべてを最新の状態に保ってください。パッケージについては1日待ってください。そのような開示を行うのは狂気じみていますが、オペレーティングシステムのようなものを可能な限り最新の状態に保つこと、Nex.jsやNode.js、私たちがその上に構築しているすべてのものなど、依存しているパッケージに目を配ることは重要です。しかし同時に、マイナーアップデートをすべてインストールしないことも重要です。なぜなら、それらがサプライチェーン攻撃である場合があるからです。ですから、これのバランスをどのように取るか。適切な時期に適切なものを確実にアップデートするにはどうすればよいか。
ええ、これは私たち全員が話し合う必要のある会話です。チャットで誰かが1日待てと言いましたが、いいえ、1、2ヶ月待ってください。あなたは本当にひどくハッキングされようとしています。なぜなら、多くのセキュリティパッチがリリースされ、そのリリースが公開された翌日に悪用されるからです。幸運を祈ります。Nex.jsとReactで最近どれほど多くのセキュリティ問題が発生したかを考えると、これらを最新の状態に保っていないなら、あなたはかなり終わっています。これのバランスをどう取るかは自分で考えなければなりません。
そして私は、私たちが皆クローズドソースソフトウェアに移行すべきだと言っているのではありません。私はそんなことをほのめかしてもいません。オープンソースはかつてないほど重要になっていると思います。私たちが自分のマシンにインストールし実行するコードを信頼する方法を、根本的なレベルで再考する必要があります。なぜなら、もはや誰が実際にそのコードをそこに送っているのか分からないからです。そして、そのコードができることは、私たちがまさにその瞬間に発見している最中のことなのです。
私がここでの義務を果たし、皆さんにいくらかの恐怖を植え付けることができたなら幸いです。それが目標だからです。まず第一に、私自身がこれらすべてのことを恐れる中で、もう一人になりたくないのです。しかし同時に、皆さんが物事が向かっている深刻さと、ソフトウェアエコシステム全体で信頼がどれほど速く崩れ去ろうとしているかを確実に理解するために、責任を持って自分のプラットフォームを利用したいとも思っています。私たちはもはや、すべてが変わろうとしている時代にはもはやいません。それは過ぎ去りました。すでに変わったのです。
私たちが置かれている深刻な状況を十分に理解している人は多くないと思います。だからこそ私は、コメント欄で誰もが深く愛してくれるであろう、この非常に論争を呼ぶ刺激的な動画を作っているのです。しかし、ええ、事態は悪いです。これについて話したかったのは、事態がどれほど悪化しているかについて十分な議論がなされていないと思うからですし、私一人で狂いたくないからです。というわけで、私からは以上です。安全に気をつけてください。パッケージを最新にしすぎない限り、環境を最新の状態に保ってください。そして気をつけて、このすべてがいかに狂っているかを理解してください。願わくば。私はおかしくなりそうです。リラックスしに行ってきます。楽しんでください、オタクの皆さん。さようなら。
コメント