ドナルド・トランプ大統領が先月署名したAI関連の大統領令は、財務省、国家安全保障局(NSA)、そしてサイバーセキュリティ・インフラセキュリティ庁(CISA)に対し、新たな「AIサイバーセキュリティ・クリアリングハウス」を30日以内に設立するよう求めていました。その期限は先週過ぎています。
このクリアリングハウスは、重要インフラにおけるソフトウェアの脆弱性のスキャン、発見、検証を調整し、それらの脆弱性をどのような優先順位でパッチ適用・展開していくかを決めることを目的としています。
取り組むべき問題設定としては正しいものです。問題は、実際に作られるものがそれを解決できるかどうかです。
懸念されるのは、この緊急性が生み出すものが、見た目はクリアリングハウスであっても、実態は委員会のような機能しか果たさないケースです。情報を集め、会議を開き、そして肝心の難所に差し掛かったところで停滞してしまう、という具合です。
バグ発見にとどまらない対応が不可欠
AI支援による脆弱性発見が急速に進化している今、直感には反するかもしれませんが、本当に難しいのはもはやバグを見つけることではありません。AIとサイバーセキュリティの交差点で働く私たちには、真のボトルネックがどこにあるのか分かっています。HackerOneは、重要なオープンソースソフトウェアの脆弱性をインターネット規模で発見・修正するためのOpenAIの取り組み、Patch the Planetのローンチパートナーとして、それを身をもって経験してきました。この取り組みから得られた教訓は、10年以上にわたり脆弱性開示プログラムを運営してきた経験にも裏打ちされたものであり、一貫しています。それは、AIツールが脆弱性を洗い出すスピードに、人間が対処する速度が追いついていないということです。発見の後に続くあらゆる工程――どの発見が本物か見極め、文脈の中で深刻度を評価し、修正パッチを作成・テストし、影響を受けるコードの保守責任者にパッチを受け入れて展開してもらうこと――こそが遅れているのです。
経験豊富な人間のレビュアーが、AIが割り当てた深刻度評価にしばしば異を唱えるのは、モデルがそのプロジェクトの脅威モデルや運用上の文脈を把握できないためです。ソフトウェア提供者、とりわけ今日のデジタルインフラの多くを支えている多数のボランティアのオープンソースメンテナーたちは、絶え間ない対応キューに直面しています。申告内容の検証、重要度の評価、パッチの作成、開示の調整といった作業です。AIは流入する量を加速させた一方で、それを処理する人材やプロセスの能力を同じペースでは加速させていません。優れたバグ発見ツールは、より多くのバグを見つけ出すだけです。本当に重要な改善は、防御側がパッチを押し出し、それをより早く展開できるよう後押しするものです。
この教訓こそ、クリアリングハウスの設計の中心に据えるべきものです。
大統領令の文言が重視しているように、クリアリングハウスがスキャンの調整を主眼に置いてしまえば、ギャップを埋めるどころか、むしろ広げてしまう恐れがあります。より多くの脆弱性を発見できても、それを解決まで導けない組織は、セキュリティ上の勝利とは言えません。国家規模で見れば、それは未処理案件を量産する装置にほかなりません。
成功のための基盤づくり
政権はこれを正しく実現できるはずですが、そのためには適切な基盤を後から積み増すのではなく、今すぐ構築する必要があります。
クリアリングハウスは、スキャンの調整以上のことをしなければなりません。実際に結果をトリアージする必要があるのです。その中核的な役割は、報告された内容をふるいにかけ、どの発見が真に信頼でき、悪用可能で、重要インフラにとって重大な結果をもたらすものかを見極めることであるべきです。共通の検証基準とリスクに基づく優先順位付けを用いれば、何が国家的対応に値するかを判断できます。そうでなければ、より大きな未処理案件の山を自動的に作り出すだけになってしまいます。
第二に、クリアリングハウスはより根本的な課題にも取り組む必要があります。防御側には、報告された内容に対応するためのリソースがありません。重要インフラにおける脆弱性は、開示に応じる正式な義務を負わず、迅速に対応する余力も限られた小規模チームや個人が保守するオープンソースコードの中にしばしば潜んでいます。クリアリングハウスは米国国立標準技術研究所(NIST)と連携し、パッチのレビューと展開を迅速化するためのリポジトリやワークフローの構成に関するガイドラインを、オープンソースメンテナー向けに策定すべきです。
これらのガイドラインには、AI支援によるパッチ適用の活用方法を盛り込み、メンテナーの脆弱性対応を後押しするために、オープンソースコードの下流利用者が何をすべきかを明確にする必要があります。連邦政府の政策は、資金提供、エンジニアリング支援、AI支援によるパッチ開発、そして協調的な脆弱性対応への参加を評価する調達要件を通じて、下流の利用者が修復の責任を分担するインセンティブを生み出すべきです。
第三に、クリアリングハウスは、ソフトウェア製品を構成するコンポーネントの構造化された目録であるソフトウェア部品表(SBOM)を、基盤インフラとして扱うべきです。SBOMがあってこそ、脆弱なコンポーネントがサプライチェーンのどこに存在するかを追跡できます。SBOMがなければ、検証済みの発見であっても、規模に見合う速さで修正することはできません。
最後に、クリアリングハウスは何を発見したかではなく、何を修正したかに基づいて成功を測るべきです。各政府機関は、検証率、パッチ適用までの所要時間、修正の採用状況、繰り返し発生する脆弱性の傾向に関するデータを公表する必要があります。こうした指標は、AIシステム、ソフトウェアベンダー、そして政策立案者が、脆弱性への対応方法を継続的に改善していく助けとなります。
最も重要なのは、このクリアリングハウスを立ち上げる各政府機関が、その運用モデルをゼロから作り上げようとする誘惑に抗うべきだということです。民間セクターとオープンソースセキュリティコミュニティは、クリアリングハウスに必要とされているまさにこの種の脆弱性受付、トリアージ、協調的開示のワークフローを運営してきた長年の経験を持っています。大統領令が業界との自発的な協力を求めているのは賢明な判断です。その協力は、単なる助言にとどまらず、構造的なものであるべきです。つまり、アーキテクチャが固まった後に付け加えるのではなく、クリアリングハウスの運用の在り方そのものに、最初から組み込まれているべきなのです。
クリアリングハウスはうまく機能し得ます。しかし課題は、もはや脆弱性を見つけることではありません。発見を実際の行動へとつなげられる仕組みを構築すること。それこそが、その成否を測る基準となるべきです。
翻訳元: https://cyberscoop.com/ai-executive-order-cybersecurity-clearinghouse-vulnerability-patching-gap/
