Secrets Management in Modern Application Environments

When a widely used GitHub Action was compromised, CISA issued an alert. The tampered action printed secrets from the CI runner’s memory into workflow logs. In public repositories those logs were readable by anyone. A build step that thousands of projects trusted turned into a way to harvest the credentials those projects had loaded to do their jobs.

The lesson is not that CI is dangerous. It is that a secret is only as safe as the least-trusted place it has to be at runtime, and most organizations have far more such places than they have counted. Pipelines, container images, environment variables, infrastructure state files, developer laptops and chat threads all hold copies.

Most secrets management efforts begin with a vault, and a vault is necessary. It does not answer the harder questions: how many secrets exist, how long each lives, and what an attacker can do with one before anyone notices.

Secrets are not all the same thing

Teams use the word for several different objects, and the right handling differs. Mixing them produces policies that fit none.

NIST’s key management guidance, SP 800-57, treats keys through a defined lifecycle: generation, distribution, use, storage, rotation and destruction. The same discipline applies to bearer secrets even though they are not cryptographic keys. The difference matters in practice. Rotating a bearer token is an operational task. Rotating an encryption key that protects stored data may mean re-encrypting that data, which is why encryption keys belong in a service built to manage them.

Reduce, shorten, then store

Treating the vault as the goal produces a familiar outcome: a tidy home for credentials that are still numerous, long-lived and over-privileged. A more effective order of preference:

• Eliminate. Where the platform supports it, give workloads an identity (a managed identity, a federated token exchange) so no static secret exists to leak.

• Shorten. Where a secret is unavoidable, issue it dynamically with a lease, so a stolen copy expires. OWASP’s guidance is clear that restarting an application does not revoke a leaked credential. Only expiry or explicit revocation does.

• Store and rotate. Whatever remains goes into a central manager with scoped access, automated rotation and audit logging.

• Detect and respond. Assume some will leak anyway, and make sure you can find and revoke them fast.

The measures worth tracking follow from that order: how many workloads still use static long-lived credentials, how old the oldest are, and how long revocation takes for a credential that has been exposed. Those numbers are specific to each organization and should be measured, not benchmarked against guesses.

Where secrets leak in modern environments

Source control and history

Deleting a secret from the latest commit does not remove it from history. Once a secret has been pushed, treat it as exposed and rotate it. Scanning needs to run before commit, on the server, and over existing history, because secrets committed years ago remain valid surprisingly often.

Pipelines

Build systems hold powerful credentials and run third-party code. The compromised action above is the case in point. Scope pipeline credentials to the job, prefer short-lived tokens issued per run, and avoid long-lived deployment keys stored as repository variables.

Containers and orchestration

Secrets baked into an image travel with every copy. In Kubernetes, Secret objects are base64-encoded by default, not encrypted, and anyone with read access to them can decode them. The Kubernetes documentation recommends encryption at rest, tight access control and, where possible, external secret stores.

Infrastructure as code

State files often contain resolved secret values in plain form. Treat them as sensitive stores with restricted access and encryption, not as build artifacts.

AI and automation

Keys for model APIs and agent tool access are bearer credentials like any other, often created quickly and pasted into notebooks or prototypes. They deserve the same scoping, expiry and scanning.

Failure modes that undermine the vault

• Vault sprawl. Each team deploys its own, with different rules and no central visibility. Standardizing on a small number of approved patterns beats a perfect single product.

• The root credential in a wiki. The secret that unlocks the secrets manager is the highest-value credential in the estate. It needs its own protection and recovery process.

• Over-broad read access. An application that can read every secret under a path turns one compromised service into many.

• Rotation nobody dares run. If rotating a credential breaks production, it will not be rotated. Test rotation in lower environments until it is boring.

• Shared secrets across environments. A development credential that also works in production makes the weakest environment the entry point to the strongest.

• No revocation plan. In an incident, the first question is who can revoke this and what depends on it. If the answer takes hours, the blast radius grows in the meantime.

What to ask before the next tooling decision: for any given credential, who can revoke it, what breaks when they do, and how quickly would we know it was being misused? A secrets program that cannot answer those questions has storage, not control.

Many organizations find that the harder questions around encryption keys sit unowned between security, platform and application teams. Where that is true, assessing how keys are generated, held, rotated and retired, and by whom, is a sensible next step. Cryptographic key management is the part of the problem where mistakes are slow to surface and expensive to reverse.

Sources

• OWASP Cheat Sheet Series. Secrets Management Cheat Sheet

• NIST. Special Publication 800-57 Part 1, Recommendation for Key Management: General

• Kubernetes Documentation. Good practices for Kubernetes Secrets

• CISA. Alert on the supply chain compromise of the tj-actions/changed-files GitHub Action cisa.gov