要旨

「急いでいたから」「ローカルで動かしたかっただけ」「あとで消せばいいと思った」——Gitにシークレットを混入させてしまう開発者は全員、こう思っていました。

GitGuardianの2026年State of Secrets Sprawlレポートによれば、2025年に公開GitHubリポジトリに新たに追加されたハードコードされたシークレットは2,865万件（前年比34%増）。GitHubの公式ブログは2024年だけで3,900万件超のシークレット漏洩を検出したと発表しています[1][2]。2022年に漏洩が確認されたシークレットのうち、64%以上が2026年1月時点でいまだ有効という衝撃的なデータもあります[3]。

しかしこの問題には、5分以内に導入できる根本的な解決策があります。git commit の瞬間に自動でシークレットを検知してコミットを止める「自動改札口」——gitleaks + pre-commitフックの設定です。

本記事では、やらかしのリアルな被害シナリオから始め、gitleaksの仕組みを解説し、今日から使える設定をコピペで提供します。

記事本文

1. 「あとで消せばいいか」が会社を破滅させる理由

1-1. Gitの歴史は「消えない」

多くの開発者が「コミットした後に git rm で削除した」「ファイルを上書きした」と思って安心しています。しかしGitの仕組みを理解すると、この安心がいかに危険かがわかります。

# ❌ 「消した」つもりのよくある間違い
git add config.py          # APIキーが入ったファイルをコミット
git commit -m "add config"
git rm config.py           # 慌てて削除
git commit -m "remove config"
git push origin main

# この時点でGitの歴史には：
# コミット A: config.py が存在する（APIキー入り）← 攻撃者はここを見る
# コミット B: config.py が削除された
# ↑ git log --all や git show <commit_hash>:config.py で誰でも見れる

"Removing a secret from your current code does not remove it from Git history. Every commit is permanent. Anyone who clones your repo — or who cloned it before you noticed — has access to every secret you ever committed."
— VibeDoctor, "Pre-Commit Hooks: Catching Secrets Before They Ship to Git" [4]
https://vibedoctor.io/blog/pre-commit-hooks-secrets-detection

つまり git push した瞬間、その後何をしようともシークレットはGitHubのサーバーに永久に刻まれます。パブリックリポジトリであれば、GitHubのミラーリングボットが数秒以内にコミットをキャプチャします。

1-2. 「秒単位」で悪用される現実

漏洩したシークレットは予想以上に速く悪用されます。

"Exposed secrets are easy to find. Secrets are supposed to prevent unauthorized access, but in the wrong hands, they can be — and typically are — exploited in seconds."
— GitHub Blog, "GitHub found 39M secret leaks in 2024" [2]
https://github.blog/security/application-security/next-evolution-github-advanced-security/

GitGuardianは通知メールを送っても通知から1時間以内に失効処理されたシークレットはわずか2.6%であることを報告しています[5]。残り97.4%のシークレットは、通知が届いてからも有効なまま放置されます。

攻撃者はGitHubのすべてのパブリックコミットをリアルタイムでスキャンしており、有効なAWSキーを発見したら即座にEC2インスタンスを起動したり、S3バケットのデータを窃取したりします。

1-3. 規模の「大惨事シナリオ」

GitHub公式ドキュメントは漏洩したシークレットが引き起こす具体的な被害を列挙しています[6]。

"Unexpected cloud bills: Leaked API keys let attackers use your cloud resources. They can run compute instances, store data, or mine cryptocurrency on your account, generating large bills. Incident response: Investigating breaches, rotating credentials, and auditing systems takes significant engineering time and resources. Legal costs: Data breaches can result in fines, legal fees, and notification expenses."
— GitHub Docs, "Secret leakage risks" [6]
https://docs.github.com/en/code-security/concepts/secret-security/secret-leakage-risks

クラウドマイニングに悪用されたAWSキーの実例では、一晩で数百万円規模の請求が発生したケースも報告されています。IBM Cost of Data Breach Report 2024は、認証情報の侵害を伴う侵害の平均コストを1件あたり488万ドルと報告しており、前年比10%増です[7]。

