MB-R072 — No secrets in VCS

C12 Third‑party Config Security Critical

API keys, tokens, and credentials must never be committed to source control or copied into sample configs. Secret exposure enables account takeover and data exfiltration. Use environment variables, secret managers, and pre‑commit scanners to prevent accidental leaks across repositories.

Why it Matters

Secrets such as API keys, database credentials, JWT tokens, and private certificates must never be committed into version control (Git, SVN, etc.). Once stored in a public or shared repository, these secrets can be leaked permanently even if later removed, leading to account takeover, database breaches, and privilege escalation.

Ensuring that no secrets exist in version control protects sensitive data and enforces proper use of environment variables or secret management systems (e.g., Vault, AWS Secrets Manager).

Verification Steps

Git history scan

# Use git-secrets or trufflehog to detect exposed keys
git secrets --scan-history
trufflehog git file://. --since-commit=HEAD~50

# Expected: no matches for API keys, tokens, or passwords

Repository file check

# Inspect sensitive files
ls -l app/etc/env.php
ls -l .env

# Ensure these are ignored in .gitignore

Remediation / Fix Guidance

Add sensitive files (e.g., .env, app/etc/env.php) to .gitignore.
Rotate any credentials that were ever committed to Git.
Use environment variables or secret managers instead of hardcoding secrets.
Run automated secret scanning in CI/CD before merging to main branch.
If a leak occurs, treat repository history as compromised and rotate all exposed keys immediately.

Examples

Fail Example

# In Git history
DB_PASSWORD="supersecret123"
STRIPE_API_KEY="sk_live_abc123"

# Secrets committed → FAIL

Pass Example

# .gitignore
.env
app/etc/env.php

# Secrets stored in Vault / ENV vars, not in Git → PASS