一週間前に「Copy Fail」の脆弱性が露見した。ヒョンウ・キムは直ちに公式な修正が不十分であると認識し、その日にパッチを提出した。この過程で彼は、Linux ドメイン（特にネットワーク関連）における標準的な手順に従った。具体的には、セキュリティ影響を特定の Linux セキュリティエンジニアリストに通告しつつ、公開チャネル上で効率的かつ低調に脆弱性を修復したのである。彼の目的は元のバグフィックスのみを公開することで、「深刻な脆弱性がある」という情報を封じ込めることだった。すなわち関係者が合意形成を図り、数日間は沈黙を守るというものである。しかし、誰かがこの変更を検知し、背後にあるセキュリティ上の意味合いを見抜いて公表してしまった。情報が漏洩したことで封鎖協定は無効化され、脆弱性の全容もすべて公開されるに至った。 この事象は、二つの異なる脆弱性情報対応手法間の緊張関係を浮き彫りにするとともに、AI の加速がこの現状をどのように変えるかについての考察を引き起こしている。 一方は「調整された開示（coordinated disclosure）」の文化である。これはコンピュータセキュリティ分野において最も一般的なアプローチであり、セキュリティホールを発見したら保守者に非公開で連絡を与え、一定の修正期間（通常は 90 日間）を与えるものであり、脆弱性に関する情報の公開前にパッチが準備されていることを確保することを狙っている。 もう一方は「脆弱性は脆弱性なり（vulnerability as vulnerability）」の文化である。これは Linux コミュニティで特に一般的であり、その主張はこうだ。「カーネルが本来行うべきではない操作を実行した場合、それを攻撃に変換できる人間は必ずいる」。したがって、注目を集めずにできるだけ早く修正すべきなのである。通常、膨大なコード変更の中で人々は此类のパッチに気づかないため、機械に対してパッチ適用のための時間を稼げるのである。 この方法は決して完璧ではなく、AI が脆弱性の発見においてますます巧みになるにつれて、厳しい挑戦に直面している。現在ではセキュリティ対策が次々と発表されており、コミット履歴の確認が極めて魅力的になっている。信号対雑音比が高まっているからだ。さらに、すべてのコミットを評価するために AI を活用することが、より低コストかつ高効率になりつつある。 一方で、長期的な情報封鎖もまた持続不可能となっている。過去の検出ペースは緩やかであった。もしあなたが脆弱性を発見してベンダーに 90 日の開示ウィンドウを与えた場合、その間に他の誰もそれを見つけることはほぼなかった。だが今や、多数の AI 支援チームがソフトウェアの脆弱性をスキャンしており、そのような状況は過去のものとなった。今回の事例でも、キム氏が ESP 脆弱性を報告してからわずか 9 時間後、クアンティング・チェン氏によって同様の脆弱性が独立して報告されていたのだ。封鎖自体がかえってリスクを増大させる可能性がある。それは偽りの緊急性の欠如を生み出し、修復作業に参加する人員の範囲を制限してしまうからである。 現時点では結論が出ていないが、私個人としては短期間の封鎖の方が望ましい妥協案だと考えられ、時間が経つにつれこのウィンドウ期間はさらなる短縮が必要となるだろう。幸いなことに、AI は攻撃側を強化する一方で防御側の速度をも加速させており、これにより以前は短すぎて無効とみなされていた封鎖期間さえも実現可能性を得ている。