secrets-audit

シークレット監査 — 認証情報の露出とシークレット管理のレビュー

2 つの側面があります：（1）ソースコード、履歴、成果物にすでに漏洩したシークレットを見つけること、（2）今後の漏洩を左右するシークレット管理体制を監査することです。

シークレットの漏洩は、「秘匿化を忘れた」というより、「仕組みがなかったため、開発者それぞれが独自の方法を考え出していた」ことが原因である場合がほとんどです。このスキルでは、事後対応と予防の両方を扱います。

関連項目：dependency-audit（ビルド時の露出に伴う CI 関連のシークレットリスク）、iam-audit（有効期間の長いキーに代わるワークロード ID フェデレーション）、owasp-audit A02（ソースコード内のシークレットのパターン）。

パート 1 — 漏洩したシークレットを見つける

プロバイダーのキー接頭辞（確度の高いパターン）

最も有効な初回調査は、既知のプロバイダーのキー接頭辞を grep で検索することです。誤検出は少なく、ヒットはほぼすべて実際のシークレットです。

# Stripe
grep -rE "(sk_live_|sk_test_|rk_live_|whsec_)[A-Za-z0-9]{20,}" . \
  --include="*.{js,ts,jsx,tsx,py,rb,go,java,php,sh,env,yml,yaml,json}"

# AWS access keys
grep -rE "(AKIA|ASIA)[A-Z0-9]{16}" .

# AWS secret keys (40 chars, base64-y) — high FP rate, use with caution
grep -rE "[A-Za-z0-9/+=]{40}" . --include="*.env*" --include="*.json"

# GitHub
grep -rE "gh[pousr]_[A-Za-z0-9]{36}" .

# Google Cloud API key + service-account JSON
grep -rE "AIza[A-Za-z0-9_-]{35}" .
grep -rln '"type": "service_account"' . --include="*.json"

# Slack
grep -rE "xox[baprs]-[A-Za-z0-9-]+" .

# OpenAI / Anthropic
grep -rE "sk-[A-Za-z0-9]{32,}" .
grep -rE "sk-ant-[A-Za-z0-9_-]{90,}" .

# Generic high-entropy strings in env files
grep -rE "^[A-Z_]+=[A-Za-z0-9/+=]{32,}$" . --include="*.env*"

リポジトリ全体を対象にするには、git ls-files を使って追跡対象ファイルに絞り、node_modules を除外します。

git ls-files | xargs grep -lE 'sk_live_|ghp_|AKIA[A-Z0-9]{16}|sk-ant-|AIza[A-Za-z0-9_-]{35}' 2>/dev/null

ツール

ツール	用途
gitleaks detect	高速で誤検出が少なく、コミット前および CI で実行できます。カスタムルールに対応しています
trufflehog git file://.	実際の API に対して検出結果を検証します（確度が高いです）
detect-secrets scan	Yelp のツールです。ベースラインファイルを使ったワークフローに適しています
GitHub Secret Scanning	パブリックリポジトリでは無料です。ほとんどのプロバイダーを自動的にカバーします。有効にしてプッシュ保護を設定すると、プッシュ時にブロックされます
GitLab Secret Detection	同様の機能が CI に組み込まれています
GitGuardian / Doppler / Spectral	商用ツールです。組織向けダッシュボードや履歴分析を追加できます

Git の履歴（忘れられがちな部分）

最新のコミットでシークレットを削除しても、履歴には残っています。git log -p、git log -S<secret>、さらにすべてのフォークやローカルクローンにも含まれています。

# Search every commit for a pattern
git log -p -S "sk_live_" --all

# Search only deleted lines
git log -p --all | grep -E "^-.*sk_live_"

# Trufflehog historical scan
trufflehog git file://. --since-commit=<first-commit>

# Git history rewrite — destructive, coordinate first
git filter-repo --invert-paths --path config/secrets.yml
# or
bfg --delete-files secrets.yml

重要な注意点： 履歴を書き換えるには、すべての開発者が再クローンする必要があります。また、すべてのフォークで引き続き露出したままです。いずれにしても、シークレットは漏洩したものと見なしてください。必ず先にローテーションを行い、その後で履歴を書き換えてください。