1-4. AI時代に加速するシークレット漏洩

AIコーディングツールがシークレット漏洩を加速させているという新しいデータもあります。

"GitGuardian's 2026 report found that AI-assisted commits leak secrets at a 3.2% rate, roughly 2x the baseline. AI coding tools can generate working code that includes hardcoded credentials."
— Snyk, "Why 28 million credentials leaked on GitHub in 2025" [8]
https://snyk.io/articles/state-of-secrets/

さらに、2025年はAIサービスのシークレット漏洩が前年比81%増。DeepSeek APIキーが11万3,000件漏洩した事例が特に際立っています[3]。Vibe Coding（AIが生成したコードをほぼそのまま使う開発スタイル）の普及で、開発者がコードをレビューせずにコミットするケースが増加しています。

2. 「どこに混入するか」——やらかしパターン図鑑

実際のインシデントから抽出した、シークレットが混入しやすい6つのパターンを示します。

シークレット混入パターン図鑑

パターン1: .env ファイルのうっかりコミット
  ファイル: .env
  内容: DATABASE_URL=postgres://user:SuperSecret@prod-db:5432/mydb
        AWS_SECRET_KEY=wJalrXUtnFEMI/K7MDENG+bPxRfiCYEXAMPLEKEY
  原因: .gitignore に .env を書き忘れた

パターン2: 設定ファイルへの直書き
  ファイル: config.py / application.yml
  内容: STRIPE_SECRET_KEY = "sk_live_xxxxxxxxxxxxxxxxxxxxx"
  原因: 「ローカルで動かすため」に一時的に書いたつもりが…

パターン3: デバッグコードのコミット残し
  ファイル: api_client.py
  内容: client = OpenAI(api_key="sk-proj-abc123...")  # TODO: 環境変数にする
  原因: あとで直すつもりが、コミットしてしまった

パターン4: インフラコードへのシークレット埋め込み
  ファイル: terraform/main.tf / docker-compose.yml
  内容: password = "ProductionDBPass2026!"
  原因: IaCは「コード」ではなく「設定」という意識から来るミス

パターン5: コメントへの残骸
  ファイル: utils.py
  内容: # API_KEY = "old-key-abc123"  ← ローテーション前の古いキーを削除した気になっている
  原因: コメントアウトで「削除」したつもり

パターン6: テストコードへの決め打ち
  ファイル: tests/test_api.py
  内容: def test_login():
            token = "ghp_actualRealTokenXXX"  # テスト用
  原因: 「テストコードだから」という油断

GitGuardianのデータでは、最も多く漏洩する種別はMongoDB認証情報（18.8%）、次いでAWS IAMキー、GitHubトークンの順です[5]。プライベートリポジトリでもAWS IAMキーが8%のリポジトリに存在することが判明しており、「プライベートだから安全」という認識は危険です[5]。

3. gitleaks——160種以上のシークレットを検知する「自動改札口」

3-1. gitleaksとは

gitleaksは2018年にZachary Riceによって開発されたオープンソースのシークレット検知ツールです。GoでビルドされたMITライセンスのシングルバイナリで、160種類以上のシークレットパターンを正規表現 + エントロピー解析で検出します[9]。

"Gitleaks is a tool for detecting secrets like passwords, API keys, and tokens in git repos, files, and whatever else you wanna throw at it via stdin."
— GitHub, gitleaks/gitleaks [10]
https://github.com/gitleaks/gitleaks

3-2. 検知できるシークレットの例

gitleaksのデフォルトルールが検知できる代表的なシークレット種別です。

カテゴリ	具体例
クラウド	AWS Access Key / Secret、GCP Service Account、Azure Client Secret
ソース管理	GitHub Token（PAT/GitHub App）、GitLab PAT
決済・SaaS	Stripe Secret Key、Slack Token、Twilio Auth Token
AI/MLサービス	OpenAI API Key、Anthropic API Key、HuggingFace Token
データベース	PostgreSQL/MySQL connection strings
認証	RSA/EC/DSA 秘密鍵、JWT Secret

