AI、オープンコードと公共部門の脆弱性リスク（英国）

英国政府デジタルサービス庁と科学・イノベーション・技術省は、2026年5月14日、AIによる脆弱性発見の加速に直面する公共部門向けに、ソースコードを安全に公開するための新たなガイダンスを発表しました。このガイダンスは、技術リーダーたちが懸念する「AIによる脆弱性発見の加速が、公共部門がデフォルトでソースコードを公開するのをやめるべきか」という問いに答えるものです。ユーザー調査により、悪用リスクの主な要因はシステム内の弱点（未パッチの脆弱性、安全でない実装、安全でない設定やデプロイ）と、それらを迅速に修復できないことにあることが明らかになりました。ソースコードの公開自体はこれらの弱点を作り出しませんが、攻撃者の不確実性を適度に減らし、分析を加速させる可能性があります（特にメンテナンスが弱く修正が遅い場合）。このガイダンスは、公開サービスを安全に運用するためにすでに想定されている最小限の運用能力を強化するものです。

推奨事項としては、まず公開システムの最低基準を満たすこと（明確な所有権、セキュリティバイデザインの実践、自動化された衛生管理、信頼できる修復能力）を求めています。次に、デフォルトでオープンを維持すること。すべてを非公開にすると、追加の配送とポリシーのコストが発生し、再利用と精査が減少します。オープン性をデフォルトとし、非公開は慎重かつ限定的に使用すべきです。例外は明確かつレビュー可能にし、コードを非公開にする場合は、攻撃者、公開がもたらすもの、具体的な危害経路を説明する簡潔な脅威モデルを要求します。例外は狭く、期限付きで、定期的に再承認する必要があります。修復能力を強化し、発見から悪用までの時間枠が短くなると想定して、パッチSLAを設定し、依存関係と脆弱性管理を自動化し、チームが報告に迅速に対応できるようにします。これはコードが公開か非公開かにかかわらず不可欠です。

ガイダンスは、公共資金で開発されたコードはデフォルトで公開され再利用可能であるべきという一貫した政府の方針を再確認しています。これはサービス基準、技術実践規範、セキュリティバイデザインポリシーなどに反映されています。政府のガイダンスは、チームがソースコードの可視性を主要なセキュリティ管理手段として扱わず、代わりに秘密（認証情報、APIキー、トークン、秘密鍵など）を決してリポジトリにコミットしないという標準的なプラクティスに従うことを前提としています。また、公開リポジトリには、内部ホスト名やIP範囲、管理エンドポイント、セキュリティ制御やしきい値など、公開されると悪用可能性を大幅に高めるセキュリティ感受性の高い実装詳細を含めないことを前提としています。これらの制御があっても、公開が特定の信頼できる危害経路を生み出す場合、チームはコードを非公開にできますが、それは新しいベースラインではなく、正当な例外としてです。

AI対応脆弱性検出の進歩により、ソフトウェア分析は急速に向上しています。英国AIセキュリティ研究所は、最近のフロンティアモデルが制御評価で実質的に強力なサイバー能力を示していると報告しています（例：2025年12月のフロンティアAIトレンドレポート、2026年4月のClaude Mythos Previewのサイバー能力評価）。これは部門にとって、発見から悪用までの時間枠が短縮されることを意味します。AIは分析の速度と規模を変え、弱点が存在してから悪用されるまでの時間を圧縮し、修復能力がこれまで以上に重要になります。ソースコードへのアクセスは、不確実性を減らし、より迅速で的を絞ったレビューを可能にすることで攻撃者に優位性を与え、この優位性はAI支援によって拡大する可能性があります。しかし実際には、その優位性は通常、根本的な弱点の存在とパッチ適用・緩和の速度に対して漸増的です。したがって、リーダーシップの判断は、ソースアクセスが重要かどうかではなく、実際に追加の優位性がデフォルトの公開から移行するほど十分かどうかです。攻撃者はソースコードがなくても、実行中のサービスを調査したり、ファジングしたり、バイナリや依存関係を分析したりして弱点を見つけることができ、防御側も同じツールを使ってより迅速にレビューとトリアージを行うことができます。

