CISAのAWS GovCloudキーがGitHubに6ヶ月間公開、請負業者の誤設定と9件のアラート無視が事後報告書で発覚

「自社のGitHubに認証情報が誤って混入していないか、確認する方法が分からない」
「セキュリティ専門機関のCISAですら6ヶ月間見落とすなら、うちの会社はもっと危ないんじゃないか……」

チップス

ボス！　CISAがGitHubにAWSのキーを半年間も公開していたって本当でしゅか？　あのサイバーセキュリティの専門機関が……？

ボス

本当だ。しかも事前に9件の自動アラートが届いていたにもかかわらず、誰も動かなかった。技術的な問題ではなく、組織的な問題だったな。

「ツールを入れているから大丈夫」。そう思っている担当者ほど、今回の事件は刺さるはずです。
自動検知が機能していても、アラートを受け取って動ける体制がなければ意味をなしません。
この記事では、CISAが2026年7月13日に公表した事後報告書をもとに、事件の経緯と根本原因、そして日本企業がいまできる対策を解説します。

組織として秘密情報漏洩を防ぐには、ツールを入れるだけでなく「誰が何をするか」を決めた運用体制が必要です。
記事を読めば、自社の対応プロセスをどう整備すべきか、具体的なヒントが見つかります。

CISAのGitHub誤公開事件：844MBの機密データが半年間、公開状態に

2026年7月13日、米CISAが重大な情報漏洩案件の事後報告書を公表しました。

請負業者の「Private CISA」リポジトリから認証情報が流出

発端は、セキュリティ企業GitGuardianの研究員Guillaume Valadon氏が2026年5月15日にKrebsOnSecurityへ連絡したことでした。
CISAの請負業者が「Private CISA」という名称にもかかわらず、Public設定のままGitHubリポジトリを放置していたのです。
リポジトリの公開期間は6ヶ月以上。この間、誰でもアクセスできる状態が続いていました。

リポジトリに含まれていた主な漏洩データは以下の通りです。

AWS GovCloudは、米国政府機関が機密データを扱う専用クラウド環境です。
そこへのアクセスキーが半年間にわたって誰でも取得できる状態にあったという事実は、サイバーセキュリティを管轄する機関としては深刻な失態でした。
KrebsOnSecurityが報道した後、CISAは本格的な調査と事後報告書の作成に着手しました。

通知後にAWSキー無効化まで48時間以上を要した対応の実態

チップス

でも、連絡が来たらすぐに対応できるんじゃないでしゅか……？

ボス

それが48時間以上かかった。報告を受け取る窓口が整っていなかったから、誰が動くべきか決まらなかったんだな。

GitGuardianからの連絡を受けたKrebsOnSecurityがCISAへ通報した後も、AWSキーの無効化には48時間を超える時間が必要でした。
パスワードCSVファイルへの対応はさらに遅れました。

Valadon氏は「6ヶ月の放置を招いたのは技術的な失敗ではなく、対応プロセスの欠如だ」と明言しています。
実際、GitGuardianはCISAに対して9件の自動アラートを送信していましたが、いずれも対応されていませんでした。
アラートが届いていても、受け取った側が動けない体制では、検知ツールは機能しないも同然です。

なぜ9件のアラートが無視されたのか：事後報告書が示す組織的問題

技術的な検知は機能していました。問題は、アラートを受け取った後の組織的な動きにありました。

自動検知は機能していた：報告チャネルの不備が招いた放置

CISAはGitGuardianを利用してGitHub上のシークレット漏洩を自動検知していました。
ところが、アラートを受け取った後に「誰が、何を、いつまでに対応するか」を定めた手順が整備されていませんでした。
9件のアラートはいずれも対応者に届かず、放置されたまま半年が経過しました。

事後報告書でCISAが認めた主な問題点は以下の通りです。

「ツールを入れたら終わり」という感覚で運用していると、アラートは静かに積み上がり続けます。
CISAの事案は、この構造的な問題を世界に向けて示した事例として記録されることになりました。

事後報告書が提言した4つの改善策

チップス

じゃあ、どうすれば良かったんでしゅか？

ボス

CISAが自ら4つの対策を提言している。他人事ではなく、日本企業も今すぐ確認すべき内容だな。

事後報告書でCISAが提言した改善策は以下の4点です。

なかでも重要なのは2点目です。
日本の多くの企業では、GitHubのシークレットスキャン機能を有効にしているだけで、アラートの対応フローが整備されていないケースが少なくありません。
「誰がアラートを受け取り、何時間以内に対応するか」を明文化しておくことが、最初の一歩です。

まとめ

CISAのGitHub漏洩事件が示したのは、「検知ツールがあれば安全」という思い込みの危険性です。
自動アラートが9件届いても対応者に渡らなかった背景には、報告チャネルと鍵管理の手順が整備されていないという組織的な欠陥がありました。

ボス

GitHubのシークレットスキャンを入れているだけでは不十分だ。アラートが来たら誰が動くか、今すぐチームで確認しておくことだな。

チップス

分かりましたでしゅ！　まずはうちの会社のアラート対応フローを上司に確認してみましゅ！

GitHubの高度なシークレットスキャン機能を有効にし、アラートの受信者・対応期限・鍵無効化手順を文書化することが、今日からできる現実的な対策です。
セキュリティ人材の確保や対応体制の整備に課題を感じているなら、外部の専門家との連携も選択肢のひとつです。