3-3. 動作の仕組み

gitleaks の検知フロー

git commit を実行
    │
    ▼
pre-commit フックが起動
    │
    ▼
gitleaks protect --staged を実行
    │
    ├── staged ファイルの内容を取得
    │
    ├── 160+ の正規表現パターンとマッチング
    │
    ├── エントロピー（ランダム性の高さ）で誤検知を抑制
    │     例: "password=test" → 低エントロピー → スキップ
    │         "password=sk-1a2b3c4d5e..." → 高エントロピー → 検出
    │
    ├── シークレット検出なし → コミット許可 ✅
    │
    └── シークレット検出あり → コミットをブロック ❌
            │
            └── 発見箇所・ルールID・ファイル・行番号を出力

4. 5分でできるgitleaks導入手順

Step 1: gitleaksのインストール

# macOS（Homebrew）
brew install gitleaks

# Linux（バイナリ直接ダウンロード）
curl -sSfL https://github.com/gitleaks/gitleaks/releases/latest/download/gitleaks_linux_x64.tar.gz | tar -xz
sudo mv gitleaks /usr/local/bin/

# Windows（Chocolatey）
choco install gitleaks

# バージョン確認
gitleaks version
# → v8.24.2 (最新は https://github.com/gitleaks/gitleaks/releases で確認)

Step 2: まず既存リポジトリをスキャンする（重要！）

フックを設定する前に、既存の歴史にシークレットが含まれていないか確認します。ここで問題が発見された場合は先に対処が必要です。

# リポジトリ全履歴をスキャン
gitleaks detect --source . --verbose

# ステージング済みファイルのみスキャン（コミット前の手動確認）
gitleaks protect --staged --verbose

# JSON形式でレポート出力（CI/CDへの組み込み用）
gitleaks detect --source . --report-format json --report-path gitleaks-report.json

# 出力例（シークレット検出時）：
# ○ │╲
# │ ○
# ○ ░ ░
#              gitleaks
#
# Finding:     STRIPE_SECRET_KEY="sk_live_xxxxx..."
# Secret:      sk_live_xxxxx...
# RuleID:      stripe-access-token
# Entropy:     4.762896
# File:        config.py
# Line:        12
# Commit:      a1b2c3d4e5f6...
# Author:      yamada.taro
# Date:        2026-07-16T09:30:00Z
# Fingerprint: a1b2c3:config.py:stripe-access-token:12

Step 3-A: pre-commitフレームワーク経由の設定（推奨）

Python製のpre-commitフレームワークを使う方法です。チーム全員への展開が簡単で、バージョン管理もできます。

# pre-commit のインストール
pip install pre-commit
# または
brew install pre-commit

リポジトリルートに .pre-commit-config.yaml を作成します。

# .pre-commit-config.yaml
repos:
  # シークレット検知（gitleaks）
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.2  # 最新バージョンに適宜更新
    hooks:
      - id: gitleaks

  # 基本的なコード品質チェック（おすすめセット）
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v5.0.0
    hooks:
      - id: trailing-whitespace       # 末尾の空白を削除
      - id: end-of-file-fixer         # ファイル末尾の改行を統一
      - id: check-yaml                # YAML 構文チェック
      - id: check-json                # JSON 構文チェック
      - id: check-added-large-files   # 大きなファイルのコミットを防止
        args: ['--maxkb=1000']
      - id: detect-private-key        # PEM秘密鍵を検知

# フックをインストール（リポジトリに対して一度だけ実行）
pre-commit install

# インストール確認
ls -la .git/hooks/pre-commit
# → -rwxr-xr-x  1 user  staff  ...  .git/hooks/pre-commit

# 全ファイルに対して手動実行（初回確認）
pre-commit run --all-files

これで git commit の度に自動的にgitleaksが走るようになります。

Step 3-B: シェルスクリプトによる直接設定（フレームワーク不要）

Pythonを入れたくない、シンプルにしたい場合はシェルスクリプトで直接設定します。