ビルド成果物など、見落とされがちな場所

シークレットは .env ファイル以外の場所からも漏洩します。

• Docker イメージ — docker history <image> で各 ENV 行を確認できます。--build-arg SECRET=... はレイヤーに残ります
• CI 環境 — set -x、console.log(process.env)、エラースタックトレース、デバッグ出力によってログに記録されたシークレット
• フロントエンドバンドル — NEXT_PUBLIC_* / VITE_* / REACT_APP_* の環境変数はブラウザーに配信されます。バンドルされた JS を grep で検索してください
• クラッシュレポート — Sentry / Datadog / Bugsnag が process.env のスナップショットを取得
• ログ — アプリよりアクセス制御の弱い SIEM に転送されたアプリケーションログ
• バックアップ — ユーザーが保存した API キーを含むテーブルの pg_dump
• パブリック S3 / blob ストレージ — .env が誤ってアップロードされた場所
• ドキュメント — プレースホルダーではなく実際のキーを記載した README.md の例
• Slack / Notion / Linear — 「テスト用」に DM に貼り付けた後、ローテーションされていないもの
• ブラウザーの localStorage / Cookie — 共有スクリーンショットやセッションリプレイに記録されたもの

発見したシークレットのトリアージ

漏えいしたシークレットを見つけた場合：

1. 有効か確認する — プロバイダーの検証方法（aws sts get-caller-identity、stripe balance retrieve、curl -H "Authorization: Bearer $TOKEN" ...）を使います。決めつけてはいけません。漏えいしたキーの中には、すでに無効化されているものや、サンドボックス専用のものがあります。
2. 漏えい期間を特定する — 最初にそのキーが登場したコミット、リポジトリが公開された日時、CI ログが保持されていた期間を確認します。
3. 影響範囲を特定する — このキーで何にアクセスできるのか、何ができるのかを確認します。IAM の権限、Stripe の本番環境かテスト環境か、GitHub の repo か admin:org かを調べます。
4. ただちにローテーションする — 新しいキーを生成してデプロイし、その後、古いキーを無効化します（先に無効化すると本番環境に支障が出ます）。
5. 使用状況を監査する — プロバイダーの監査ログ（CloudTrail、GitHub の監査ログ、Stripe のイベント）を確認し、漏えいした認証情報によるアクティビティがないか調べます。
6. その後でクリーンアップする — 現在のコードから削除し、必要に応じて履歴を書き換えます（ローテーション後は優先度が低くなります）。
7. 記録する — ローテーションに問題がなかった場合でも、インシデントレポートを作成します。再発パターンから傾向が見えてきます。

パート 2 — シークレット管理体制の監査

シークレット保存方法の階層（最悪 → 最良）

Tier	パターン	許容されるケース
❌	ソースコードにハードコード	ありません
❌	イメージ／ビルド成果物にハードコード	ありません
❌	共有ドキュメント／Slack に平文で保存	ありません
⚠️	リポジトリ内の .env ファイル（.gitignore に含めていても、push、バックアップ、アーカイブ経由で漏えいしやすい）	ブートストラップのみ。監査で指摘対象
⚠️	環境変数のみ	一時的な開発環境では許容されます。本番環境では脆弱です（/proc、クラッシュダンプ、ログから見える可能性があります）。
🟢	デプロイ時にシークレットマネージャーから取得	ほとんどのアプリで標準的です
🟢	ワークロード ID フェデレーション（保存するシークレットが不要）	対応している場合に最適です

クラウドプロバイダーのシークレットマネージャー

• AWS Secrets Manager / Parameter Store (SecureString) — IAM でスコープを限定した IRSA／タスクロール／Lambda ロール経由で統合します。
• GCP Secret Manager — Workload Identity 経由で GSA にバインドし、GSA がシークレットを取得します。
• Azure Key Vault — マネージド ID 経由で取得します。
• Doppler / Infisical / 1Password Secrets Automation — クラウドをまたいで使え、開発者にとって扱いやすいサービスです。

監査チェックリスト

