CL004.md

CL004 — Hardcoded secret

• Severity: Error
• Confidence: High, Medium or Low depending on the detection path

What it finds

Secrets committed to configuration files: connection strings with inline passwords, well-known token formats, values under secret-suggesting key names, and long high-entropy values that look like generated key material.

Why it matters

Configuration files are committed, copied into build artifacts and attached to bug reports. A secret that enters a repository must be considered leaked — rotating it is expensive; not committing it is cheap.

Detection paths and confidence

Signals map to confidence honestly (ADR-0002); the strongest matching signal wins:

Signal	Confidence
AWS access key ID format (AKIA…)	High
GitHub token format (ghp_…, gho_…, …)	High
JSON Web Token structure (eyJ….…)	High
Private key block (-----BEGIN … PRIVATE KEY-----)	High
Connection string with inline Password=/Pwd=	High
Secret-suggesting key name and high-entropy value	High
Secret-suggesting key name (e.g. …Secret, …ApiKey, …Password)	Medium
High Shannon entropy alone (≥ 4.0 bits/char, ≥ 24 chars, token charset)	Low

Not flagged: empty values, obvious placeholders (${VAR}, {{vault:…}}, <your-key-here>, %VAR%, changeme, …), booleans and numbers under secret-ish names (TokenLifetimeMinutes), and GUIDs (common as identifiers, rarely secrets on their own).

Finding messages show only the first four characters of the value — reports must not leak the secret they warn about.

Example

{
  "ConnectionStrings": {
    "Default": "Server=db;User Id=sa;Password=SuperSecret123!;" // CL004, High
  },
  "Auth": {
    "ClientSecret": "hunter2-prod" // CL004, Medium
  }
}

How to fix

• Local development: dotnet user-secrets.
• Hosted environments: environment variables or a secret store (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault) wired in as a configuration provider.
• Rotate any secret that was already committed; removing it from the file does not remove it from history.