# .git/hooks/pre-commit ファイルを作成
cat > .git/hooks/pre-commit << 'HOOK'
#!/usr/bin/env bash
set -euo pipefail

# gitleaks がインストールされているか確認
if ! command -v gitleaks >/dev/null 2>&1; then
  echo "⚠️  gitleaks が見つかりません。インストールしてください："
  echo "   macOS: brew install gitleaks"
  echo "   Linux: https://github.com/gitleaks/gitleaks/releases"
  exit 1
fi

# カスタム設定ファイルがあれば使用
CONFIG_ARGS=""
if [ -f ".gitleaks.toml" ]; then
  CONFIG_ARGS="--config .gitleaks.toml"
fi

echo "🔍 シークレットをスキャン中..."

if ! gitleaks protect --staged --redact $CONFIG_ARGS; then
  echo ""
  echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
  echo "❌ シークレットが検出されました！コミットをブロックします。"
  echo ""
  echo "【対処方法】"
  echo "1. 上記のファイルからシークレットを削除してください"
  echo "2. 環境変数または .env ファイルに移してください"
  echo "3. .env は .gitignore に追加してください"
  echo ""
  echo "【どうしても今すぐコミットが必要な場合（緊急時のみ）】"
  echo "  git commit --no-verify （フックをスキップ ※使用は最小限に）"
  echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
  exit 1
fi

echo "✅ シークレット検出なし。コミットを続行します。"
HOOK

# 実行権限を付与
chmod +x .git/hooks/pre-commit

Step 3-C: JavaScript/TypeScriptプロジェクト（Husky）

npmプロジェクトでは、Huskyを使うことでチームメンバーが npm install するだけでフックが有効になります。

# Huskyのセットアップ
npm install --save-dev husky
npx husky init

# pre-commitフックにgitleaksを追加
cat > .husky/pre-commit << 'HOOK'
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

if ! command -v gitleaks >/dev/null 2>&1; then
  echo "⚠️  gitleaks が未インストールです: brew install gitleaks"
  exit 1
fi

echo "🔍 シークレットをスキャン中..."
gitleaks protect --staged --redact
if [ $? -ne 0 ]; then
  echo "❌ シークレットが検出されました。コミットをブロックします。"
  exit 1
fi
echo "✅ シークレット検出なし。"
HOOK

chmod +x .husky/pre-commit

package.json に以下を追加して、npm install 時に自動セットアップします。

{
  "scripts": {
    "prepare": "husky"
  },
  "devDependencies": {
    "husky": "^9.0.0"
  }
}

5. .gitleaks.toml——プロジェクト固有のカスタム設定

gitleaksのデフォルトルールを拡張・調整するための設定ファイルです。

# .gitleaks.toml
title = "MyProject Gitleaks Config"

# デフォルトルールを継承
[extend]
useDefault = true

# ─────────────────────────────────────────────
# カスタムルール：自社固有のシークレットパターン
# ─────────────────────────────────────────────

# 自社内部APIトークン
[[rules]]
id = "internal-api-token"
description = "MyCompany Internal API Token"
regex = '''myco_[a-zA-Z0-9]{40}'''
tags = ["internal", "api"]

# データベース接続文字列（MySQL/PostgreSQL/MongoDB）
[[rules]]
id = "database-connection-string"
description = "Database connection string with credentials"
regex = '''(?i)(?:postgres|postgresql|mysql|mongodb|redis)(?:ql)?:\/\/[^:]+:[^@]+@[^\s'"]+'''
tags = ["database"]

# AWS ARN（一部のケースで機密情報として扱いたい場合）
[[rules]]
id = "aws-arn-with-account"
description = "AWS ARN containing account ID"
regex = '''arn:aws:[a-z0-9\-]+:[a-z0-9\-]*:(\d{12}):'''
tags = ["aws"]

# ─────────────────────────────────────────────
# 許可リスト（False Positive を除外）
# ─────────────────────────────────────────────

