Secrets Management

Secrets management is the practice of storing, delivering, rotating, and revoking credentials — database passwords, API keys, certificates, tokens — so that no configuration file, repository, or log holds them in readable form. Guidance below follows the OWASP Secrets Management Cheat Sheet, checked in September 2026.

The rule the whole practice reduces to: configuration references a secret; it never contains one. Everything else is about making that reference convenient enough that nobody is tempted to shortcut it.

With one qualification that is easy to miss and expensive to miss: referencing a secret is not the same as never handling it. If a tool reads the value during a run and passes it on, that tool has the value and may persist it — so the question to ask of any “we reference it now” claim is which component ends up holding the plaintext. The section on state files below is the concrete case.

Where secrets actually leak

The leaks that matter are rarely dramatic. They are places a secret ends up because someone did the obvious thing.

• Infrastructure state and plan files. Put a value in a definition and the tool records it — an infrastructure state file commonly contains initial database passwords, in plain text when stored locally. Reading the value from a secret store during the run does not by itself change this: if the tool receives the plaintext and passes it to a resource, it is stored. Terraform is explicit that values marked sensitive are still kept — Terraform “stores values with the sensitive argument in both state and plan files” and the marking only redacts output — and that a saved plan holds sensitive data “in cleartext.” Omitting values needs a mechanism built for it, such as Terraform’s ephemeral values, which are “available at runtime” but omitted “from state and plan files entirely,” subject to version and provider support.
• CI logs and build output. Anything printed for debugging, and anything a tool echoes back, persists wherever logs are kept and for as long as they are kept.
• Image layers. A file added and later deleted in a subsequent layer is still in the image.
• Error reports and diagnostics. A crash dump or an environment listing includes the process environment, which includes whatever was injected into it.
• Repository history. Removing a committed secret from the current files does not remove it from history, so the remediation is rotation rather than deletion.

That last point generalizes usefully: once a secret has been somewhere it should not be, the only reliable response is to change the secret. Cleaning up the location is housekeeping.

The lifecycle

“Secrets follow a lifecycle. The stages of the lifecycle are as follows: Creation, Rotation, Revocation, Expiration.” Most organizations implement the first and intend the rest, which is worth noticing because the later stages are the ones that limit damage.

• Creation. “New secrets must be securely generated and cryptographically robust enough for their purpose,” and — easy to skip — “secrets must have the minimum privileges assigned to them to enable their required use/role.” A credential scoped to everything is a credential whose theft costs everything, which is least privilege applied at issue time. Delivery matters too: “you should transmit credentials securely,” ideally not sending a password alongside the username it belongs to.
• Rotation. For static secrets, “it is therefore better to automate the rotation of keys or at least ensure that the process is sufficiently supported by IT,” since manual rotation “is a challenging process when implemented manually, and can lead to mistakes.” Note one consequence people discover late: rotating encryption keys “might trigger full or partial data re-encryption.”
• Revocation. The ability to make a credential stop working now, without waiting for expiry — which is the same capability as access revocation and should be tested rather than assumed.
• Expiration. A secret that ends on its own is worth more than a rotation policy nobody runs.

Which is the argument for short-lived credentials wherever they are available: “dynamic secrets should be used where possible to reduce the surface area of credential reuse.” A leak then has a bounded cost by construction rather than by procedure.

Be precise about what bounds it, though, because the convenient summary — restart the application and a stolen credential is dead — is not how the mechanism works. In Vault’s model every dynamic secret carries a lease, and Vault “promises that the data will be valid for the given duration, or Time To Live (TTL).” What ends validity is expiry or revocation: “when a lease is expired, Vault will automatically revoke that lease,” and an explicit revoke “invalidates that secret immediately and prevents any further renewals.” Restarting your application issues a new credential to the new instance; the stolen one keeps working until its lease expires or someone revokes it (and revoking the issuing token revokes “all leases that were created using that token”).

So the number that describes your exposure is the TTL, and the control that shortens it is revocation on the compromise path — which is why revocation below is a capability to test rather than to assume.

Five principles worth adopting

• Centralize, but read the qualification. “You must standardize and centralize the secrets management solution with care” — and realistically, “standardizing and centralizing can mean that you use multiple secret management solutions.” The goal is that “teams standardize the interaction with these different solutions,” so they “remain maintainable and usable in the event of an incident.” One consistent interface, not necessarily one product.
• Nobody has access to everything. The reasoning is about the human as an additional exposure: “when users can read and/or update the secret in a secret management system, it means that the secret can now leak through that user and the system they used to touch the secret.” So “engineers should not have access to all secrets,” and the store must support “fine-grained access controls on each object and component.”
• Remove humans from the path. “Manual maintenance not only increases the risk of leakage; it also introduces the risk of human errors while maintaining the secret,” so “it is better to limit or remove the human interaction with the actual secrets” — through a secrets pipeline, or by having applications request credentials at startup.
• Audit in a way that survives an attacker. “You must implement auditing securely to be resilient against attempts to tamper with or delete the audit logs.” The minimum record is specific: who requested a secret and for what system and role, whether it was approved or rejected, when it was used and by whom, when it expired, whether expired secrets were reused, authentication and authorization errors, updates and who made them, and administrative actions. “It is essential that all auditing has correct timestamps.” This is a stronger standard than a general-purpose audit log.
• Treat availability as a requirement, not a bonus. “It is vital to select a technology that is robust enough to service traffic reliably.” Two reasons are given, and the first is the one that gets discovered during an outage: responders “expect to be provisioned with credentials rapidly, so they can recover services that have gone offline,” and “having to wait for credentials could impact the responsiveness of the operations team.” The second is ordinary operation — a slow store “could degrade the availability of dependent applications or increase application startup times.”

That last point deserves a decision rather than a hope: a secrets service on the recovery path needs its own availability answer and a documented break-glass route, because “we could not get the credentials” is an unacceptable sentence in an incident review.

Configuration is not a secret, and the line matters

A hostname and a password may arrive through the identical mechanism — an environment variable, a mounted file — and they need opposite handling. Configuration belongs in version control, where it is reviewed and diffed. Secrets do not.

The test is simple: if publishing the value would require you to change something, it is a secret. Blurring the line is how credentials end up in the same file as endpoints, and then in the same repository, and then in the same search result.

Where a pipeline is involved, generation can be moved there — “you can use pipeline tooling to generate secrets and either offer them directly to the service deployed by the tooling or provide the secret to a secrets management solution.” A variant keeps secrets encrypted in git, which is workable under two conditions worth stating because they are commonly violated: “developers cannot decrypt the secrets themselves” and “every consumer of a secret has its encrypted variant,” with a different secret per environment encrypted under a different key so that “a secret does not leak cross-environment.”

Finally, automate detection rather than relying on review, since “shift-left and DevSecOps principles apply to secrets detection as well.” Two practical notes from the same guidance: enable detection at the developer’s machine to avoid the commit in the first place, and “create standard test secrets and use them universally across the organization,” which keeps false positives manageable by giving scanners one known value per secret type to ignore.

How this applies to infrastructure definitions specifically — where the state and plan files are the leak nobody expects — is worked through in The File That Says What Exists, alongside infrastructure as code more generally.

Reference: Terraform documentation, Manage sensitive data in your configuration; Vault documentation, Lease, renew, and revoke; OWASP, Secrets Management Cheat Sheet (checked September 2026).