repo-sentinel

Repo Sentinel

公開リポジトリ内のすべてのものは、永続的な攻撃対象領域となります。このスキルでは、公開リポジトリに含めるべきものと含めるべきでないもの、12 の攻撃対象領域にわたる違反の検出方法、境界が侵害された場合の修正方法、継続的な適用方法を定義します。

参照ファイル

このスキルでは、詳細なパターンやテンプレートを記載した同梱の参照ファイルを使用します。必要に応じて読み込んでください。

ファイル	読み込むタイミング
references/attack-surfaces.md	いずれかの領域を監査する場合 — 領域 0～12 の詳細な定義
references/scan-patterns.md	監査（高速パスまたは全件）を実行する場合 — すべての検出コマンドを記載
references/pre-release-checklist.md	リリース前監査（ステージ 4）を実行する場合 — §4.1～§4.8 の準備状況チェックリスト
references/templates.md	適用を設定する場合、.gitignore を生成する場合、または CI ゲートを作成する場合
references/remediation.md	検出結果を修正する場合、または履歴を消去する場合 — すべての修正手順を記載

---

前提条件

• gh CLI がインストールされ、認証済みであること（gh auth status が成功すること）— GitHub 固有の領域チェック（領域 10）に必要です
• アクティブな git リポジトリのコンテキスト — このスキルは git オブジェクトを対象とします。git 以外のディレクトリは対象外です
• trufflehog または gitleaks — エントロピー分析を用いた領域 0（git 履歴）のシークレット検出に任意で利用できますが、強く推奨します。利用できない場合は、references/scan-patterns.md の git log -p grep パターンにフォールバックしてください
• git オブジェクトストア全体への読み取りアクセス — シャロークローン（--depth N）では履歴内のシークレットを見落とすため、シャロークローンが検出された場合はユーザーに警告してください

判定基準

• 公開と非公開の可視性： 公開リポジトリには、より厳しい重大度評価を適用してください。非公開リポジトリで MEDIUM に分類される検出事項（例：コメント内の内部 URL）は、公開リポジトリでは HIGH に引き上げます。評価前にリポジトリの公開範囲を確認してください。
• 技術スタックに応じた領域： 検出された技術スタックに関連する攻撃対象領域に監査範囲を限定してください。静的 HTML リポジトリでは、領域 6（コンテナ）や領域 7（ロックファイル）が実質的な対象にならないため、減点せずに N/A としてください。
• N/A の扱い： N/A と評価された領域は減点対象とならず、全体的なリスク評価も下げません。スキップした理由をユーザーが理解できるよう、N/A の領域を明示してください。
• ツールの利用可否： trufflehog／gitleaks を利用できない場合は、監査ヘッダーにその旨を記載し、領域 0 のカバレッジに関する信頼度が低下することを説明してください。
• 誤検知を避ける： パターンが近似しているだけではなく、実際に情報が露出している証拠がある場合にのみ検出事項として報告してください。プレースホルダー値が設定された api_key という名前の変数は LOW であり、CRITICAL ではありません。

基本原則

公開／非公開の境界は一方通行の弁です。 プッシュ、PR、issue、wiki、リリースアセット、GitHub Pages のいずれかを通じて、データが公開リモートに到達した時点で、永久にインデックス化、キャッシュ、ミラーリング、アーカイブされると考えてください。git push --force、PR の削除、issue の編集、リリースの削除では、消去は保証されません。スクレイピングインフラストラクチャ（GitHub Archive、GH Torrent、Software Heritage、Google Cache、Wayback Machine、および数十もの独自セキュリティスキャナー）は、1 時間未満の遅延で継続的に稼働しています。

すべての成果物に対する判断基準：

質問	はいの場合 →	いいえの場合 →
他にアクセス手段のない攻撃者の助けになる可能性がありますか？	除外	続行
公開情報から推測できない内部トポロジーが明らかになりますか？	除外	続行
何らかの対象へのアクセスを許可する値が含まれていますか？	除外	続行
ライセンス上の義務に違反する、または法的リスクを招く可能性がありますか？	除外	続行
これを削除すると、正規のユーザーにとってリポジトリの有用性が低下しますか？	含める（上記がすべて「いいえ」の場合）	除外

判断に迷う場合は、除外してください。偽陰性（シークレットの漏えい）は壊滅的で、取り返しがつきません。偽陽性（過剰な墨消し）は簡単に修正できます。

---

12 の攻撃対象領域

