Skip to main content
In this walkthrough we perform a secrets management audit to identify hard-coded credentials, insecure environment handling, and gaps in rotation and encryption practices. The goal: produce reproducible findings with evidence, safe proofs-of-concept, and prioritized remediation steps you can track in issues or tickets.
A presentation slide titled "Secrets Management Audit" with a large dark curved shape on the right containing the word "Demo."

​
Scope and quick checklist

Use this checklist to drive automated scans and manual reviews across the repository:
Checklist itemWhy it matters
Scan codebase for hard-coded secrets (API keys, passwords, JWT secrets, encryption keys)Prevents leaked credentials in VCS and public mirrors
Verify environment variable usage; ensure .env is not committedBuilds separation of config from code and avoids plaintext secrets
Check secret rotation capability for DB passwords, API keys, certsLimits blast radius after exposure
Review encryption and key management (KDFs, salts, key storage)Ensures cryptographic primitives are configured correctly
Ensure startup environment validation (fail fast in production)Prevents deploying weak default secrets to prod
Produce structured findings (severity, evidence, remediation snippet)Enables prioritized remediation and tracking
Use both automated scanners (trufflehog, git-secrets) and targeted repository searches for keywords like JWT_SECRET, API_KEY, password, env, encrypt, salt, bcrypt, and rotate to collect evidence before manual verification.

​
Example prompts and audit orchestration

Typical audit workflow:
  • Run repository-wide keyword search and secret scanners.
  • For each candidate finding, extract file paths and line ranges (evidence).
  • Produce a risk score (0–10), top prioritized fixes, and a checklist diff (Pass/Fail/NA).
  • Provide safe, non-destructive PoC (where necessary) and remediation snippets for developers.
Automated and manual steps complement each other: scanners find likely issues; manual inspection validates context and false positives.

​
What the audit looks for (high level)

  • Hard-coded secrets: API keys, DB credentials, JWT secrets, encryption keys.
  • Environment variables: are secrets only in env vars and is .env tracked in git?
  • Rotation: ability to rotate and revoke tokens, API keys, and DB credentials.
  • Encryption management: use of salts, KDF parameters (bcrypt/Argon2), and secure key storage.
  • Startup checks: validations preventing default dev/test secrets from being used in production.

​
Repository scan highlights (example output)

  • Found tracked .env file in repo.
  • Found default JWT secret placeholder: JWT_SECRET=your_jwt_secret_key_here.
  • Found DB credential placeholders: DB_USER=your_db_user, DB_PASSWORD=your_db_password.
  • No evidence of secret rotation mechanisms or CI secret scanning configured.
  • Password hashing may be using low bcrypt cost parameter.

​
Key findings (summary)

SeverityFindingImpact
CriticalDefault/placeholder JWT secret present and referenced in codeEnables token forgery if secret is unchanged
Critical.env tracked in git with DB credentials in plaintextExposed credentials and compliance risk
HighNo secret rotation mechanism or revocation supportLong-lived secrets increase exposure window
MediumPassword hashing cost may be too lowEasier to brute-force/accelerate attacks
HighMissing environment validation on startupWeak dev/test secrets could be deployed to production
If a .env (or any secrets file) is committed, treat the repository as potentially compromised. Remove secrets from version control, rotate them immediately, and enable CI secret scanning. Follow a documented rotation procedure.

​
Evidence and examples

  1. Placeholder JWT secret present
  • Evidence: .env — contains JWT_SECRET=your_jwt_secret_key_here
  • Evidence: routes/auth.js (or equivalent) references process.env.JWT_SECRET
  1. .env tracked in git
  • Evidence: Repository index lists .env as a tracked file and .gitignore does not exclude it
  1. Database credentials in plain text
  • Evidence: .env contains DB_USER=your_db_user, DB_PASSWORD=your_db_password
  • Evidence: config/database.js reads these env vars directly

​
Proof-of-concept — JWT forgery with known placeholder secret

This safe PoC demonstrates how an attacker can forge a token when the placeholder secret is used. Do not use forged tokens against live systems. 
// PoC: Forge a JWT when secret is the known placeholder
const jwt = require('jsonwebtoken');

const forgedToken = jwt.sign(
  { userId: 1, email: 'admin@example.com' },
  'your_jwt_secret_key_here' // Known default secret from repo placeholder
);

console.log('Forged token:', forgedToken);

​
Quick remediation commands

How to remove .env from git and add it to .gitignore: 
# Remove .env from index, keep local file, and add to .gitignore
git rm --cached .env
echo ".env" >> .gitignore
git add .gitignore
git commit -m "Remove .env from repo and add to .gitignore"
Generate a cryptographically secure JWT secret (example): 
# Generate a 64-byte hex secret with Node
node -e "console.log(require('crypto').randomBytes(64).toString('hex'))"
  1. Improve bcrypt hashing rounds (when hashing new passwords)
// bcrypt: set appropriate cost factor
const bcrypt = require('bcrypt');

const saltRounds = 12; // Minimum recommended today; increase over time
async function hashPassword(password) {
  return await bcrypt.hash(password, saltRounds);
}
  1. Enforce secure secrets at application startup (fail fast in production)
// Add early validation in server startup (e.g., server.js or app.js)
if (process.env.NODE_ENV === 'production') {
  if (!process.env.JWT_SECRET || process.env.JWT_SECRET.length < 64) {
    throw new Error('Production requires a secure JWT_SECRET (64+ chars)');
  }

  if (!process.env.DB_PASSWORD || process.env.DB_PASSWORD === 'your_db_password') {
    throw new Error('Production requires secure database credentials');
  }
}
  1. Use a secret manager instead of commit-stored .env (defense-in-depth)
  1. Add secret rotation and revocation for tokens
  • Implement refresh tokens with server-side revocation (e.g., store refresh token ID and allow revocation).
  • Consider short-lived access tokens and a revocation/blacklist mechanism for immediate invalidation.

​
Prioritized remediation plan

PriorityActions
Priority 1 — ImmediateReplace placeholder JWT_SECRET with a secure, random secret (64+ chars). Remove .env from git, rotate exposed credentials, add startup checks to refuse weak production secrets.
Priority 2 — This weekImplement token revocation/refresh flow or short-lived access tokens. Increase bcrypt rounds for new passwords and plan re-hashing strategy. Add environment-specific validation.
Priority 3 — Next sprintIntegrate a secrets manager and migrate secrets. Add rotation procedures and documentation. Enable automated secret scanning in CI/CD (e.g., GitHub secret scanning, TruffleHog, git-secrets).

​
Defense-in-depth recommendations

  • Prefer managed secrets stores over file-based secrets.
  • Use different credentials per environment (dev/staging/prod) and enforce least privilege.
  • Rotate secrets on a schedule and immediately after any suspected exposure.
  • Implement CI checks to block commits containing secrets and enable repository scanning.

​
Compliance and risk

These findings may impact compliance frameworks such as: Until secrets and rotation controls are addressed, avoid deploying with production data.

​
Example consolidated issue report format (for each finding)

  • Title
  • Severity (Critical/High/Medium/Low)
  • CWE (if applicable)
  • Evidence (file, function, line ranges)
  • Why it matters
  • Exploitability notes / safe PoC
  • Remediation (precise code/config fix)

​
Final notes

The audit highlights substantial risk from default secrets and tracked environment files. Immediate actions: remove secrets from version control, rotate exposed credentials, enable startup validation to prevent weak production configs, and integrate automated secret scanning into developer workflows. Consider adding logging and monitoring to detect and respond to leaked or abused credentials. Links and references

Watch Video