公開したプログラムに、組織の内部データへアクセスできる認証情報が残っていたら、どうなるでしょうか。英国の公共部門で見つかった問題は、コードの閲覧だけでは済まず、人事記録や業務資料へのアクセスにつながり得るものでした。調査に使われたのは、特殊な攻撃専用システムではなく、ノートパソコンと一般向けに提供されている生成AIモデルです。

セキュリティ企業ControlPlaneの研究者クリス・ネズビット＝スミス氏は、英国の公共部門が公開するコードから、100件を超える深刻な脆弱性を発見しました。調査対象は33組織の349コードベースで、同氏によると、その約3分の2で脆弱性が見つかっています。コードベースとは、あるサービスやシステムを構成するプログラム群のことです。



分析には、Anthropicが提供するClaudeのOpusとSonnetが使われました。ただし、ネズビット＝スミス氏が強調しているのは、攻撃手法の高度さではありません。発見した問題の多くは、通常のIT点検でも見つけられる性質のものだったと説明しています。生成AIが、基本的な管理不備を広い範囲から探す作業を助けた事例として捉えるのが適切でしょう。

企業にとっての論点も、AIが未知の攻撃を生み出すかどうかだけではありません。これまで点検の手が届かなかったコードや設定を、第三者が確認しやすくなる点にあります。公開前の確認や日常の保守が追いついていなければ、発見の効率化は防御側だけの利点にはなりません。今回の事例は、生成AIの活用を進める前提として、既存の認証情報とアクセス権限を管理できているかを問い直しています。

特に深刻だったのが、イングランドの土地利用に関する審査や不服申し立てなどを扱うPlanning Inspectorateの事例です。同機関は、コードの共有・管理サービスGitHubの公開リポジトリに認証情報を誤って登録した後、その情報を完全には無効化できていませんでした。認証情報が外から見える状態になったことに加え、その権限の広さと、有効期限が設定されていなかったとみられることが危険性を高めています。

研究者によると、問題のMicrosoft Entra IDに関係する認証情報は、組織内のすべてのSharePointサイトと、職員個人に割り当てられたOneDrive領域に対する読み書きを可能にするものでした。Entra IDは、利用者やアプリケーションの認証、アクセス管理を担うサービスです。ソースコードを閲覧するための情報から、文書共有や個人用の保存領域まで影響が広がり得た点が、この問題の核心にあります。



対象には人事記録のほか、法定の計画審査や不服申し立てに関連し、証拠保全のために保持される機密性の高い資料も含まれると研究者は説明しています。同氏は、データの窃取や暗号化を通じた身代金要求につながる余地があったと指摘しました。ただし、これは想定される被害であり、そうした攻撃の実行が確認されたという意味ではありません。

Planning Inspectorateは、8月の研究者の活動を監視ツールが直ちに検知し、ControlPlaneから連絡を受ける前からサイバーインシデントとして対応していたと説明しています。報告から20分以内に脆弱性を修正し、データ侵害がなかったことも確認したとしています。発見された危険性と実際の被害は、区別して受け止める必要があるでしょう。

英国政府は、公費で開発したコードを原則として公開する方針を、およそ10年にわたり採ってきました。透明性を確保するとともに、他の組織がコードを再利用しやすくして、開発費用の効率化につなげる狙いがあります。対象には保健・社会福祉省や内務省、地方自治体などが含まれます。公開そのものには、行政が何を作り、どう運用するかを外部から確認しやすくする意味があります。

ただし、プログラムを公開できることと、そこに含まれるすべての情報を公開してよいことは同義ではありません。認証情報や内部向けの設定には、コードとは異なる管理が必要です。非営利の業界団体OpenUKの最高経営責任者アマンダ・ブロック氏も、Planning Inspectorateの問題はオープンソースそのものではなく、公開ツールを使う際の内部管理と手順の不備にあると指摘しています。



この違いは、日本企業がGitHubなどを利用する際にも当てはまります。公開したプログラムは、設計や処理の仕組みを示します。認証情報は、実際のシステムへ入るための鍵として働きます。コードを再利用できる状態にする判断と、その鍵を誰に渡すかという判断は、分けて設計しなければなりません。両者が同じファイルや作業手順の中で扱われると、公開時の事故につながりやすくなるでしょう。

英国の各部門では、予算の圧迫を背景に、技術資産の保守や改善が十分に行われてこなかった状況も伝えられています。ただし、それだけで個別の不備の原因を説明できるわけではありません。企業側が読み取るべきなのは、コード公開の方針だけを決めても、安全な運用は続かないという点です。点検、権限の見直し、認証情報の更新を担う担当者と時間まで確保して、初めて運用上の方針になると考えられます。