攻撃対象領域 0～12 の対象となるもの、対象とならないもの、漏えいする理由、検出方法についての詳しい定義は、references/attack-surfaces.md にあります。監査の範囲設定や評価を行う際は、このファイルをお読みください。攻撃対象領域ごとのスキャンコマンドは references/scan-patterns.md に、修正手順は references/remediation.md にあります。

---

重大度の分類

すべての検出事項は重大度で分類されます。この分類に基づいて対応の優先順位を決定します。

重大度	基準	対応
CRITICAL	有効な認証情報、秘密鍵、認証トークンの露出	プッシュを阻止します。直ちに修正します。
HIGH	標的型攻撃を可能にするインフラストラクチャ／トポロジー	プッシュ前に解決します。
MEDIUM	偵察に役立つ情報漏えい	次のコミットで修正します。
LOW	衛生面、スタイル、冗長性に関する問題	都合のよいときに修正します。

Git の履歴に CRITICAL または HIGH がある場合、履歴全体のスクラブと認証情報のローテーションが必要です。

---

運用

ファストパス監査（ステージ済み変更のみ）

単一ファイルまたは小規模な変更セットをプッシュする場合に使用します。リポジトリ全体ではなく、ステージ済みの変更のみをスキャンします。コマンドについては references/scan-patterns.md § Fast-Path をお読みください。

リポジトリ全体の監査（20 以上のチェック）

リポジトリを公開する前、または公開リモートへの初回プッシュ前に実行します。20 項目のチェック手順、クイックリファレンスのスキャンコマンドブロック、監査出力形式については、references/scan-patterns.md § Full Audit をお読みください。

リリース前監査モード（4 段階 DAG）

リポジトリをオープンソースとしてリリースする準備を行う際は、攻撃対象領域ベースの監査の代わりに、この 4 段階のリリース前監査を実行します。各段階では、実行可能な修正方法とともに PASS ／ WARN ／ FAIL が出力されます。第 1～3 段階でハードブロッカーが見つかった場合、パイプラインは停止します。第 4 段階では参考情報が出力されます。

Stage 1: Sensitive Assets        [HARD BLOCKER] → Surfaces 0–4, 8–9
Stage 2: Legal & Compliance      [HARD BLOCKER] → Surface 11
Stage 3: Public Surface Hygiene  [HARD BLOCKER] → Surfaces 4–7, 9–10
Stage 4: Contribution & Release  [SOFT BLOCKER] → Surface 12 + Pre-Release Checklist

各段階を順番に実行します。最後に、結果を構造化された監査テーブルで報告してください。第 4 段階のチェックリスト項目（§4.1～§4.8）は references/pre-release-checklist.md にあります。

継続的な適用のセットアップ

シフトレフトによる予防が、最も効果の高い対策です。すぐに使える pre-commit 設定、GitHub Actions ワークフロー、.gitignore ジェネレーターについては、references/templates.md をお読みください。

履歴汚染の修復

シークレットがすでにコミットされている場合は、references/remediation.md を参照してください。詳細なトリアージの判断ツリー、git filter-repo コマンド、BFG によるフォールバック、スクラブ後の手順、.gitignore の生成ガイダンスが記載されています。

---

制限事項

• 履歴のスクラブを行っても、情報漏えいの解消が保証されるわけではありません。強制プッシュが必要であり、外部ミラー（フォーク、GitHub Archive、Software Heritage）には、ローカルでの操作にかかわらず履歴が無期限に保持されます。
• コンテンツの削除後に、外部ミラー、キャッシュ、検索エンジンのインデックスから確実に削除されたことを検証することはできません。
• 対象は単一リポジトリのみです。適用を調整せずにモノレポを監査する用途には設計されていません。パッケージ間でのシークレット伝播については、パッケージのルートごとに別途分析する必要があります。
• ブランチ保護、シークレットスキャンのアラート、セキュリティアドバイザリなどの GitHub 固有のチェックには、認証済みアクセスが可能な gh CLI が必要です。利用できない場合、Surface 10 のカバレッジは低下します。
• シークレットスキャンの深度は、利用可能なツールによって異なります。trufflehog と gitleaks はエントロピー分析を用いた検証済みの検出を提供します。フォールバックとして使用される手動の正規表現パターンは、誤検知率が高く、難読化された認証情報を見逃します。
• パッケージレジストリへの公開（npm、PyPI、crates）におけるアーティファクトの扱いは、ソースリポジトリへの収録ルールとは異なる、エコシステム固有の慣習に従います。公開済みアーティファクトを監査する際は、各エコシステムの慣習を適用してください。