Secrets Management Best Practices for Engineering Teams
Every application has secrets: database passwords, API keys, signing keys and OAuth client secrets. How you manage them determines whether one leaked laptop, log file or repository becomes a breach.
Principles
- Secrets never live in code. Not in repositories, not in images, not in frontend bundles.
- Least privilege. Each service gets only the secrets it needs.
- Short-lived where possible. Temporary credentials beat permanent keys.
- Rotatable. Every secret can be rotated without downtime.
- Auditable. You know who and what accessed each secret.
Where to store secrets
| Option | Good for | Notes |
|---|---|---|
| Cloud secrets managers | Most teams on a major cloud | Integrated IAM, rotation and audit logs |
| Dedicated vault software | Multi-cloud or advanced needs | Dynamic secrets, more operational effort |
| Platform environment variables | Small apps on PaaS | Encrypted at rest, but limited audit and rotation |
.env files | Local development only | Never commit, never use in production |
Prefer identity over secrets
The best secret is one you do not need:
- Workload identity: cloud roles attached to compute, so code receives temporary credentials automatically.
- OIDC federation from CI/CD to cloud providers, replacing stored deploy keys.
- Managed database authentication via IAM where supported.
Distribute secrets safely
- Inject at runtime from the secrets manager, not at build time.
- Avoid printing secrets in logs, error messages and CI output. Use masking.
- Do not pass secrets as command-line arguments, which appear in process lists.
- Keep secrets out of crash reports and analytics.
Rotation
- Automate rotation for database credentials and cloud keys where your platform supports it.
- Support two active versions during rotation to avoid downtime.
- Rotate immediately when someone with access leaves, or when exposure is suspected.
Developer access
- Developers should not need production secrets for daily work.
- Use separate secrets for each environment.
- Share secrets through the secrets manager or a password manager, never in chat or email.
Detect leaks
- Pre-commit and CI secret scanning.
- Push protection in your code host.
- Monitoring for unusual use of credentials.
- External scanning of your public code and frontend bundles.
A starter setup for a small team
- Move production secrets into your cloud's secrets manager.
- Give each service its own identity with access to its own secrets.
- Switch CI deploys to OIDC federation.
- Add pre-commit secret scanning and enable push protection.
- Document a rotation procedure and test it once.
Finding leaked secrets
SecurityInfinity's secrets and static analysis agents look for exposed keys and tokens in code, public files and JavaScript bundles, so you find leaks before attackers do. Start free.
Frequently asked questions
Are environment variables secure?
They are better than hardcoding, but can leak via logs, debug pages and child processes. For sensitive secrets, read from a secrets manager at runtime.
Should secrets be encrypted in the repository?
Encrypted secret files can work with strong key management, but they add complexity. A secrets manager is usually simpler and safer.
How often should secrets be rotated?
Automate rotation where possible. Otherwise rotate high-value secrets at least annually and immediately after suspected exposure.