• Git の履歴にシークレットがない（gitleaks --all を実行します）
• .env がコミットされていない — .gitignore で .env* を対象にします（.env.example の扱いには注意してください）。
• シークレットはビルド時に埋め込まず、実行時に取得する — ローテーションのためにイメージを再ビルドする必要はありません。
• IAM のスコープをシークレットごとに限定する — サービス A はシークレット A を読み取れますが、シークレット B は読み取れません。
• ローテーションの頻度 — シークレットのクラスごとに定義します（管理者：30 日、サービス：90 日、顧客と共有するもの：侵害への対応時）。
• ローテーションを自動化する — 人が 90 日ごとにスクリプトを実行する方式では、いずれローテーションが遅れます。
• アクセスを記録する — Get／Decrypt の呼び出しはすべて監査証跡に記録します。
• ワークロードに長期有効なクラウドキーを使わない — 対応しているすべての環境でワークロード ID フェデレーションを使います（iam-audit を参照）。
• 緊急時の手順 — シークレットマネージャーが停止した場合、重要なサービスをどう起動しますか？（通常は、暗号化してディスクにキャッシュし、再起動時に必ず再取得します。）
• 環境間の分離 — ステージング環境から本番環境のシークレットを読み取れることがあってはなりません（異なる KMS キーと IAM を使用します）。

よくある指摘事項

• ローテーションを一度もテストしていない — シークレットストアは設定済みでも、実際にはローテーションされておらず、最初の試行で本番環境に支障が出ます。
• .env.local がステージングに含まれている — 環境固有の開発用シークレットが境界を越えて持ち込まれています。
• フォークからの PR が CI のシークレットにアクセスできる — GitHub のデフォルトの動作は以前、危険なものでした。pull_request_target とシークレットへのアクセス可否を確認してください。
• ビルド引数をシークレットに使っている — --build-arg AWS_SECRET=... はイメージの履歴に残ります。代わりに --secret／BuildKit を使ってください。
• 未処理の例外時にロギングフレームワークが process.env を出力する — Sentry / Datadog / Bugsnag のスクラブ設定が必要です。
• etcd の暗号化なしで、シークレットを平文の K8s Secret として保存している — Base64 はエンコードであり、暗号化ではありません（container-audit を参照）。
• モバイルアプリに OAuth クライアントシークレットを含めている — パブリッククライアントはシークレットを保持できません。解決策は PKCE です。

出力形式

# Secrets Audit Report
## Scope: [repos / environments / managers covered]
## Date: [date]

### Live leaked secrets found
| Provider | Location | First seen (commit / date) | Verified live? | Rotation status |
|---|---|---|---|---|

### Secrets-management posture
| Category | Status | Notes |
|---|---|---|

### Recommendations
| Priority | Item | Owner | Deadline |
|---|---|---|---|

owasp-audit に従った処置方針（修正／延期／リスク受容）。

境界

• ユーザーが監査権限を持つリポジトリ、CI システム、インフラストラクチャのみを監査してください
• 見つかったシークレットをプロバイダーへのアクセスに使用しないでください。最小限の API 呼び出し（データ抽出ではなく、アカウント情報の取得）で有効かどうかを確認し、他へのアクセスを試みないでください
• 履歴を書き換える操作では、明示的な確認と、開発者への通知を調整する計画なしに決して進めないでください
• 他者のリポジトリで見つかった漏えいシークレットの収集や悪用への協力は拒否してください
• 監査で第三者（ベンダー、従業員の個人アカウント）に属する認証情報が見つかった場合は、通知してローテーションしてください。黙って修正しないでください

参考資料

• OWASP チートシート：シークレット管理
• NIST SP 800-57（鍵管理に関する推奨事項）
• GitGuardian「State of Secrets Sprawl」年次レポート — 業界の状況を把握するのに役立ちます
• gitleaks、trufflehog、detect-secrets のドキュメント
• GitHub Secret Scanning と Push Protection のドキュメント
• HashiCorp Vault のアーキテクチャ／ベストプラクティス
• AWS Secrets Manager のベストプラクティス
• 「Twelve-Factor App」— 設定の原則