米国のサイバーセキュリティ機関であるCISA（Cybersecurity and Infrastructure Security Agency）において、契約業者（コントラクター）が運用していたGitHub上の公開リポジトリに、クラウド環境へのアクセスキーやパスワードなど、機密性の高い認証情報が約6か月間にわたり含まれていたことが、外部研究者の指摘と報道によって明らかになりました。脅威は「侵入」だけでなく、設定ミスや運用の隙からも発生し、こうした認証情報の漏えいはシステムへの不正アクセスにつながる重大なリスクとなります。
事案の詳細
今回取り上げられたのは、CISAが外部の契約業者を通じてGitHubで運用していたコードや設定ファイルの扱いに起因して、外部に見られてはいけない情報が公開状態になっていたという問題です。問題のリポジトリは「Private-CISA」と名付けられていましたが、実際には2025年11月から約6か月間にわたって公開されており、誰でも閲覧できる状態になっていました。GitHubはソフトウェア開発で広く使われるサービスで、公開設定のリポジトリは基本的に誰でも閲覧できます。
元記事が焦点を当てるのは、攻撃者が高度なゼロデイ脆弱性を突いたというよりも、「公開してはいけない情報が、公開の場に置かれていた」点です。問題のリポジトリには、AWS GovCloudの管理者キー、データベースや社内システムの平文パスワード、GitHubなど開発環境へのアクセス用トークン、さらにRSA秘密鍵など、クラウドや内部システムに対する広範なアクセス権限を持つ「秘密情報（シークレット）」が含まれていました。こうした情報は第三者に悪用されると、アカウント乗っ取りやシステム内部への不正アクセス、さらには政府システムへの侵入足掛かりとなる可能性があります。
また、公開された情報は「見つけた人だけが得をする」性質があります。検索や自動収集の仕組みを使えば、公開リポジトリから鍵やパスワードらしき文字列を探すことは難しくありません。実際、今回の事案でも、外部のセキュリティ研究者が公開リポジトリをスキャンする中で、明らかに機密性の高い認証情報を含むファイル名や設定ファイルを発見し、報道機関を通じてCISAに連絡したことで問題が顕在化しました。いったん外部に露出した可能性がある情報は、削除しても複製されている前提で対応する必要があり、被害の芽を早期に摘むことが重要になります。
CISAは通知を受けた後、問題のリポジトリを非公開化・削除し、関連するクラウド環境の一時停止、露出した資格情報のローテーション（無効化と再発行）、契約業者のアクセス権限の見直しを行ったとされています。また、調査の結果、当該資格情報が悪用された形跡はログ上では確認されていないと説明していますが、ログが完全である保証はないため、専門家の間では「悪用が起きていない」と断定することには慎重な見方もあります。
事後に公開されたCISAの検証レポートでは、(1)秘密情報をコードリポジトリに含めないこと、(2)公開リポジトリを継続的にスキャンして露出した秘密情報を検知すること、(3)資格情報漏えいに特化したインシデントレスポンスのプレイブックを事前に整備すること、(4)外部研究者からの報告窓口を明確かつ簡便にすること、といった教訓が整理されています。CISA自身も、今回の事案を受けて開発者の秘密情報管理を強化し、公開リポジトリの継続的スキャンとキー管理プロセスの改善に着手したと説明しています。
日本への影響
日本の中小企業でも、GitHubや類似のコード共有サービス、クラウドの設定管理を外部ベンダーや少人数の情シスが兼務するケースは多く、同種の「うっかり公開」「鍵の混入」は現実的なリスクです。今回のCISAの事案では、契約業者が自らの作業効率や検証のために、CISAのビルド・デプロイ用リポジトリを個人のGitHubアカウントにコピーしていたことが、重大な漏えいにつながりました。契約業者や委託先が、組織のポリシーを十分に理解しないままクラウドやコード共有サービスを利用すると、同様の事態は日本企業でも起こり得ます。
攻撃者にとっては企業規模は関係なく、外部から到達できる場所に有効な鍵が落ちていれば標的になります。公開されたリポジトリから認証情報を自動収集するツールや検索手法は広く利用可能であり、海外での事例は、国内でも起こり得る運用上の落とし穴を具体的に示しています。特に、クラウド管理コンソールやVPN、リモートデスクトップ、ソースコード管理システムなどへの鍵が一度でも公開されれば、たとえ短時間でも攻撃者に悪用されるリスクがあります。
さらに、CISAの事案が示したように、「インシデント報告の窓口が分かりづらい」「資格情報漏えいに特化した対応手順が整備されていない」といった組織的な問題は、日本企業・団体にも共通しがちです。誤って秘密情報を公開してしまった場合に、誰が、どのシステムの、どの鍵を、どの順序でローテーションし、どのログを確認するのかといった具体的な手順が事前に定められていないと、対応が遅れ、被害の範囲が拡大するおそれがあります。
対策・今後の展望
- 公開範囲の棚卸し：GitHub等で自社・自社プロジェクト、委託先や個人アカウントを含めて、組織に紐づく公開リポジトリが存在しないか一覧化し、公開が必要なものだけに絞る。名前に「private」などと付いていても設定が公開になっていれば誰でも閲覧できるため、リポジトリ名ではなくアクセス設定を確認することが重要です。
- 「鍵」をコードに入れない運用：APIキーやトークン、パスワード、クラウド管理コンソールやVPNの認証情報などをソースコードや設定ファイルに直接書かず、環境変数や専用の秘密情報管理（シークレットマネージャー、キーマネジメントサービス）に移す。契約業者や外部開発者にもこの方針を徹底し、「個人用の検証リポジトリ」に組織の秘密情報をコピーしないルールを明文化します。
- 漏えい前提のローテーション：過去に公開場所へ置いた可能性がある鍵は、削除ではなく無効化・再発行を基本とし、関連するアクセス権限も見直す。今回のCISA事案では、一部の鍵やトークンの失効が遅れたことが問題視されました。秘密情報の種類ごとに「漏えい時にどの順序でどのシステムの鍵をローテーションするか」を事前に定義し、テストしておくことが有効です。
- 自動検知の導入：リポジトリへのプッシュ時に秘密情報を検知するプリコミットフックやCI/CDパイプライン上のスキャン機能、GitHub等が提供するシークレットスキャン機能を有効化し、定期的な全リポジトリのスキャンを実施する。CISAの教訓でも、公開・非公開を問わずコードリポジトリを継続的にスキャンする仕組みの重要性が強調されています。
- 権限とレビュー：公開設定の変更や外部公開は複数人レビューを必須にし、個人の判断だけで公開されない手順にする。特に、契約業者や外部パートナーが組織のコードや設定を個人アカウントにコピーすることを禁止し、例外的に必要な場合は事前承認とセキュリティレビューを求めることで、「個人の便宜」が重大な漏えいにつながるリスクを減らします。
- 報告窓口とインシデントプレイブックの整備：外部の研究者やベンダーが誤公開を発見した際に、迅速かつ確実に連絡できる窓口（メールアドレス、Webフォームなど）を明示し、資格情報漏えいを想定したインシデント対応手順書（プレイブック）をあらかじめ準備しておきます。これにより、露出からローテーション完了までの時間を最小化できます。
CSRIからの現場アドバイス
【観点①：現場で何が起きているか】MDRや診断の現場では、侵入痕跡より先に「外部に露出した鍵」が入口になる例が目立ちます。今回のCISA事案のように、クラウド管理コンソールや内部システムの認証情報が公開リポジトリから見つかるケースでは、攻撃者はわざわざ高度な脆弱性を探さなくても、正規の認証情報を使って内部に踏み込むことができます。海外事例は収集ツールで迅速に広まり、日本企業でも公開設定のまま放置された資産が先に狙われがちです。
【観点②：平易な解説】例えるなら、会社の金庫の鍵を玄関先に置いたままにするようなものです。つまり、システムそのものが強くても、入るための合鍵がネット上に落ちていれば、誰でも正規の手順で入れてしまうということです。今回の事案で露出していたのは、クラウド環境や社内システム全体に広範な権限を与える「マスターキー」に相当する情報であり、攻撃者にとっては極めて価値の高い標的でした。
【観点③：今週中にできること】まず、自社名や製品名、委託先企業名で公開リポジトリがないか確認し、不要な公開は非公開にします。次に、過去の設定ファイルやサンプルコード、個人アカウントにある検証用リポジトリに鍵やパスワードが入っていないか検索し、見つけたら無効化と再発行を担当者に指示します。その際、クラウド管理鍵、データベース接続情報、VPNやリモートアクセス用アカウントなど、影響範囲の広いものから優先的にローテーションし、アクセスログの確認と異常な利用有無の点検も並行して行うことが推奨されます。