Applications depend on sensitive values such as API keys, database passwords, signing keys, client secrets, and service credentials. These values often provide direct access to data or privileged operations, so protecting them requires more than keeping them out of source code.
Good secrets management controls the entire lifecycle: creation, storage, delivery, use, rotation, revocation, and incident response.
Treat secrets as credentials, not configuration
A useful distinction is whether disclosure of a value would let an attacker authenticate, decrypt protected information, forge trusted data, or perform privileged actions.
Values such as feature flags and public service URLs are configuration. Database passwords and private signing keys are secrets.
This distinction matters because secrets need stronger controls. They should not be copied casually between configuration files, tickets, chat messages, build logs, or documentation.
Keep secrets out of source control
Do not place real credentials in application source code or committed configuration files.
Moving a secret into a file ignored by version control is useful for local development, but it does not solve production secret management. Production systems still need a controlled way to store and deliver credentials.
If a secret has already been committed, deleting it from the latest version of a file is not sufficient. Repository history, forks, caches, build artifacts, or developer clones may still contain the value. Treat the credential as exposed and rotate or revoke it.
Secret scanning can help detect accidental commits, but detection is a safety net rather than permission to store secrets in repositories.
Use a dedicated secret store where practical
A secret-management system can centralise sensitive values and enforce access controls around them. Depending on the environment, this may be a managed secrets service, a dedicated vault, or another platform facility designed for protected credential storage.
The important properties are more useful than the product name. A suitable system should make it possible to:
- restrict which identities can read each secret;
- encrypt stored secret material;
- deliver secrets only to authorised workloads;
- record security-relevant access metadata;
- update or revoke credentials without editing application source;
- separate production secrets from development and test credentials.
Centralisation also makes ownership clearer. Teams can answer which applications use a credential and who is allowed to change it.
Prefer workload identity over long-lived secrets
The safest long-lived secret is often one that does not need to exist.
When infrastructure supports workload identity or another short-lived credential mechanism, prefer it over static access keys. A workload can authenticate using its platform identity and receive narrowly scoped, temporary credentials.
Short-lived credentials reduce the useful lifetime of stolen material and make routine rotation easier. They do not remove the need for access control: the workload identity itself must still receive only the permissions it requires.
Deliver secrets without exposing them unnecessarily
A secret should reach the component that needs it without passing through unrelated systems or people.
Environment variables are convenient and widely supported, but they are not automatically secure. Depending on the runtime and operational tooling, environment values may appear in process inspection, diagnostics, crash reports, deployment interfaces, or support bundles.
Mounted files can provide tighter filesystem permissions in some environments, while a secret-management client can fetch credentials at runtime. Each approach has trade-offs. Choose a delivery mechanism based on the platform’s threat model rather than assuming one method is universally safe.
Whatever mechanism is used, avoid printing the resolved value during deployment or application startup.
Apply least privilege to secret access
Do not give every application access to a shared collection of credentials.
A service that only needs one database credential should not be able to read unrelated payment, email, or signing secrets. Production workloads should not automatically receive development credentials, and developer accounts should not receive production secrets merely for convenience.
Separate credentials by application, environment, and purpose where practical. This limits the impact of one compromised workload or account.
Also separate administrative permissions from read permissions. The ability to change secret policies or create new versions is different from the ability to retrieve a secret value.
Rotate with a plan
Rotation is valuable only when applications can adopt the new credential safely.
For credentials that support overlapping validity, a practical sequence is:
- create a new credential;
- make it available to the authorised application;
- confirm that the application is using it successfully;
- revoke the old credential;
- verify that no dependent system still relies on the old value.
For systems that cannot support overlap, coordinate the change carefully to avoid outages.
Rotation frequency should reflect the credential’s sensitivity, lifetime, exposure risk, and operational cost. More importantly, teams should be able to rotate critical credentials quickly when compromise is suspected.
Do not leak secrets into logs
Logging is a common secondary exposure path.
Avoid recording passwords, access tokens, session identifiers, private keys, complete connection strings containing credentials, or request headers that may contain authentication material.
Redaction should happen before sensitive values reach general logging pipelines. Filtering only at the final log destination can leave copies in intermediate collectors or error-reporting systems.
When auditing secret use, record useful metadata instead of the value itself. For example, record the requesting workload identity, secret identifier, operation, timestamp, and result.
Be careful with error messages and debugging
Debugging tools often collect more context than normal application logs. Exception objects, HTTP traces, configuration dumps, command histories, and diagnostic archives can accidentally preserve credentials.
Design support procedures so engineers can diagnose failures without routinely exposing secret values. If temporary sensitive diagnostics are unavoidable, restrict access, minimise retention, and remove them when the investigation ends.
Prepare for secret exposure
Assume that a credential may eventually be copied to the wrong place, included in a log, committed to a repository, or stolen from a compromised workload.
An exposure response should identify:
- what capability the secret grants;
- which systems use it;
- whether it can be revoked immediately;
- how to issue and distribute a replacement;
- what logs can show suspicious use;
- which dependent credentials may also need rotation.
Do not wait for proof that an exposed credential was abused before replacing it. Once confidentiality is lost, continued trust in the value is difficult to justify.
Maintain an inventory and ownership
Secrets become difficult to manage when nobody knows why they exist.
For important credentials, maintain enough metadata to identify the owner, purpose, consuming workload, environment, expected lifetime, and rotation procedure. Avoid placing the secret value itself in the inventory.
Regularly remove credentials that are no longer used. Old credentials expand the attack surface and are especially dangerous when their original owners or applications have disappeared.
A practical baseline
A reasonable baseline for application secrets is straightforward:
- never commit real secrets to source control;
- use controlled secret storage for production credentials;
- prefer short-lived workload credentials when available;
- grant access only to the identities that require it;
- keep secrets out of logs and diagnostic output;
- separate credentials across environments and purposes;
- practise rotation before an emergency requires it;
- revoke exposed or unused credentials promptly;
- keep ownership and usage information current.
Secrets management is not primarily about hiding strings. It is about limiting who can obtain powerful credentials, reducing how long those credentials remain useful, and making replacement routine when trust is lost.