脆弱性開示ポリシー

Google セキュリティチーム Project Zero は新しい「Full X」脆弱性公開ポリシーを導入することを発表しました：脆弱性は、ベンダーに報告されてから X 日後に公開されます。新しいポリシーは即日「Full 90」として実施され、2027 年 2 月 2 日には 60 日に短縮され、2028 年 1 月 3 日には 30 日に短縮されます。従来の「90+30」ポリシーは廃止され、猶予期間やバリアント（variant）ルールなどの特別条項も削除されました。例外は三つだけ残ります：すでに悪用されている脆弱性、詳細が他者によって公開されている脆弱性、ベンダーが公開を求めた脆弱性です。Project Zero は、AI が脆弱性の発見と悪用の速度を大幅に加速させ、その発見された脆弱性の数も明らかに増加していると述べています。

ビットコインコア開発者の Antoine Poinsot は、ビットコイン開発メールリストでセキュリティ脆弱性の開示ポリシーの調整を発表しました。彼は、過去には脆弱性が長期間秘密にされていたため、ユーザーが詳細が公開される前にアップグレードを完了できるようにしていたが、これにより修正が旧バージョンに戻せなくなり、ユーザーは次のメジャーバージョンのリリースを待たなければならなかったと述べました。Poinsot は、大規模言語モデルが一部の脆弱性を再発見しやすくしているため、修正の遅延が提供できる保護は非常に限られていると指摘しました。新しいポリシーに基づき、「発見しやすい」と判断された脆弱性は、すべてのメンテナンスされているメジャーバージョンでできるだけ早く修正され、安全公告が同時に発表されます。この分類は、簡単な LLM プロンプトを通じて発見できる脆弱性に適用されます。他の脆弱性は、重大度に応じて開示スケジュールに従います：低重大度の脆弱性は修正を含むメジャーバージョンのリリースから2週間後に開示され、中高重大度の脆弱性は最後の影響を受けたバージョンがライフサイクルの終了（通常は新しいメジャーバージョンのリリースから1年後）に達してから2週間後に開示されます。重要な脆弱性は標準ポリシーの範囲外であり、一時的な手続きが必要になる可能性があります。ビットコインエコシステムのセキュリティ研究者である Luke de Wolf は、彼は過去に Poinsot のセキュリティポリシーに同意していなかったが、今回の更新は良い調整であると考えていると述べました。今年の8月、ボランティアの Bitcoin Red Team は390のプロジェクトで約5000の潜在的な問題を報告し、その時点で再現されたのは約5分の1に過ぎませんでした。同月、Core Lightning 開発者は複数の AI 生成の脆弱性報告を受けて、オペレーターにアップグレードを促すか、ノードをオフラインにするように求め、技術的な詳細を2週間保持しました。