secrets-scannerlisted

# Secrets Scanner ## When to use This skill covers three scenarios: an active leak (incident), preventive scanning, and setting up prevention. The action order differs sharply per scenario, so phase 1 explicitly asks which one you're doing. Triggers: - "I think I accidentally committed a key", "this token looks like it's leaking", "check whether there are secrets in the repo". - A PR touches files like `.env`, `.env.*`, `config/*.yaml`, `docker-compose*.yml`, `helm/values*.yaml`, `*.pem`, `*.key`, `credentials.json`, or new files under `secrets/`, `vault/`. - Setup of a new repo: install pre-commit plus CI secret-gate. - Periodic audit of git history on an existing repo. - A finding from `security-review` phase 3 (automated scan) that needs further triage. - Anthropic/OpenAI-style token patterns in logs, screenshots, or shared notebooks. ### When NOT to use (handoff) - Runtime secret injection (Kubernetes Secrets, External Secrets Operator, sidecar pattern) → `k8s-security` and `container-hardening`. - Cloud IAM policy review (who can use which key) → `iac-security`. - Secret-handling patterns in code (where a credential lives in memory, how it's passed) → `secure-coding` phase 4. - Vulnerability triage on dependencies that leak credentials → `cve-triage`. - Post-incident forensics where misuse is proven → `ir-runbook` and `forensics-assist`. For an active leak this skill doesn't stop — rotation is its job. But escalate to `ir-runbook` as soon as there's evidence of mi