AI対応のコード分析により組織が公開リポジトリへのアクセスを制限しているという最近の報道は、リーダーが不確実性に応じて全面的な非公開にすぐに走る可能性を示しています。このガイダンスは別の選択肢を提示します。デフォルトで公開を維持するが、公開を意図的な決定とし、最低限のメンテナンスと修復基準で裏付けることです。実際には、本番リスクは、公開されたソースコードによるアプリケーションロジックの可視性よりも、セキュリティバイデザインのアーキテクチャと実装、デプロイ、設定、依存関係の衛生、アクセス制御によって主に引き起こされます。多くの深刻な脆弱性はコードの論理欠陥ですが、攻撃者は他の手段でそれらを発見し悪用することがよくあります。重要なのは、ソースの可視性は通常、発見までの時間と攻撃者の不確実性を変えるものであり、弱点が存在するかどうかやどの程度迅速に緩和されるかの主要な決定要因ではないということです。チームは、セキュリティバイデザインの提供、コードからの秘密の分離、強力な環境制御、監視、および迅速な修復を優先する多層防御アプローチに焦点を当てるべきです。これらの制御は、コードが公開でも非公開でも効果的です。

追加の考慮事項として、非公開リポジトリは誤った安心感を生み出し、セキュリティバイオブスキュリティの考え方を促進し、根本的な弱点を修正する緊急性を低下させる可能性があります。公開後にコードを非公開にしても、能力のある敵対者のアクセスを除去できない場合があります。人気のあるリポジトリはミラーリングまたはフォークされることが多く、目立たないリポジトリでも研究者や攻撃者によってすでにインデックス化またはクローンされている可能性があります。非公開は一方通行のドアになる可能性があります。非公開リポジトリは再利用と外部精査を減らし、時間とともにチームは分岐します。そのため、コードを再び公開することが難しくなります。安全かつ自信を持って公開するために必要な作業が増加するからです。同じツールを防御に適用できます。発見が加速するにつれて、防御は継続的なレビュー、テスト、修復に依存する必要があります。オープン性はこの規律を強化しますが、精査を避けても欠陥は除去されず、弱点が持続する可能性があります。オープン性は問題を早期に表面化させることができます。公開コードは、政府全体やサプライヤーエコシステムを含むより広範なレビュー担当者による問題特定を可能にします。コードを非公開にすると、発見は提供チームと運用監視に集中します。先例は重要です。閉鎖のための広範な「AI」の正当化は簡単にコピーされ、一旦標準化されると、再利用と基準に関する政府全体の一貫性を損なう可能性があります。

公開システムの最低基準として、リーダーは以下を最低基準とすべきです：指名された所有者とメンテナンス計画（CODEOWNERSファイルなどで可視化）、セキュリティ連絡先と報告経路、秘密や機密運用詳細の排除と防止策、セキュリティバイデザインのベースライン（脅威モデリング、セーフデフォルト、最小特権、公開エンドポイントの堅牢化など）、自動化された衛生管理（依存関係更新ツール、脆弱性・秘密スキャン、トランク保護）、パッチ期待値（重要・高脆弱性に対処するための合意されたタイムライン）、未メンテナンスコードの安全な姿勢（明確にマークしてアーカイブ、または明示的な所有者とパッチ経路を持つ）。コードを非公開にすることは、所有権、パッチ能力、または運用保証の欠如に対する適切な緩和策ではないため、安全に維持できないシステムは修復または廃止されるべきです。チームが最低基準を満たせない場合、リーダーは運用上のギャップに対処する必要があります。実際には、リーダーは共有サービスを介して能力を人員配置するか、不要なシステムを廃止し（関連リポジトリをアーカイブ）、ライブサービスに明確な所有者とパッチ経路が残らないようにする必要があります。システムが最低運用基準を満たした場合にのみ、リーダーは既存の例外ルールを使用できます。つまり、適切にメンテナンスされたコードを公開すると特定の信頼できる危害経路が生じる場合です。「デフォルト非公開」を避けることが意図されており、リソース不足のメンテナンスを隠蔽する非公開デフォルトへの漂流を防ぎます。コードを公開から非公開に移行することは、セキュリティバイデザインの提供、所有権、修復への投資の代替として行われる場合、警告サインです。それは共有と精査を減らし、政府全体とサプライヤー間の調整された改善を遅らせ、実行中のサービスの根本的な弱点を除去しません。部門は、プライバシーを特定の信頼できる危害経路に対する例外制御として扱い、能力不足に対する補償制御として扱うべきではありません。