オープンソースはセキュリティ境界ではありません

2026年5月14日、英国 Government Digital Service は、公共部門におけるAI、公開コード、脆弱性リスクに関するガイダンスを公開しました。このガイダンスは、正しい問いに答えています。AIによって脆弱性の発見コストは下がります。それでも、リポジトリの非公開化がセキュリティ境界になるわけではありません。¹

その9日前の公開報道では、NHS England が、AI脆弱性ツールによって公開コードを大規模に調査される懸念から、数百の GitHub リポジトリを非公開にする計画だと伝えられました。² 不安は理解できます。しかし、提案された対策は適切ではありません。コードを隠す発想は、発見されることを脅威として扱っています。本気のセキュリティでは、未修正の弱点こそを脅威として扱います。

オープンソースのセキュリティは、実際の露出を減らすことで向上します。コードに秘密情報を入れないこと、例外を明確にすること、リポジトリに責任者を置くこと、機能する開示経路を用意すること、素早くパッチを出すこと、修正がユーザーに届いた証拠を公開することです。リポジトリの非公開化は、特定の例外を支える場合はあります。しかし、その運用体制の代わりにはなりません。

要点

GDSは、公共部門のチームに対して、コードは原則として公開し、例外は意図を持って見直し、実際のリスクを変える実務上の要因に集中すべきだと述べています。¹ この答えは、リポジトリ非公開化へのパニックより優れています。公開コードは、すでにフォーク、ミラー、キャッシュ、パッケージ成果物、コンテナイメージ、スクリーンショット、生成クライアント、過去のクローンに存在している可能性があるためです。さらに重要なのは、公開コードによって、より多くの人が調査し、再利用し、報告し、改善できることです。¹³

AIによる脆弱性発見への正しい対応は、「すべて非公開にする」ことではありません。秘密情報を取り除き、機微なコードを分類し、明確な例外を公開し、依存関係と秘密情報のスキャンを実行し、脆弱性開示の経路を維持し、素早く修正し、公開コードに責任者がいる証拠を残すことです。¹⁴⁵

重要なポイント

• エンジニアリングリーダーへ: 非公開化は限定的な場面で露出を減らせますが、責任体制、棚卸し、パッチ適用、開示の代わりにはなりません。
• 公共部門のチームへ: 秘密情報、不正対策、機微なアーキテクチャ、未公開ポリシーについて明示的な例外を設ければ、原則公開は今でも機能します。
• セキュリティチームへ: AIによって、対応能力の価値が上がります。トリアージ経路のない非公開リポジトリは、それでも失敗します。
• エージェントチームへ: コードの可視性は攻撃面の1つにすぎません。リポジトリが非公開に見えるかどうかより、ツール権限、状態の境界、外部通信の制御、リリース基準のほうが重要です。
• メンテナーへ: 謎を減らしましょう。良いドキュメント、明確なセキュリティ連絡先、小さく責任範囲のはっきりしたサービスは、非公開リポジトリの壁よりリスクを下げます。

パニックは可視性を脆弱性と取り違えています

AI脆弱性スキャナーは、調査の経済性を変えます。以前は、コードベースを調べるには時間、スキル、根気が必要でした。十分に能力のあるモデルなら、より多くのコードをより速く調べ、ファイルをまたいで手がかりをつなぎ、候補となる指摘を大量に出せます。この変化は、もともと壊れやすいコード、曖昧な責任体制、遅いパッチ経路を抱えていたチームに圧力をかけます。

それでも、リポジトリの可視性は脆弱性そのものではありません。公開コードがバグを明らかにすることはあります。非公開コードにも同じバグは存在し得ます。攻撃者は、バイナリ、APIトラフィック、クライアントバンドル、パッケージ内容、コンテナレイヤー、ログ、ドキュメント、依存関係メタデータ、古いクローンから挙動を推測できる場合が少なくありません。GDSも同じ実務的な点を示しています。以前公開されていたリポジトリを非公開にしても、人気プロジェクトにはフォークやミラーがあることが多く、知名度の低いリポジトリでさえ、すでに研究者や攻撃者に渡っている可能性があるため、有能な相手のアクセスを断てるとは限りません。¹

この注意点は重要です。「閉じる」ことは、何かを実行したように感じられるからです。しかし、その行動は技術的な弱点を残したまま、公開された説明責任だけを減らすかもしれません。チームは、外部レビュー、共有された修正、再利用の機会を失いながら、すでにコードをコピーした相手に対してはほとんど防御を得られない可能性があります。

