OWASP's secrets management guidance boils down to a few habits: centralise and standardise, give each person and service only the secrets they need, automate rotation, use short-lived credentials, log access, and keep a tested break-glass path. Never hardcode secrets in source or Docker ENV and ARG lines.
Rule 1: centralise and standardise
OWASP says to centralise secrets management and to protect the manager's own primary secret in a secondary system. One place makes access control, rotation and audit possible. Scattered copies in chat, wikis and env files do not.
Rule 2: least privilege, per secret
Engineers should not have access to all secrets, and access should be fine-grained per object. On Azure, OWASP suggests separate vaults per application and environment as the main boundary. Restrict who can pass roles, create IAM entities or impersonate service accounts.
Rule 3: automate, and prefer short-lived
Limit human handling. Rotate static secrets automatically. For dynamic secrets, issue credentials per session with short leases and revoke them when done. OWASP uses static secrets only for long-lived key material or services that cannot issue temporary credentials.
Rule 4: audit what happens
Log requests and approvals, usage, expirations, reuse attempts, authentication errors, updates and admin actions. Protect the logs and keep timestamps accurate. Alert on odd access by IP or user agent.
Rule 5: treat CI/CD as production
Keep as few secrets as possible in CI tooling, let consumers fetch secrets at runtime when possible, and use short-lived, tightly scoped credentials to reach the manager.
Rule 6: containers
Prefer orchestrator-mounted files or sidecar-fetched in-memory secrets over environment variables, which OWASP generally discourages.
Rule 7: plan for failure
Back up secrets, encrypt backups and test restores. Keep break-glass credentials in a secondary system. Scan for secrets early, in IDEs and pre-commit hooks, and use more than one tool.
Rule 8: know what to do on a leak
Revoke immediately, rotate with automation, delete from code and logs, and think before rewriting git history. See rotating without downtime.
What to avoid
Hardcoding, one shared credential for many users, blanket access, plaintext logging and keeping encryption keys beside the data.
Click through it at your own pace, or open it full screen.
Safeguard offers policies and gates that can block a pull request, plus SBOM and dependency scanning. You can run a free scan at gold.safeguard.sh/scan.
If you are starting from scratch, do not try to adopt every rule at once. Begin with an inventory of where secrets live today, move the most sensitive ones into a central manager, remove blanket access, and turn on access logging. Then work through rotation and short-lived credentials one system at a time. Progress you can measure beats a perfect design that never ships.
Quick check
Do I need a dedicated vault product?
OWASP prefers the provider's native service for a single cloud and a cloud-agnostic option for multi-cloud. The key is centralisation, not the brand.
Are environment variables acceptable?
OWASP discourages them unless other methods are impossible.
Sources
Last reviewed: 19 October 2026.
