sanitize-git-repo について
Gitリポジトリ内の認証情報などを体系的に見つけて置き換えるためのスキルです。共有前の整理やセキュリティレビュー準備向けに、出現箇所の記録と置換後の再確認を案内します。履歴の整理は別途検討が必要です。
主な機能
- 01一般的な認証情報パターンの検索
- 02設定、文書、テストデータの確認
- 03秘密情報と出現箇所の記録
- 04該当箇所を一貫して置換
- 05残存確認とテストの実行
活用シーン
- 01共有やオープンソース化前の整理
- 02誤ってコミットした認証情報の削除
- 03コード内の機密情報の監査
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/sanitize-git-repoを入力して読み込まれたか確認します。
詳細
Git リポジトリのサニタイズ
このスキルでは、API キー、トークン、パスワード、その他の認証情報など、Git リポジトリ内の機密情報を体系的に特定し、置き換える方法を説明します。
このスキルを使用するタイミング
- 共有またはオープンソース化する前にリポジトリをサニタイズするとき
- コードベースに誤ってコミットされたシークレットを削除するとき
- ハードコードされた認証情報をプレースホルダーに置き換えるとき
- リポジトリ内に機密情報がないか監査するとき
- セキュリティレビューに向けてコードを準備するとき
推奨されるアプローチ
フェーズ 1：網羅的な調査
変更を加える前に、すべての機密情報の完全な一覧を作成します。これにより、作業中に追加のシークレットが見つかるというよくあるミスを防げます。
よくあるシークレットのパターン：
| 種類 | パターン／プレフィックス | 例 |
|---|---|---|
| AWS アクセスキー | AKIA[A-Z0-9]{16} | AKIAIOSFODNN7EXAMPLE |
| AWS シークレットキー | 40 文字の base64 文字列 | 多くの場合、アクセスキーの近くにあります |
| GitHub トークン | ghp_、gho_、ghs_、ghr_ | ghp_xxxxxxxxxxxx |
| Huggingface トークン | hf_ | hf_xxxxxxxxxxxx |
| 一般的な API キー | api[_-]?key、apikey | さまざま |
| ベアラートークン | bearer、token | さまざま |
| 秘密鍵 | -----BEGIN.*PRIVATE KEY----- | RSA／EC キー |
| データベース URL | postgres://、mysql://、mongodb:// | 接続文字列 |
| パスワードフィールド | password、passwd、pwd | さまざま |
調査の手順：
- 正規表現を使って、既知のプレフィックスやパターンを検索します
- よく使われる変数名（
API_KEY、SECRET、TOKEN、PASSWORD、CREDENTIAL）を検索します - 設定ファイル（
.env、config.*、settings.*、*.json、*.yaml、*.yml）を確認します - テスト用フィクスチャやモックデータファイルを調べます
- 他の形式に埋め込まれたデータ（文字列内の JSON、base64 エンコードされたコンテンツ）を確認します
確認すべき重要な場所：
- 設定ファイルと環境テンプレート
- テスト用フィクスチャとサンプルデータ
- ドキュメントと README ファイル
- CI/CD 設定ファイル
- Docker とデプロイ設定
- JSON／YAML データファイル（シークレットが構造化データに埋め込まれている場合があります）
- リポジトリに保存された Git の差分出力やパッチファイル
フェーズ 2：一覧の文書化
変更を加える前に、次の項目を文書化した一覧を作成します。
- 見つかった一意の機密情報それぞれ
- 各機密情報が見つかったすべてのファイルの場所
- 一致させる正確な文字列（一意に特定するために必要であれば、前後の文脈を含めます）
- 置換に使用するプレースホルダー
プレースホルダーの規則：
<AWS_ACCESS_KEY>、<GITHUB_TOKEN>、<DATABASE_PASSWORD>のように、種類が分かる説明的なプレースホルダーを使用します- すべての置換で一貫性を保ちます
- 指定がある場合は、ユーザーが指定した形式に合わせます
フェーズ 3：体系的な置換
順序立てて置換を実行します。
- 一覧に従い、シークレットを一つずつ処理します
- 各シークレットについて、すべてのファイルにあるすべての出現箇所を置き換えます
- 置換のたびに、すぐに内容を確認します
- 意図しない変更を避けるため、完全一致で検索します
置換時のベストプラクティス：
- 正確に文字列を一致させるため、編集前にファイルを読みます
- 空白と書式を正確に扱います
- JSON などの構造化形式に埋め込まれたシークレットも考慮します（エスケープが必要な場合があります）
- 同じファイル内に同じ値が複数回出現する場合は、一括置換を検討します
フェーズ 4：検証
すべての置換が完了したら、次のことを行います。
- 最初に行ったすべての調査を再実行し、シークレットが残っていないことを確認します
- 機密情報の一部分に一致するものも検索します
- 用意されているテストスイートを実行し、サニタイズが適切に行われたことを確認します
- プレースホルダーの形式が正しいことを確認します
よくある落とし穴
1. 最初の調査が不十分
問題： 置換作業中にシークレットが次々と見つかり、後戻りが必要になります。
防止策： 複数のパターンを使った網羅的な検索と、データファイルや埋め込みコンテンツを含むすべてのファイル形式の確認に、事前に十分な時間をかけます。
2. 想定外の場所にあるシークレット
問題： シークレットが JSON ファイル、埋め込み文字列、テスト用フィクスチャ、エンコードされたデータなどに含まれており、単純な検索では見つかりません。
予防策： すべてのファイル形式を対象に、再帰的に検索します。特に JSON ファイルと YAML ファイルを確認します。シークレットを含んでいる可能性のある Base64 エンコード済みのコンテンツも探します。
3. 文字列の完全一致に関する失敗
問題： 空白の違いや文字エンコードの問題により、編集操作が失敗します。
予防策： 対象ファイルを必ず先に読み、正確な書式を把握します。空白も含め、ファイル内にある文字列をそのままコピーします。
4. 一部の置換漏れ
問題： 同じシークレットが複数箇所にあるにもかかわらず、一部しか置換されていません。
予防策： 置換のたびに、元の値を再検索してすぐに確認します。利用可能な場合は、すべて置換する機能を使います。
5. Git の履歴に関する考慮事項
問題： 現在のファイルから削除した後も、シークレットが Git の履歴に残っています。
予防策： Git の履歴のサニタイズが必要かどうか、ユーザーに確認します。必要な場合は、git filter-branch や BFG Repo-Cleaner などのツールが必要になることがあります（これは別途実施する、より複雑な作業です）。
6. ツールが利用可能であることを前提とする問題
問題： ripgrep などの専用検索ツールは、すべての環境で利用できるとは限りません。
予防策： 代替手段をあらかじめ用意します。標準の grep -r はほとんどの環境で使えます。ツールに依存する前に、利用可能かどうかを確認します。
検証チェックリスト
作業を完了とする前に、次の項目を確認します。
- 既知のシークレットパターンをすべて検索した
- 設定ファイルを確認した
- JSON／YAML データファイルを確認した
- テスト用フィクスチャとモックデータを確認した
- 特定したシークレットを、すべての箇所で置換した
- 検証検索により、元のシークレットが残っていないことを確認した
- プレースホルダーの形式に一貫性がある
- 提供されたテストがすべて正常にパスする
検索コマンドのリファレンス
標準の grep（広く利用可能）：
# Search for AWS access keys
grep -rn "AKIA[A-Z0-9]\{16\}" . --exclude-dir=.git
# Search for common token prefixes
grep -rn "ghp_\|gho_\|ghs_\|hf_" . --exclude-dir=.git
# Search for password-related strings
grep -rn -i "password\|passwd\|pwd" . --exclude-dir=.git
# Search for API key patterns
grep -rn -i "api[_-]\?key\|apikey" . --exclude-dir=.git
Git の内部情報によるノイズを避けるため、検索対象から .git ディレクトリを必ず除外してください。