オープンソースは監査の記録も作ります。公開履歴を見れば、誰が何を変えたのか、いつ修正が入ったのか、メンテナーが報告にどう対応したのか、プロジェクトが今も手入れされているのかが分かります。非公開コードは、同業のチーム、供給者、研究者、再利用や改善を検討する他の公共機関から、そうしたシグナルを隠してしまいます。

原則公開は甘い考えではありません

GDSは、すべてのコード行を公開インターネットに置くべきだとは主張していません。以前からあるGOV.UKのオープンソースガイダンスでも、鍵、認証情報、不正検知アルゴリズム、未公開ポリシーなど、コードを非公開にしてよい正当な理由が挙げられています。³ Technology Code of Practiceも、オープン性をセキュリティやプライバシー義務と対立させるのではなく、同時に求めています。⁴

より強い原則は、具体的な例外を伴う原則公開です。この方針にすると、チームは「セキュリティ」という包括的な分類に逃げず、リスクの名前を示す必要があります。秘密情報はリポジトリに入れるべきではありません。不正検知のシグナルは可視性を制限する必要があるかもしれません。未公開ポリシーのサービスには、期限付きの保留が必要な場合もあります。ただ恥ずかしく感じるだけのコードベースは、例外には当たりません。

英国公共部門の実践指針も同じ方向を向いています。政府のソフトウェアとコードは、適切な場合には原則としてオープンソースであり、オープンに開発され、承認済みライセンスの下で公開されるべきだという期待を示しています。⁵ DWPのOpen-Source Code Publishing Policyも同じ型です。オープンライセンスでの公開を促しつつ、定義された管理策によって機微なソースコードを保護します。⁶

この区別は品質を守ります。公開の場でコードを書くチームは、外部の人が読む可能性があるため、より良いREADME、より分かりやすいセットアップ手順、より明確な課題履歴、より明示的なデータ境界を書く傾向があります。GOV.UKのガイダンスは、コード公開がドキュメント、保守性、データの明確さ、セキュリティフィードバックを改善し得ると述べています。³ AIへの圧力に反応してすべてを埋めてしまえば、こうした利点は消えます。

本当の対策は修正速度です

AIは時計を速めます。発見は速くなります。報告量も増えます。誤検知も増えます。同じ能力面の圧力について、私はエージェントが脆弱性を見つけたときで書きました。発見は、検証と修復がなければほとんど意味を持ちません。チームに必要なのは、トリアージ、責任者への振り分け、パッチ適用、開示、そしてリリース証拠です。リポジトリの非公開化は、そのどれも与えてくれません。

CISAのVulnerability Disclosure Policy Platformは、そのために存在します。このプラットフォームは、連邦文民機関に対して、公開研究者が報告する脆弱性を受け取り、トリアージし、振り分ける経路を提供します。⁷ CISAのCoordinated Vulnerability Disclosure Programも、オープンソースソフトウェアやAIシステムを含む重要インフラ全体の脆弱性を対象とし、公開前の緩和調整を重視しています。⁸

NCSCも、脆弱性の報告と開示に関するガイダンスを通じて、英国組織に同じ運用上の枠組みを提供しています。ツールキットや政府部門向けの既成の報告経路も含まれます。⁹ 共通する考え方は単純です。外部の人がバグを見つけることを前提にし、その報告と修正が機能するようにすることです。

この枠組みに立つと、AIによる脆弱性発見は、隠す理由ではなく、対応ループを改善する理由になります。モデルが公開コードのバグを見つけられるなら、チームは次の5つを問うべきです。

これらの答えは、コードが公開されていても非公開でもリスクを減らします。リポジトリを隠しても、今日ソースを見られる人が変わるだけです。責任者、パッチ、開示経路は生まれません。

より良い判断基準

チームには、恥ずかしさ、露出、本当に機微な情報を分ける判断基準が必要です。

この基準は、よくある失敗も防ぎます。何も分類できないからすべて閉じる、という失敗です。リポジトリの棚卸しでは、そのサービスが何をするのか、どのデータに触れるのか、誰が責任者なのか、どの秘密情報スキャナーが動いているのか、重要な依存関係は何か、報告がどうメンテナーに届くのかを答えられるべきです。答えがないなら、それは運用上の欠落です。リポジトリの可視性を変えれば、その欠落を公衆から隠せるかもしれません。しかし、欠落そのものは残ります。

エージェントは境界の問題をさらに大きくします

AIコーディングエージェントは、同じ教訓をより鋭くします。リポジトリ境界は、許可された権限の内側でエージェントが危険な判断をすることを止めません。この構図については、エージェントのサンドボックスセキュリティは提案にすぎませんで書きました。危険な操作は、権限セットの外ではなく、内側で起きることが多いのです。同じ組み合わせの問題は、ソフトウェアサプライチェーン攻撃にもあります。一つひとつは妥当に見える部品が、組み合わさることで有害な経路になります。

