detecting-secrets

Secret Patterns

Look for these categories of hardcoded secrets in code:

High-Confidence Patterns

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
 

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

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:

GitHub Secret Scanning Integration

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:

3. Remove from Git History (If Needed)

If the secret was committed to a public repo or a repo that will become public:

Warning: Rewriting git history is destructive and affects all collaborators. Only do this when the secret was exposed in a public or soon-to-be-public repository.

4. Prevent Recurrence

• Add patterns to .gitignore for files that should never be committed (.env, *.pfx, appsettings.Development.json)
• Enable GitHub push protection for the repository
• Use secret scanning custom patterns for organization-specific secret formats

Secure Alternatives

Bitwarden uses Azure Key Vault for secrets management, provisioned by the BRE team:

For local development, use user-secrets or .env files that are .gitignored — never commit them.

Critical Rules

• Assume any committed secret is compromised. Always rotate, even if the repo is private. No exceptions.
• Never suppress secret scanning alerts without rotation. Dismissing an alert doesn't make the exposure go away.
• Validation, not just detection. When a potential secret is found, verify it's real before raising an alarm. Check if it's a test value, placeholder, or encrypted content.
• Check the full commit history. A secret removed in the latest commit may still exist in git history. Use git log -p -S "secret-pattern" to search history.
• Bitwarden uses Azure Key Vault for secrets management. If a new secret needs to be stored, work with BRE to provision vault access for the repository.