セキュリティ脆弱性の約70%はメモリ安全性に関するもので、CやC++で書かれているから存在しているんだ。ほとんどの脆弱性は新しく書かれたコードにあるから、Googleは新しいコードを書くときにRustを使うだけで、見つかる脆弱性の数が劇的に減ることを発見したんだ。

2000年以前のソフトウェアは本当に良かったのかな？リリース時には、そうだったね。CDやフロッピーに焼く前に、ソフトウェアがちゃんと動くか確認しなきゃいけなかったから。今はバグだらけのバージョンをリリースして、ユーザーにテストさせてる感じだよね。

90年代にマイクロソフトで開発者をやってたんだ（Visual Studio（ボストン）とWindowsチーム）。当時のソフトウェアが「良かった」とは言わないけど、確かにもっと低いレベルで考えなきゃいけなかったのは事実だね。例えば、どのWin32関数がリング3からリング0に遷移するかを知っておかなきゃいけなかった。そういう遷移はすごくコストがかかるからね。「正しい関数を見つけて次に進む」なんてことはできなかった。アプリやシステム全体をダウンさせない正しい関数を見つけなきゃいけなかった。KiUserExceptionDispatcherの問題にぶつかるたびに、人生が嫌になったのを覚えてるよ。例外のような簡単なことでも、アプリのパフォーマンスを殺す可能性があったからね。それに、問題が発生したらパッチを当てるだけじゃなかった。フロッピーディスクでパッチを送ったり、BBSに投稿したり、PC Magazineに送ったりしなきゃいけなかったんだ。[0]: https://doar-e.github.io/blog/2013/10/12/having-a-look-at-th...

8ビットや16ビットのビデオコンソールゲームを考えてみて。あのカートリッジは高かったから、何百万も作る前にバグがないことをどれだけ確信していたのかな？

どちらが理由かは難しいけど、両方の可能性が高いよね。つまり、低い複雑さがより徹底的なテストを可能にしたってこと。とにかく、2000年以前のソフトウェアは今より確実に良かったと思う。絶対に失敗しないように設計されてたから、何をしてもクラッシュしたりデータが壊れたりすることはなかった。ただ、その頃のほとんどの人が使っていたコンピュータはシングルスレッドのCPUだった。プリエンプティブマルチタスクのOSやマルチスレッドのアプリを使っても、シングルスレッドのCPUで実行すると、マルチコアCPUで露呈するような微妙なバグは見つからなかったんじゃないかな。今は、どんな状況でも絶対に失敗しないOSなんてないけど、2003年以前とは違って、古いプログラムの質が良かったのか、それともハードウェアの並列性を持つシステムでソフトウェアの同時実行を正しく実装するのが難しいからなのか、ちょっと気になるね。

最高の時代でもあり、最悪の時代でもあった。最高だったのは、QAが実際に存在していて、多くの会社にとって重要だったから。QAが何かを見つけたら、最終マスターがプレスされる前に「出荷停止」できたから（だいたいゲームのことだけど）。フォークロアや歴史的なサイトを探せば、そういう例が見つかるよ。プログラマーが夜通し働いて、出荷マネージャーがそばで見守っていて、ディスクを掴んで倉庫に駆け込む準備をしてた。だけど、アップデートもあったよ。バグや機能のため、プログラマーが完璧じゃなかったから（完璧なコードを作るために宇宙シャトル並みの努力をしてたわけじゃないし、ボイジャーだってアップデートがあるしね）。DooMを見てみて。BBSでリリースされて、当時からいろんなバージョンがあったし、1994年くらいかな？でも「最悪」だったのは、フレームワークやコードが今ほど進んでなかったから。CRUD開発者でも、全てがどう動くか結構知っておかないといけなかった。今当たり前に思ってる多くの保護機能（Cのような「低レベル」言語でも）なんて存在しなかった。セキュリティの問題も多かったけど、みんなあまり気にしてなかった。だって、全てがローカルだったから（自分のボックスをr00tできるかどうかなんて誰も気にしない）。2000年はインターネットが本格的に始まり、全てが「オンライン」になり始めて、問題が次々と見つかるようになった時期だった。

