ブログ一覧に戻る
ベストプラクティス2026年11月5日4分で読めます

リポジトリからシークレットを削除しても手遅れ――漏洩したキーは即座にローテーションせよ

Deleting a leaked key from your repo doesn't protect you

ベストプラクティス

この記事のポイント

【なぜ重要か】 GitHubに誤ってAPIキーなどのシークレットをコミットした場合、ファイルの削除やgit履歴の書き換え、リポジトリの削除を行っても、漏洩したシークレットには依然としてアクセス可能な状態が続く。実際にLiteLLMは2024年5月に管理者キーを誤ってパブリックリポジトリにコミットし、その4か月以上後に攻撃者がそのキーを悪用してGitHubトークンを窃取し、悪意のあるリリースを公開す...

【なぜ重要か】 GitHubに誤ってAPIキーなどのシークレットをコミットした場合、ファイルの削除やgit履歴の書き換え、リポジトリの削除を行っても、漏洩したシークレットには依然としてアクセス可能な状態が続く。実際にLiteLLMは2024年5月に管理者キーを誤ってパブリックリポジトリにコミットし、その4か月以上後に攻撃者がそのキーを悪用してGitHubトークンを窃取し、悪意のあるリリースを公開するという被害を受けた。攻撃者はインターネット上のシークレットを常時スキャンしており、公開された瞬間にすでに取得済みと考えるべきである。

【ポイント】

  • ファイルを削除しても無効:シークレットスキャナーはgit履歴を解析し、削除済みファイルも検査対象とするため、後続コミットでファイルを削除しても漏洩したシークレットは検出可能なままとなる。
  • git履歴を書き換えても無効:force pushで該当コミットをブランチの到達範囲から除外しても、GitHubはそのコミットのSHA-1ハッシュを知っている者に対してコミット内容を引き続き提供する。短縮ハッシュ(最短4文字)から推測・発見される可能性もある。
  • リポジトリを削除しても無効:誰かがリポジトリをフォークしていた場合、GitHubはそのフォーク上に「削除済み」コミットを無期限に保持する。また、削除前に誰がクローンしたかを把握する手段はない。
  • 唯一の有効な対処法はクレデンシャルのローテーション:漏洩したキーを即座に無効化し、新しいキーを発行して、旧キーを使用していたすべての箇所を更新することが唯一の完全な対策である。ローテーション後は、旧キーがすでに悪用されていないか、アクセスログ・mainブランチへの最近のコミット・CIパイプラインの設定変更などを確認し、悪用の痕跡があればインシデントとして対応する必要がある。
  • Aikidoによる検出支援:Aikido Secrets DetectionはGitHub・GitLab・Bitbucket・Azure DevOpsのリポジトリ(公開・非公開問わず)をスキャンし、git履歴に含まれるシークレットも検出できる。Live Secret Detectionで漏洩キーがまだ有効かどうかを確認し、Secrets AutoTriageでテスト用の偽陽性を除外する。IDE拡張機能・pre-commitフック・CI/CDとの連携によりコミット前の早期検出も可能。さらにAikido Device Protectionは開発者のローカルマシン上のシェル履歴などからもハードコードされたシークレットを検出する。MITライセンスで無償公開されているオープンソースエンジン「Betterleaks」は誰でも単独で利用できる。

【まとめ】 シークレットが一度でも公開されたら、削除・履歴改ざん・リポジトリ削除では不十分であり、即座にクレデンシャルをローテーションすることが唯一の有効な対策である。まずAikido Secrets DetectionまたはBetterleaksで自社リポジトリに漏洩済みシークレットがないかスキャンし、発見次第ただちに無効化・再発行を実施することを推奨する。

原文を読む

Aikido Security Blog

英語で詳細な技術情報を確認

原文を読む

コメント・質問

この記事についてのコメントや質問を投稿できます

コメントを投稿するにはログインが必要です

ログインする

読み込み中...