今回の調査では、教育分野のコードからも複数の脆弱性が見つかりました。対象には、学校向けの調達サービス、教員の応募を扱うサービス、公的資金による研修事業者や職業訓練に関するイングランドの主要登録システムが含まれています。教員の応募サービスは、個人情報、資格、職歴、本人確認書類を扱うものでした。サービスの用途によっては、技術的な欠陥が個人の機微な情報に接近する経路になります。

スコットランド政府のオープンデータポータルでは、訪問者が管理者アカウントの情報を読み取り、サイト設定を変更できる脆弱性も見つかっています。関係組織は、その後これらの問題に対応しました。ただし、発見された個々の脆弱性について、AIがどの工程を担い、人間がどこまで検証したかという詳細は示されていません。Claudeだけで調査のすべてを完結できたと受け取るのは早計でしょう。



生成AIを点検に使う利点として考えられるのは、多数のコードを読み、確認すべき箇所を絞り込む作業を補助できることです。人間がすべてを同じ密度で読むことは難しくても、候補が整理されれば、限られた時間を重要な確認に振り向けやすくなります。今回の調査規模は、その活用方法を検討する材料になります。

もっとも、怪しい記述を見つけることと、実際に悪用可能な脆弱性だと判断することには距離があります。認証情報が現在も有効か、どの環境につながるか、どの範囲の操作を許すかによって、対応の優先順位は変わるためです。企業が導入するなら、AIが出した指摘の数だけを成果にするのではなく、検証と修正まで進められる体制に組み込む必要があります。点検範囲を広げた分だけ、確認を担う人員への負荷も考慮すべきでしょう。

AIによって脆弱性の発見が速くなるなら、コードを公開しない方が安全ではないか。この議論も英国の公共部門で起きています。英国の公的医療制度NHSでは、AIモデルの影響に対する安全上の懸念から、5月に技術チームへコードの公開から離れる方向への移行が指示されたと報じられています。ただし、この情報から、NHS全体がオープンソース製品の利用をやめたと読み替えることはできません。

ネズビット＝スミス氏は、根本的な問題を修正せずにリポジトリだけを閉じる対応を懸念しています。公開されていたコードは、すでに第三者が複製している可能性があるためです。非公開に変更しても、手元に残った複製まで消えるわけではありません。問題の発見に協力する研究者のアクセスを断つ一方で、悪意ある相手が過去の情報を保持し続ける状況も考えられます。



一般的な認証の仕組みでも、公開場所から文字列を削除する操作と、その文字列を使えなくする操作は別です。外部に知られた鍵がまだ有効なら、掲載先を閉じてもアクセスの可能性は残ります。流出した認証情報の失効や更新、付与権限の見直しが必要になるのは、このためです。履歴や複製に情報が残ることを前提に、認証を受け付ける側で対処しなければなりません。

公開範囲の変更が必要になる場面はあるでしょう。しかし、その判断だけで対応完了とすることは避けたいところです。自社で同様の事象が起きた場合は、公開状態の変更に加えて、認証情報が無効になったか、利用履歴に不審な動きがないか、影響するデータは何かを確認する必要があります。今回の事例が示すのは、コードを見せるかどうかより先に、漏れた情報が何を可能にしてしまうのかを把握する必要性です。

今回の問題を自社の対応につなげるなら、公開リポジトリに秘密情報がないかを確認するだけでは十分ではありません。見つかった情報が、どのシステムに接続でき、どの操作まで許可されているかを追う必要があります。Planning Inspectorateの事例でも、危険性を高めたのは認証情報の公開に加え、組織内の広い範囲へ読み書きできる権限でした。発見から影響範囲の確認までを、一続きの作業として扱うことが出発点になります。

点検対象は、現在のファイルだけに限りません。一般に、コード管理では過去の変更履歴が保存されるため、最新の状態から削除した情報が履歴に残ることがあります。公開リポジトリとその履歴を確認し、有効な認証情報が見つかった場合は失効や更新を進め、接続先と利用状況を調べる流れが必要です。その上で、業務に必要な範囲まで権限を絞れるかを検討するとよいでしょう。



生成AIの利用も、この流れの中で判断できます。大量のコードから確認候補を見つける用途は検討できますが、社内コードや認証情報を外部サービスへ入力する場合は、利用条件と自社の情報管理ルールとの整合を確認しなければなりません。今回、一般向けモデルが使われたという事実は、どの企業でも同じ方法をそのまま採用できることを意味しません。扱う情報に合った利用環境を選ぶ必要があります。

担当者が最初に行う作業としては、自社の公開リポジトリを一つ選び、認証情報の点検から、接続先、権限、管理担当者の確認まで進める方法が考えられます。そこで更新手順や責任分担が曖昧な箇所が見つかれば、対象を広げる前に修正できます。AIによる検出件数を増やすことを先に目標とせず、見つかった鍵を確実に使えなくし、必要な権限へ戻せるかを確かめる。その実務が、発見の速さを防御の改善につなげます。