こういうことを言うとき、ちょっとバラ色のメガネをかけてる感じがする。プログラムは自動保存されず、頻繁にクラッシュしてたから。誰かが何時間も作業を失ったって話を聞くのはすごく普通だった。コンピュータはランダムにブルースクリーンになってたし、デバイスドライバーはカーネルから隔離されてなかったから、簡単にシステムを不安定にするようなドングルを買っちゃうこともあった。ウイルスはホワイトカラー経済をひざまずかせることがよくあった。オンラインで協力プレイを始めたばかりのコンピュータゲームは、クライアントが送るものの検証を全くしてなかった（今でもそういうことはあるけど、当時はそれが普通だった）。

見た目は良かったけど、機能が少なくて開発とテストに時間がかかったからだよね。でも、ノスタルジーもある。全てが遅く動いていて、世界も小さくて、基準も低かった。人々は通常、ソフトウェアの後のバージョンを覚えているか、初期のバージョンに出会ったことがないから。インターネットがなかった頃は、みんなが細かいことについて文句を言うこともなかったし、一般的な意識も今ほど毒性がなかった。

デルタ、ジェットブルー、アメリカン航空、アラスカ航空は、無料でロイヤリティプログラムに登録している限り、無料のインターネットを提供してるよ。ジェットブルーとデルタはViaSatを使ってる。私はほとんどデルタしか利用しないけど、ViaSatは私が乗った国内路線では全て利用できたよ。ATLから南西GAに行く小さいA900を除いて（50分のフライト）。その後は、T-MobileのGoGo地上サービスを使って、無料の無制限1時間アクセスを利用してる。

AIが書いたソフトウェアが原因かもしれないって考えてるんだけど、これが実際に嬉しい唯一の側面なんだ。企業で書かれるソフトウェアの大半はクソだし、誰かが適当に組み合わせてなんとか動かしたものだから、次のことに移らなきゃいけないんだよね。時間が限られている世界では、新機能が最優先になって、終わりのないバグのリストを潰す羽目になる。でも、良いソフトウェアのコストが、ほとんど機能しないソフトウェアのコストを圧倒するのは、その時だけなんだ。何かを磨くのにかかる追加コストが、最初に書くのにかかった時間よりもほんの少し長いだけなら、何度も見直してバグを取り除いて、ちゃんと仕上げる理由がないよね。今、AIは（そしてこれからも）人間が書く気にならないような、徹底的なテストケースを作成できるし、どんどん良くなっていく。もし企業が質の高いソフトウェアを、ゴミを出すのとほぼ同じ時間で出荷できるなら、インセンティブは急速に変わるだろう。少なくとも、そう願ってる。

どんな時代でも、すべてのソフトウェアが同じ品質で作られているわけじゃない。例えば、1980年にはAdaを使って、高い信頼性が求められるところで仕事ができた。みんながKnuthのように、資金が潤沢な世界のトップ機関で個人秘書を持っているわけじゃないし。2000年代には、すでに膨大なリソースを持っていたMicrosoftがWindows Millennium Editionをリリースした。もしあなたが若すぎて覚えていないなら、隣の年配の人に聞いてみて。商業化が始まったのは2000年だけど、これは最後のMS-DOSベースのWindowsバージョンで、Windows 9xが代表するものの頂点を示している。大きなNTの遺産への切り替えの前にね。いつも通り、良い時代の最大の利点は選択的な記憶だ。結局、覚えている人はその時代を生き延びたことを知っているけど、現在と未来はその点であまり確実性を提供してくれないから。