[allowlist]
  description = "プロジェクト固有の除外設定"

  # 除外するファイルパス（正規表現）
  paths = [
    # テストフィクスチャのサンプルデータ
    '''tests/fixtures/.*''',
    # ドキュメントのサンプルコード
    '''docs/examples/.*''',
    # gitleaks 自体の設定ファイル
    '''\.gitleaks\.toml$''',
    # 依存ライブラリのロックファイル
    '''package-lock\.json$''',
    '''yarn\.lock$''',
  ]

  # 除外するコミット（特定コミットハッシュを除外）
  commits = [
    # "abc1234"  ← 過去のやらかしコミット（すでに対処済み）
  ]

# .gitleaksignore
# 誤検知（False Positive）を個別に除外するファイル
# gitleaksが出力する Fingerprint の値をそのまま貼り付ける

# 例：テスト用の無効なAPIキー（実際のキーではない）
3a5b7c9d1e2f4a6b8c0d2e4f6a8b0c2d4e6f8a0b

# Supabase の匿名キー（仕様上パブリックに公開して良いキー）
9f8e7d6c5b4a3f2e1d0c9b8a7f6e5d4c3b2a1f0e

6. 動作確認——実際にブロックされる様子を見る

設定が正しくできているか、テストしてみましょう。

# テスト用のダミーシークレットを含むファイルを作成
cat > /tmp/test_secret.py << 'EOF'
# これはテストファイルです（コミット後に削除します）
import os

# ❌ 悪い例（こういうコードが検出対象）
AWS_ACCESS_KEY_ID = "AKIAIOSFODNN7EXAMPLE"
AWS_SECRET_ACCESS_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
STRIPE_KEY = "sk_live_XXXXXXXXXXXXXXXXXXXXXXXX"
OPENAI_API_KEY = "sk-proj-XXXXXXXXXXXXXXXXXXXXXXXX"

# ✅ 正しい例（こう書くべき）
aws_key = os.environ.get("AWS_ACCESS_KEY_ID")
stripe_key = os.environ.get("STRIPE_SECRET_KEY")
EOF

cp /tmp/test_secret.py ./test_secret.py
git add test_secret.py
git commit -m "test: シークレット検出テスト"

期待される出力（コミットがブロックされる）：

🔍 シークレットをスキャン中...

    ○
   │╲
   │ ○
   ○ ░ ░
          gitleaks

Finding:     AWS_ACCESS_KEY_ID = "AKIAIOSFODNN7EXAMPLE"
Secret:      AKIAIOSFODNN7EXAMPLE
RuleID:      aws-access-key
Entropy:     3.684184
File:        test_secret.py
Line:        5
Fingerprint: :test_secret.py:aws-access-key:5

Finding:     AWS_SECRET_ACCESS_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
Secret:      wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
RuleID:      aws-secret-key
Entropy:     4.712384
File:        test_secret.py
Line:        6
...

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
❌ シークレットが検出されました！コミットをブロックします。
...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

✅ コミットがブロックされ、yarakashi防止ができています。テストファイルを削除して完了です。

git rm test_secret.py
# ステージングをリセット
git reset HEAD test_secret.py 2>/dev/null || true
rm -f test_secret.py

7. CI/CDへの組み込み——「--no-verify」への最後の防衛ライン

pre-commitフックには一つの弱点があります。git commit --no-verify でスキップできるという点です。

"Yes. Running git commit --no-verify skips all hooks. This is why you should also run Gitleaks in your CI/CD pipeline as a second layer. Pre-commit hooks catch 95% of cases during normal development. CI catches the rest."
— VibeDoctor [4]
https://vibedoctor.io/blog/pre-commit-hooks-secrets-detection

チームの誰かが緊急時に --no-verify を使ったとき、あるいは新しいメンバーがフックをセットアップしていないとき——この「最後の防衛ライン」がCI/CDでのgitleaksスキャンです。

GitHub Actionsへの設定

# .github/workflows/secrets-scan.yml
name: Secret Scanning

on:
  push:
    branches: [ "**" ]
  pull_request:
    branches: [ main, develop ]

