Secrets Scan Checklist

Purpose

Give a reviewer a fast pattern-matching pass for credential-shaped strings, so secrets get caught by recognizable shape rather than relying on remembering to look for them. Pair this with the Secrets Are Always A Hard Fail rule — this skill is about finding the secret; that rule governs what happens next.

When to use it

At the start of every review, before looking at anything else — a live credential outranks every other finding in urgency, so it's worth checking first rather than stumbling into it halfway through. Also run it against commit history when a repository's history hasn't been checked before, not just the current diff — a secret removed in a later commit is still exposed in history.

Shapes to recognize

• Cloud/provider API keys — long fixed-prefix strings such as vendor keys that start with a recognizable literal prefix followed by 20+ alphanumeric characters. Don't rely on memorizing every vendor's exact prefix; the pattern (short literal prefix + long high-entropy suffix) is the signal.
• Generic tokens/secrets — high-entropy strings (mixed case, digits, length 32+) assigned to a variable or field named token, secret, key, password, credential, auth, or similar, especially in config, .env-style files, or hardcoded as a default value.
• Connection strings — URLs with a scheme like postgres://, mysql://, mongodb://, redis://, amqp:// that embed a username and password in the authority component (scheme://user:password@host/...).
• Private key blocks — anything containing -----BEGIN ... PRIVATE KEY----- (RSA, EC, OpenSSH, PGP), or .pem/.pfx/.p12 file content pasted inline.
• JWTs and session tokens — three base64url segments separated by dots (eyJ...........), especially if hardcoded rather than generated at runtime.
• Webhook/signing secrets — values assigned to names like webhook_secret, signing_key, hmac_key sitting next to the verification code that's supposed to use them.