「リバースエンジニアリングは、エントリーレベルのチームにとってもほとんどスピードバンプみたいなもんだった。バイナリをIRに持ち上げたり、ソースコードにデコンパイルしたりするのが普通だから。エージェントもこれができるけど、アセンブリから直接推論することもできる。バグハンティングよりもLLMに向いてる問題を探してるなら、プログラムの翻訳がいいスタート地点だよ。」ふーん、アセンブリでの直接デバッグか。だったら、マシンコードに飛び込んじゃえばいいんじゃない？

明確にするために言うと、これはAnthropicの研究者によるトークなんだけど、LLMの話題を考えると「エントロピックリサーチャー」っていうのもなんとなく意味があるね。

リンターはこれを見つけられるのかな？もしかしてファジング？それがsyzbot / syzkallerがやってることで、最近のAIファジングと似たような結果が出てる。一般的にLinuxのメンテナーが抱える問題は、Linuxコードベースに「厳密な正確性と安全性」のバグがたくさんあって、それを一度に修正できないことだ。どのバグが攻撃者によって悪用される可能性があるかをトリアージする良いメカニズムもない。これがほとんどのバグがCVEになる理由でもある。攻撃者が到達可能な正確性のバグかどうかを判断する能力がないため、どんなバグも悪用される可能性があるとされていて、どれがどれかを決めるのは手間がかかりすぎるっていうのが彼らの立場なんだ。

その態度は本当に意味がわからないし、AIがセキュリティバグを見つけることで人々が「ついに理解する」理由がわからない。Linuxの一般的なセキュリティの実績が悪いことの言い訳に過ぎないと思う。

これが最良のシナリオだよ。アップデートがオプトアウトになると、別のタイプの攻撃ベクターになっちゃうからね。更新されたコードがオープンソースでなければ、あなたは盲目的に信じることになる。知らないうちに、別のリモートコード実行が起こったかもしれないから。

カーネルレベルでは、バグをセキュリティ関連かそうでないかに分類するのが難しいことがあると思う。過去には、セキュリティ問題だと思われていなかったバグを利用したエクスプロイトもあったしね。新しい機能を追加するアップデートを避けたくなるのは理解できる（そういう変更は新たなバグを引き起こす可能性があるから）。でも、LinuxにはLTSリリースがあって、セキュリティの影響に関係なくバグ修正だけを含むから、その場合は最小限のリスクで最新の状態を保てるよ。

もしそういうことを気にするタイプの人なら、同じディストリビューションのバージョンを10年間提供してくれるベンダーにお金を払うべきだね。もしくは、オフブランドのRHELを使うのもアリかな。

詳細は重要だけど、私の考え方はこう落ち着いてる：セキュリティバグは、政治家が「子供たちのことを考えろ」と言うように使われることがある。自動的に勝つためのボタンみたいなものだね。優先順位で競合するものもある（パフォーマンス、機能性、摩擦、便利さ、互換性など）。その点を考えるのは一つのことだよ。時には、「このプログラムや機能がどうして攻撃対象になるの？インターネットの誰かがこのシステムに書き込めるのはなぜ？」って思うこともある。多くの場合、あるシステムの主な目的は数値演算を行ったり、UIに物を表示したり、ボタンを通じてユーザー入力を受け付けたりすることなんだけど、「これに[必須？自動的？みんながこれをやらなきゃ重要な面で生活が悪影響を受けるって言ってるの？]セキュリティアップデートがあるの？脆弱性があるの？」って考えちゃう。誰かが根本的な要件レベルで本当に失敗したんじゃないかと思うよ。

どこかで読んだエピソードを思い出す：ある「組み込みシステム」のエンジニアが、彼らが作るように依頼されたウェブベースの製品を発表しようとしたとき、マネージャーやレビュアーたちはバグが見つからないことに困惑していた。これについて尋ねられたエンジニアはこう答えた：「それが選択肢だとは知らなかった」。ウェブからの「クイックフィックス」なしで自律的に動作するシステムを構築するには、確実に異なる考え方やツールセットが必要だね。