/detecting-secrets

name: detecting-secrets
description: This skill should be used when the user asks to "find hardcoded secrets", "audit for credential leaks", "check for API keys in code", "review secret scanning alerts", "rotate a leaked secret", or needs to detect hardcoded credentials, review secret handling patterns, or remediate exposed secrets.

Secret Patterns

Look for these categories of hardcoded secrets in code:

High-Confidence Patterns

| Type | Example Patterns | | ------------------ | ----------------------------------------------------------------------------------------------------------------------- | | API Keys | `AKIA[0-9A-Z]{16}` (AWS), `AIza[0-9A-Za-z_-]{35}` (Google), strings assigned to variables named `*apiKey*`, `*api_key*` | | Connection Strings | `Server=...;Password=...`, `mongodb://user:pass@host`, `postgres://user:pass@host` | | Private Keys | `-----BEGIN RSA PRIVATE KEY-----`, `-----BEGIN OPENSSH PRIVATE KEY-----` | | Tokens | `ghp_[A-Za-z0-9]{36}` (GitHub PAT), `xoxb-` (Slack bot), `sk-` (OpenAI) | | Passwords | Values assigned to variables named `*password*`, `*passwd*`, `*secret*`, `*credential*` | | Certificates | PFX/P12 files with embedded passwords, PEM files with private keys |

Lower-Confidence Patterns (Require Context)

• Base64-encoded strings in configuration (may be encrypted or may be cleartext secrets)
• JWT tokens (may be test tokens or production tokens)
• Hex strings of 32+ characters (may be encryption keys or hashes)
• URLs with embedded credentials (`https://user:pass@host`)

Context-Aware Detection

Distinguish real secrets from false positives. Not every pattern match indicates an actual secret — consider context:

Test Fixtures and Mock Data

// NOT a real secret — test fixture with obvious fake value
var testApiKey = "test-api-key-not-real-12345";
var mockPassword = "P@ssword123"; // Used only in unit tests

// REAL secret — production-looking value in non-test code
var apiKey = "sk-proj-abc123def456ghi789jkl012mno345pqr678stu901vwx";

**Decision criteria:**

• Is it in a test directory (`**/test/**`, `**/tests/**`, `**/*.Test/**`)?
• Does the value contain obvious placeholder text ("test", "fake", "mock", "example", "placeholder")?
• Is the value used in assertions or mock setups?

Example and Placeholder Values

// NOT a real secret — documented example
{
  "apiKey": "YOUR_API_KEY_HERE"
}

// REAL secret — actual value in config
{
  "apiKey": "sk-proj-abc123def456ghi789jkl012mno345pqr678stu901vwx"
}

Encrypted or Hashed Values

• Hashed passwords (bcrypt `$2b$`, argon2 `$argon2id$`) are NOT secrets — they're properly stored
• Encrypted values with proper key management are NOT secrets in the same way
• But the encryption KEY itself, if hardcoded, IS a secret

Common Hiding Spots

Search these locations when auditing for secrets:

| Location | What to Look For | | --------------------------------------------------- | ---------------------------------------------------------- | | `appsettings.json` / `appsettings.Development.json` | Connection strings, API keys, service credentials | | `.env` / `.env.local` | Environment variable definitions with real values | | `web.config` / `app.config` | Machine keys, connection strings | | `docker-compose.yml` / `Dockerfile` | `ENV` directives with credentials, build args with secrets | | CI/CD files (`.github/workflows/*.yml`) | Inline secrets instead of `${{ secrets.* }}` references | | Test seed scripts / migration files | Database passwords, service account credentials | | Comments and TODO notes | "Temporary" credentials left in comments | | Default parameter values | `function connect(password = "admin123")` | | Constants files | Centralized credential definitions |

GitHub Secret Scanning Integration

# List all secret scanning alerts
gh api /repos/{owner}/{repo}/secret-scanning/alerts --jq '.[] | {number, state, secret_type, secret_type_display_name, created_at, push_protection_bypassed}'

# Get details for a specific alert
gh api /repos/{owner}/{repo}/secret-scanning/alerts/{alert_number}

# List alerts that bypassed push protection
gh api "/repos/{owner}/{repo}/secret-scanning/alerts?state=open" --jq '.[] | select(.push_protection_bypassed == true)'

**Push protection** prevents commits containing detected secrets from being pushed. When someone bypasses push protection, the alert is flagged — review these with extra scrutiny.

Remediation Workflow

When a secret is found in code, follow this sequence:

1. Rotate Immediately

Assume any committed secret is compromised. Even if the repo is private, the secret may have been cached, logged, or accessed by CI/CD systems.

• Revoke the existing credential
• Generate a new credential
• Update the credential wherever it's used (services, deployments)

2. Remove from Code

Replace the hardcoded secret with a secure reference:

// WRONG — hardcoded secret
var connectionString = "Server=prod.db;Password=s3cr3t!";

// CORRECT — environment variable
var connectionString = Environment.GetEnvironmentVariable("DB_CONNECTION_STRING");

// CORRECT — Azure Key Vault (Bitwarden's approach)
var connectionString = await