Our #3 recommendation to increase Application Security, protect application secrets in configuration and code, is the first one to come from the Implementation category of improvements from OWASP SAMM. Practices from this category have the most direct impact on the daily lives of developers as they are related to how the organization builds and deploys software.
To protect application secrets in configuration and code you should:
- Deny developers access to production secrets and credentials.
- Prevent production secrets from being available in non-production environments.
- Store production secrets in a protected location.
Store secrets in a protected location
Production secrets must never be stored in code or configuration files alongside code. Developers should not have those kinds of secrets stored on their machines. A stolen or compromised developer laptop quickly turns into a nightmare when it's loaded with production secrets.
Instead, production secrets should be injected during deployment, manually or automatically, or stored in a location which only the production system can access. Note that this means it is perfectly safe to store encrypted production secrets alongside code in configuration files. As long as only the production environment can decrypt them. This last part is important.
Never reuse secrets
Lastly, you should never reuse secrets in a production and non-production environment. This is obvious for passwords, but actually applies much more broadly. Don't reuse passwords, cryptographic keys, tokens, credentials, cookies, or any other value that should be unique.
Protecting application secrets can be quite a challenge at first but can be made easy with the right tools and techniques. Does your organization have a good process in place? Find out with a full SAMM assessment. Or read how to organize basic data protection or practice best-effort patching. Our #2 and #1 recommended security practices.
