Security and Secrets Hygiene

DATABASE_URL=postgresql://user:password@localhost:5432/dbname
API_KEY=your-api-key-here

Common Secret Leak Patterns to Watch For

• Inline connection strings with embedded passwords
• API keys passed as default function parameters
• Private keys or certificates copied into the repo for "convenience"
• Docker Compose files with hardcoded credentials (use environment variable substitution instead)
• CI pipeline configs with secrets in plaintext (use the platform's secrets management)
• Jupyter notebooks or REPL history with authenticated API calls
• Screenshots or logs that contain tokens or session IDs

Configuration Files

• Docker: Never use ENV in a Dockerfile for secrets. Pass them at runtime via docker run -e or Docker Compose environment/env_file with a .env file that is gitignored.
• CI pipelines: Use GitHub Actions secrets (${{ secrets.MY_SECRET }}), never plaintext in workflow files.
• Application config: Use environment variables for anything sensitive. Config files checked into the repo should contain only non-sensitive defaults.

.gitignore Requirements

Every project's .gitignore must include at minimum:

# Secrets and environment
.env
.env.local
.env.*.local
*.pem
*.key
*.p12
*.pfx

# IDE and OS
.idea/
.vscode/
*.swp
.DS_Store
Thumbs.db

# Dependencies (language-specific — add the appropriate patterns)
node_modules/
__pycache__/
*.pyc
vendor/

# Build outputs (language-specific — add the appropriate patterns)
dist/
build/
*.o
*.class

Tailor the language-specific sections to the actual stack. The secrets section is non-negotiable for all projects.

Dependencies

1. Review before adding. Before installing a new dependency, check: is it actively maintained? Does it have known vulnerabilities? Is the scope appropriate, or are you pulling in a large library for one function?
2. Pin versions in production. Use lock files (package-lock.json, poetry.lock, Gemfile.lock, etc.) and commit them. This ensures reproducible builds and prevents supply chain attacks via version drift.
3. Keep dependencies updated. Regularly check for security advisories. Use tools like npm audit, pip-audit, or Dependabot/Renovate for automated vulnerability alerts. Don't ignore security warnings.
4. Minimise dependency surface. Fewer dependencies mean fewer attack vectors. If you can implement something in a few lines rather than adding a package, do so. Every dependency is code you don't control.

What To Do If a Secret Is Leaked

If a secret is committed to any branch, even locally:

1. Rotate the credential immediately. Generate a new key/password/token and update wherever it's used.
2. Remove from git history using git filter-repo or BFG Repo-Cleaner — but treat this as damage limitation, not a fix. The old credential must be considered compromised.
3. Check access logs for the affected service to see if the credential was used by an unauthorised party.
4. Document the incident so the team can learn from it.

The rotation step is the only one that actually secures the system. History rewriting is cosmetic.