見えないエージェントの問題は、オープンソース方針にも当てはまります。見えないものは統制できません。ツール経路、生成物、キャッシュ、リリース状態、開示キュー、責任者の引き継ぎは、すべて重要です。

オープンソース方針は、エージェントセキュリティから学ぶべきです。有効な境界は、操作と対応の層にあります。

• 信頼できない入力を、ツールが触れる前に分類する。
• コード、履歴、ログ、パッケージ、生成アセットから秘密情報を取り除く。
• ビルドキャッシュとリリース成果物を信頼レベルごとに分ける。
• 自動化されたワークフローの外向きネットワーク経路を制限する。
• 公開、デプロイ、修正完了宣言の前に証拠を求める。
• 外部研究者に、安全で文書化された報告経路を提供する。

これらの対策は、ソースの秘匿性に依存しません。機微な情報がどこにあり、どの操作が害を起こし得るのかをチームが把握しているかに依存します。リポジトリに本物の秘密情報が含まれているなら、露出後に非公開にするのは誤った問題を解いています。秘密情報をローテーションし、可能な範囲で履歴から削除し、古い成果物を無効化し、インシデント対応経路を文書化してください。公開境界が重要なのは、外部に出る出力には、ローカル分析より強い基準が必要だからです。

だからこそ、GDSのガイダンスは正しく感じられます。このガイダンスは、AIが脆弱性発見を変えることを否定していません。浅い結論を拒んでいるのです。AIによって弱いシステムは調べやすくなります。だから答えは、システムをより所有しやすく、監査しやすく、報告しやすく、修復しやすくすることであるべきです。

今日やるなら

AIによるリポジトリパニックに直面しているチームは、初期設定を変える前に、48時間の公開コードレビューを実施すべきです。

1. 公開リポジトリを棚卸しし、それぞれを責任者に紐づける。
2. 現在のツリーとgit履歴に対して秘密情報スキャンを実行する。
3. 各リポジトリにセキュリティ連絡先または開示ポリシーがあるか確認する。
4. 不正、不正利用、稼働中アーキテクチャ、未公開ポリシーに関する例外を特定する。
5. 依存関係更新、パッチリリース、ロールバックの経路を確認する。
6. 名前の付いた例外に該当する特定のリポジトリだけを閉じる、または公開を遅らせる。
7. 将来のチームが同じパニックを繰り返さないように、判断基準を公開する。

この計画は、リーダーに実際の管理面を与えます。同時に、証拠も作ります。将来のレビュー担当者は、なぜあるリポジトリは公開のままだったのか、別のリポジトリはなぜ非公開になったのか、どの作業が実際のリスクを下げたのかを確認できます。

FAQ

AIによって公開コードはより危険になりますか？

AIによって公開コードは調べやすくなります。そのため、チームは脆弱性報告の増加と自動化された探索の増加を想定すべきです。危険は、未修正の脆弱性、露出した秘密情報、弱い対応ループから生まれます。公開されていることで発見は増えますが、非公開化しても根本のバグは消えません。¹

リポジトリを非公開にすべき場合はありますか？

あります。秘密情報、不正対策、機微な稼働中アーキテクチャ、未公開ポリシー、その他の具体的な害を含む、または明らかにするコードは制限すべきです。例外は文書化し、その理由が失効したときに見直す必要があります。³⁶

レビューが終わるまで、すべて閉じてはいけないのですか？

一律の閉鎖は、不確かな保護と引き換えに、実際に存在する公開の利点を手放します。GDSは、以前公開されていたコードが、すでにミラー、フォーク、クローン済みのコピーに存在している可能性があると警告しています。¹ 短く絞ったレビューのほうが、責任体制の問題を隠す無期限の初期設定より優れています。

公開リポジトリを十分に安全と言う前に、何が必要ですか？

少なくとも、秘密情報がないこと、責任者がいること、ライセンスがあること、明確なセットアップ手順、依存関係更新の実務、セキュリティ連絡先または脆弱性開示経路、そして修正を素早く届けられるリリースプロセスが必要です。

これはAIコーディングエージェントとどう関係しますか？

エージェントは同じ境界問題を広げます。リスクが1つの見えるファイルに収まることはまれです。権限、生成物、キャッシュ、外向きリクエスト、ビルド状態、リリース権限にまたがります。良いエージェントセキュリティも良いオープンソース方針も、そうした境界で証拠を求めます。

参考文献