セキュリティニュース：GitHub上の秘密情報漏えいを、発見から復旧まで設計する（2026年7月19日）

キーワード: GitHub / シークレット管理 / AWS GovCloud / 通報窓口 / キーローテーション / 継続監視

何が公開されていたのか

• CISAの委託先に関係する公開GitHubリポジトリ「Private CISA」には、844MBの機微データが含まれていたと報じられた。
• 「importantAWStokens」には三つのAWS GovCloudサーバーの管理用認証情報があり、別ファイルには多数の内部システムの平文ID・パスワードが含まれていた。
• 公開されていたこと自体は侵害成功の証明ではない。しかし、閲覧・複製・悪用の機会を長く与えるため、秘密情報の露出として直ちに扱う必要がある。

なぜ長期化したのか

• このリポジトリは、発見・通報までおよそ6か月公開されていた。
• GitGuardianは自動検知の通知を9回送ったが、Krebsへの連絡前には応答されなかったと説明している。
• 四半期ごとの点検では、公開から次の点検までの時間が攻撃者の猶予になり得る。公開コードの監視は継続的な運用として設計する。

通報が届かないと何が起きるか

• 研究者は委託先への連絡、CISAの脆弱性開示窓口、報道機関という複数の経路を試す必要があった。
• 製品の欠陥報告窓口と、自組織の漏えい通報窓口を混ぜると、緊急度の高い通知が適切な担当へ届かない。
• security.txtの公開だけで終えず、組織サイトや開発者向けページにも、秘密情報漏えいの連絡先と受領後の扱いを明示したい。

48時間の無効化が示す難しさ

• CISAは通知を受けた後、AWSの鍵など重要な秘密情報の無効化に48時間超を要した。システムや連携先の複雑さが背景と説明している。
• 鍵を失効させると、攻撃を止められる一方で、依存する業務や自動処理が止まる可能性がある。
• だからこそ、所有者、利用先、代替の認証手段、復旧手順を平時から対応付ける。漏えい時に初めて依存関係を調べる運用では遅い。

監視・手順・証跡をつなぐ

• CISAは全ての秘密情報をローテーションし、開発用秘密情報の管理と監視を改善する行動計画を作成した。
• 既存のインシデント対応手順には、GitHubなどクラウドサービスでの漏えいへの対応が十分に含まれていなかった。
• 詳細なログとゼロトラストの運用により、顧客・任務データの流出や、認証情報のCISA環境外での使用は確認されなかったとしている。
• 無効化だけを完了条件にせず、公開範囲、利用履歴、権限変更、データアクセスを検証し、証跡を残す必要がある。

明日からの優先順位

• 最初に、公開リポジトリ、過去のコミット、添付ファイル、バックアップに秘密情報が残っていないかを継続的に確認する。
• 見つけた場合は、削除より先に利用中の鍵・トークン・パスワードを無効化またはローテーションし、利用先への影響を管理する。
• 次に、外部研究者からの通知を受ける専用窓口、24時間以内の受領確認、担当へのエスカレーションをテストする。
• 最後に、漏えい対応の演習で、誰が停止を決め、誰が認証情報を更新し、誰がログを調べるかを確認する。

まとめ

• この事例の教訓は、秘密情報を公開しないことだけではない。発見、通報、無効化、影響確認までを、時間目標と責任者を伴う一続きの運用にすることである。
• 優先度が高いのは、公開状態の有無、現在も有効な認証情報、外部からの通報経路、そして無効化後の影響確認である。

参考ソース

• Krebs on Security: Lessons Learned from CISA’s Recent GitHub Leak — https://krebsonsecurity.com/2026/07/lessons-learned-from-cisas-recent-github-leak/