jobs:
  gitleaks:
    name: 🔍 Gitleaks Secret Scan
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0    # ← 全履歴を取得（歴史のスキャンに必要）

      - name: Run Gitleaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}  # 商用利用時は必要

      # JSON レポートをアーティファクトとして保存（任意）
      - name: Upload Gitleaks Report
        if: failure()
        uses: actions/upload-artifact@v4
        with:
          name: gitleaks-report
          path: gitleaks-report.json
          retention-days: 7

GitLab CI/CDへの設定

# .gitlab-ci.yml に追加
secret-scanning:
  stage: test
  image: zricethezav/gitleaks:latest
  script:
    - gitleaks detect --source . --verbose --report-format json --report-path gitleaks-report.json
  artifacts:
    when: on_failure
    paths:
      - gitleaks-report.json
    expire_in: 1 week
  allow_failure: false  # シークレット検出時にパイプラインを失敗させる

8. シークレットが漏洩してしまったら——緊急対応手順

もし万が一、シークレットがコミット・プッシュされてしまった場合の対応手順です。Git履歴からの削除より先に、シークレットの無効化を必ず最初に行います。

# ステップ1（最重要・最優先）：シークレットを即座に無効化・ローテーション
# ─────────────────────────────────────────────────────
# AWS: IAMコンソール → 対象のアクセスキー → 無効化 → 新しいキーを生成
# GitHub: Settings → Developer Settings → Personal Access Tokens → 削除
# Stripe: Dashboard → API Keys → 対象キーを削除・新規作成
# OpenAI: Platform → API Keys → 削除・新規作成

# ステップ2：該当コミットの確認
git log --oneline | head -20
git show <commit_hash>:ファイル名  # シークレットが実際にあるか確認

# ステップ3：Git履歴からの削除（BFG Repo-Cleanerを使用）
# https://rtyley.github.io/bfg-repo-cleaner/

# BFGのダウンロード
curl -L https://repo1.maven.org/maven2/com/madgag/bfg/1.14.0/bfg-1.14.0.jar -o bfg.jar

# リポジトリのミラークローン（重要：通常のcloneではなくmirrorを使う）
git clone --mirror https://github.com/yourorg/yourrepo.git

# 特定の文字列を削除（実際のシークレット値を指定）
echo "ACTUAL_SECRET_VALUE_HERE" > secrets.txt
java -jar bfg.jar --replace-text secrets.txt yourrepo.git

# 履歴の整理とforce push
cd yourrepo.git
git reflog expire --expire=now --all
git gc --prune=now --aggressive
git push --force

# ステップ4：全関係者・システムへの通知
# - リポジトリにアクセスできた人全員に通知
# - シークレットを使用しているすべてのシステムで設定を更新
# - セキュリティインシデントレポートの作成

# ステップ5：影響範囲の調査
# クラウドサービスのアクセスログ確認
# 漏洩してから現在までの間に不審なアクセスがなかったか確認

"Immediately revoke or rotate the exposed credential, remove it from the repository, and update configurations to prevent future leaks."
— gitleaks.org [11]
https://gitleaks.org/installing-and-configuring-gitleaks-complete-setup-guide-for-secure-secret-scanning/

9. シークレットを「そもそもコードに書かない」設計

gitleaksは「書いてしまったシークレットを検知する」ツールですが、根本的にはシークレットをコードに書かない設計が重要です。

# ✅ 環境変数パターン（基本）
export AWS_ACCESS_KEY_ID="実際のキー"
export AWS_SECRET_ACCESS_KEY="実際のシークレット"

# Python でのアクセス
import os
aws_key = os.environ.get("AWS_ACCESS_KEY_ID")
if not aws_key:
    raise ValueError("AWS_ACCESS_KEY_ID が設定されていません")

# ✅ .env ファイルパターン（ローカル開発）
# .env ファイルを作成（.gitignore に追加済みであること！）
cat > .env << 'EOF'
# ローカル開発用の設定（絶対にコミットしないこと）
DATABASE_URL=postgres://user:pass@localhost:5432/mydb
STRIPE_SECRET_KEY=sk_test_xxxx
OPENAI_API_KEY=sk-proj-xxxx
EOF

