Demo Secrets Management Audit

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 item	Why 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 committed	Builds separation of config from code and avoids plaintext secrets
Check secret rotation capability for DB passwords, API keys, certs	Limits 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)

Severity	Finding	Impact
Critical	Default/placeholder JWT secret present and referenced in code	Enables token forgery if secret is unchanged
Critical	`.env` tracked in git with DB credentials in plaintext	Exposed credentials and compliance risk
High	No secret rotation mechanism or revocation support	Long-lived secrets increase exposure window
Medium	Password hashing cost may be too low	Easier to brute-force/accelerate attacks
High	Missing environment validation on startup	Weak 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

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

.env tracked in git

Evidence: Repository index lists .env as a tracked file and .gitignore does not exclude it

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'))"

Recommended code-level remediations (concrete, minimal fixes)

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);
}

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');
  }
}

Use a secret manager instead of commit-stored .env (defense-in-depth)

Migrate secrets to managed stores: AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault.
Pattern: fetch secrets at startup via the provider SDK and inject into config, avoiding storing them in repo or plaintext files.

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

Priority	Actions
Priority 1 — Immediate	Replace 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 week	Implement 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 sprint	Integrate 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:

PCI DSS
GDPR

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

Introduction

Getting Started with Claude Code

Working with Claude Code

Code Review with Claude Code

Security Auditing with Claude Code

Advanced Features

Demo Secrets Management Audit

Scope and quick checklist

Example prompts and audit orchestration

What the audit looks for (high level)

Repository scan highlights (example output)

Key findings (summary)

Evidence and examples

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

Quick remediation commands

Recommended code-level remediations (concrete, minimal fixes)

Prioritized remediation plan

Defense-in-depth recommendations

Compliance and risk

Example consolidated issue report format (for each finding)

Final notes

Watch Video

Introduction

Getting Started with Claude Code

Working with Claude Code

Code Review with Claude Code

Security Auditing with Claude Code

Advanced Features

Documentation Index

​Scope and quick checklist

​Example prompts and audit orchestration

​What the audit looks for (high level)

​Repository scan highlights (example output)

​Key findings (summary)

​Evidence and examples

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

​Quick remediation commands

​Recommended code-level remediations (concrete, minimal fixes)

​Prioritized remediation plan

​Defense-in-depth recommendations

​Compliance and risk

​Example consolidated issue report format (for each finding)

​Final notes

Watch Video

Scope and quick checklist

Example prompts and audit orchestration

What the audit looks for (high level)

Repository scan highlights (example output)

Key findings (summary)

Evidence and examples

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

Quick remediation commands

Recommended code-level remediations (concrete, minimal fixes)

Prioritized remediation plan

Defense-in-depth recommendations

Compliance and risk

Example consolidated issue report format (for each finding)

Final notes