Microsoftは2026年11月5日、AIを使って公開GitHub上の認証情報を探し、クラウドへの不正アクセスに利用する攻撃を報告しました。一つの観測例では、秘密情報の探索開始から、認証情報などを保管するAzure Key Vaultのデータ持ち出しまで、5分で進んでいました。

サイトや業務システムを運営する事業者にとっては、開発会社が扱う「プログラム用の鍵」の保管場所と、漏れたときに止められる担当者を確認するきっかけになります。

「5分」は探索開始から。公開直後の被害とは限らない

Microsoftが観測したのは、公開されたコードから、アプリの認証情報やAPIキーなどを探す攻撃です。これらはプログラムがサービスへ接続するための鍵で、見つけた人がその権限を悪用できる場合があります。

報告では、AIが探索だけでなく、その後の不正アクセスにも使われています。「5分」は一つの事例における探索開始からデータ持ち出しまでの時間であり、コードの公開からの時間や、攻撃全体の平均ではありません。Microsoft自身の情報漏えいや、Key Vaultという製品の脆弱性を発表したものでもありません。Microsoftの報告

外注しているサイトでも、公開コードの管理は確認したい

自社でGitHubを操作していなくても、委託した開発会社がコードを保管していることがあります。事業担当者は、まず次の点を開発・保守担当者に確認すると、対策の担当と範囲を整理できます。

  • 自社のサイトやアプリのコードは、どの組織・アカウントで管理しているか
  • 公開しているコードや設定ファイルに、実際に使える鍵が含まれていないか
  • 漏えい検知の通知を誰が受け取り、休日を含めて誰が対応するか
  • 鍵を停止すると、どの機能が止まり、誰が復旧作業を行うか

ここで確認したいのは、コードを公開すること自体の是非ではなく、公開物に認証情報が混入しない運用です。非公開の保管先についても、アクセスできる人と認証情報の管理方法を把握しておく必要があります。

公開前に止める機能と、通知後の対応をセットで確認

GitHubの「push protection」は、コードを登録する際に対応する秘密情報を検出し、登録を止める機能です。公開後に発見するだけでなく、漏えいを事前に防ぐための仕組みとして使えます。

ただし、検出対象や設定による違いがあります。利用者個人向けの保護と、コードの保管先であるリポジトリ向けの保護では、保護を回避した際の通知も異なります。「GitHubを使っているから、すべての鍵が自動的に守られる」とは考えず、設定と通知先を確認してください。GitHubのpush protectionの説明

漏れた鍵は、ファイルから消すだけで終わらせない

漏えいが分かった場合、ファイルから鍵を削除しても、すでにコピーされた鍵は使われ続ける可能性があります。GitHubも、コードの削除だけでは対処にならず、鍵の失効が重要だと説明しています。

技術担当者には、鍵の失効・必要な再発行、利用サービスの切り替えと動作確認、不正利用の有無の調査を依頼します。失効によるサービス停止の影響も確認が必要ですが、その調整を理由に有効な鍵を放置しない判断が求められます。利用履歴の保存や調査も含めて対応してください。GitHubの漏えい対応手順

認証情報の権限や、開発用と本番用の分離については、開発環境と本番環境の管理を解説した記事で整理しています。

今回の報告から事業者が確認したいのは、「漏れたら後で消せばよい」という運用になっていないかです。公開前の検査と、発見後に鍵を止める担当・手順をそろえておくことが、初動の遅れを減らします。

2026年11月8日時点の公開情報に基づきます。日本国内の被害件数や、自社環境への影響を示す報告ではありません。