# .gitignore に追加
echo ".env" >> .gitignore
echo ".env.*" >> .gitignore
echo "!.env.example" >> .gitignore  # サンプルファイルは共有

# .env.example（コミットして良いサンプルファイル）
cat > .env.example << 'EOF'
# このファイルを .env にコピーして実際の値を設定してください
DATABASE_URL=postgres://user:password@localhost:5432/dbname
STRIPE_SECRET_KEY=sk_test_your_key_here
OPENAI_API_KEY=sk-proj-your_key_here
EOF

# ✅ クラウドの秘密管理サービスの活用

# AWS Secrets Manager（Python SDK例）
import boto3
import json

def get_secret(secret_name: str, region: str = "ap-northeast-1") -> dict:
    client = boto3.client("secretsmanager", region_name=region)
    response = client.get_secret_value(SecretId=secret_name)
    return json.loads(response["SecretString"])

# 使用例
db_credentials = get_secret("prod/myapp/database")
db_url = f"postgres://{db_credentials['username']}:{db_credentials['password']}@{db_credentials['host']}"

# ✅ GitHub Actionsでのシークレット利用
# .github/workflows/deploy.yml

jobs:
  deploy:
    steps:
      - name: Deploy to AWS
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}      # Secrets に登録
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        run: |
          aws s3 sync ./dist s3://my-bucket/

10. チームへの導入——「フックが入ってないメンバー」問題を解決する

pre-commitフックはローカルに設定するもので、デフォルトではGitリポジトリにコミットされません。新しいメンバーが参加した際に「フックをセットアップしていない」という問題が生じます。

以下のアプローチでチーム全体への展開を確実にします。

# チーム展開スクリプト（scripts/setup-dev.sh）
#!/usr/bin/env bash
set -euo pipefail

echo "🚀 開発環境セットアップ"

# gitleaks のインストール確認
if ! command -v gitleaks >/dev/null 2>&1; then
  echo "📦 gitleaks をインストール中..."
  if [[ "$OSTYPE" == "darwin"* ]]; then
    brew install gitleaks
  else
    echo "❗ Linux: 手動でインストールしてください"
    echo "   https://github.com/gitleaks/gitleaks/releases"
    exit 1
  fi
fi

# pre-commit のインストール確認
if ! command -v pre-commit >/dev/null 2>&1; then
  echo "📦 pre-commit をインストール中..."
  pip install pre-commit
fi

# フックのインストール
echo "🔧 pre-commit フックをインストール中..."
pre-commit install

echo "✅ セットアップ完了！"
echo "   git commit のたびにシークレットスキャンが自動実行されます"

# README.md に追加する開発環境セットアップ手順

## 🔧 開発環境のセットアップ

このリポジトリでは、シークレット漏洩を防ぐために pre-commit フックを使用しています。
**初回のみ**、以下のコマンドを実行してください：

```bash
bash scripts/setup-dev.sh

または手動で：

# gitleaks のインストール（macOS）
brew install gitleaks

# pre-commit のインストール
pip install pre-commit

# フックの有効化
pre-commit install

⚠️ このセットアップをしないと、シークレットを含むコミットがCI/CDで
ブロックされ、マージできません。


---

### 11. まとめ——「1秒の手間」が会社を救う

2025年にパブリックGitHubに漏洩したシークレットは**2,865万件**（前年比34%増）[3]。その70%近くが数年後でもいまだ有効なまま放置されています。IBM調査によれば認証情報侵害の平均コストは**488万ドル**[7]。

これに対してgitleaks + pre-commitフックの設定にかかる時間は**5分**です。1秒の「あとで直せばいい」という判断が数億円の損失につながる可能性がある一方、5分の設定でそのリスクを根本から断ち切れます。

**今すぐできること3ステップ：**

```bash
# 1. gitleaksをインストール
brew install gitleaks

# 2. .pre-commit-config.yaml を作成（↑ Step 3-A のコピペ）

# 3. フックを有効化
pip install pre-commit && pre-commit install

「自動改札口を設けなかった電車は、切符を持っていない客を全員通してしまう」——gitleaksはgit commitの改札口です。今日から設定しておきましょう。

参考文献

[1] GitGuardian. "State of Secrets Sprawl 2026." March 18, 2026.
https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026/

[2] GitHub Blog. "GitHub found 39M secret leaks in 2024. Here's what we're doing to help." April 1, 2025.
https://github.blog/security/application-security/next-evolution-github-advanced-security/

[3] TechRadar. "Over 29 million secrets were leaked on GitHub in 2025, and AI really isn't helping." March 18, 2026.
https://www.techradar.com/pro/security/over-29-million-secrets-were-leaked-on-github-in-2025-and-ai-really-isnt-helping

[4] VibeDoctor. "Pre-Commit Hooks: Catching Secrets Before They Ship to Git." April 6, 2026.
https://vibedoctor.io/blog/pre-commit-hooks-secrets-detection

[5] GitGuardian. "State of Secrets Sprawl 2025." 2025.
https://www.gitguardian.com/state-of-secrets-sprawl-report-2025

[6] GitHub Docs. "Secret leakage risks." 2026.
https://docs.github.com/en/code-security/concepts/secret-security/secret-leakage-risks

[7] GitHub. "Understanding your organization's exposure to secret leaks." 2025.
https://github.com/resources/insights/understanding-secret-leak-exposure

[8] Snyk. "Why 28 million credentials leaked on GitHub in 2025, and what to do about it." March 30, 2026.
https://snyk.io/articles/state-of-secrets/

[9] DevSecOps School. "Gitleaks: A Comprehensive DevSecOps Tutorial." May 23, 2025.
https://devsecopsschool.com/blog/gitleaks-a-comprehensive-devsecops-tutorial/

[10] GitHub. "gitleaks/gitleaks — Find secrets with Gitleaks."
https://github.com/gitleaks/gitleaks

[11] gitleaks.org. "Installing and Configuring Gitleaks: Complete Setup Guide for Secure Secret Scanning." February 21, 2026.
https://gitleaks.org/installing-and-configuring-gitleaks-complete-setup-guide-for-secure-secret-scanning/

[12] tutorialQ. "Git Security — Pre-Commit Hooks, Secret Detection, and Credential Safety." April 2, 2026.
https://tutorialq.com/dev/git/git-security-secrets-detection

[13] d4b.dev. "Add a Local Gitleaks Pre-Commit Hook (No Frameworks)." February 1, 2026.
https://www.d4b.dev/blog/2026-02-01-gitleaks-pre-commit-hook/

[14] HackerStack. "Pre-Commit Essentials — A Quick Guide to Setup, Hooks, and Usage." May 27, 2026.
https://www.hackerstack.org/pre-commit-essentials-a-quick-guide-to-setup-hooks-and-usage/

[15] orthogonal.info. "I Caught 14 Leaked Secrets in My Git History. Here's the Pre-Commit Setup That Stops It." June 11, 2026.
https://orthogonal.info/i-caught-14-leaked-secrets-in-my-git-history-heres-the-pre-commit-setup-that-stops-it/

[16] Infosecurity Magazine. "Nearly 13 Million Secrets Spilled Via Public GitHub Repositories." May 11, 2026.
https://www.infosecurity-magazine.com/news/13-million-secrets-public-github/

[17] GitGuardian Blog. "The State of Secrets Sprawl 2025." March 14, 2025.
https://blog.gitguardian.com/the-state-of-secrets-sprawl-2025/

[18] Angelus-H's Athenaeum. "Pre-Commit Hooks for Secret Detection." May 25, 2026.
https://angelus-h.github.io/practices/security/Pre_Commit_Hooks_Secret_Detection_Guide/

[19] OpenAI. "How your data is used to improve model performance."
https://openai.com/policies/how-your-data-is-used-to-improve-model-performance/

[20] GitHub. "gitleaks/gitleaks-action — Gitleaks GitHub Action."
https://github.com/gitleaks/gitleaks-action