Because delivery systems are often the place where secrets are introduced, moved, and exposed. If credentials are hardcoded, stored in plaintext, or handled inconsistently across pipelines, the delivery process itself becomes an identity risk. Centralised retrieval and policy checks turn secrets handling into a governed control rather than an informal habit.
Why This Matters for Security Teams
secrets handling and DevOps are inseparable because the delivery system is now part of the identity perimeter. Build agents, release pipelines, IaC jobs, and deployment controllers routinely request, transform, and pass credentials, which means weak handling turns operational automation into an exposure path. The issue is not just storage hygiene; it is whether the pipeline can prove what it is allowed to do at the moment it does it. NHI Management Group’s Guide to the Secret Sprawl Challenge shows how quickly unmanaged secrets accumulate across delivery workflows, and OWASP’s OWASP Non-Human Identity Top 10 frames these credentials as identities that must be governed, not scattered artifacts.
That matters because secrets do not only leak from code. They appear in CI variables, artifact metadata, logs, runners, and chat-driven ops handoffs. The operational failure is usually systemic: teams secure the vault but leave the pipeline, runner, or promotion step with broad access and no consistent retrieval policy. In practice, many security teams encounter credential abuse only after a compromised pipeline has already moved laterally through multiple environments, rather than through intentional design.
How It Works in Practice
Good design starts by treating each delivery stage as a distinct workload identity. A build job should authenticate as a build job, a deploy job as a deploy job, and neither should inherit standing access just because it is “part of CI/CD.” Current guidance suggests using workload identity and short-lived credentials so the pipeline proves what it is before it receives anything useful. That is the practical difference between storing secrets and governing access to them.
In a mature setup, the pipeline asks a central secrets service for a task-specific credential, receives a short TTL token or dynamic secret, uses it once, and then lets it expire. Policy decides whether that request is valid based on context such as repository, branch, environment, deployment window, and change ticket. This is where runtime controls matter more than static role maps. A generic RBAC model cannot express all of the risk conditions that appear in delivery automation, especially when secrets move across pre-build, test, sign, and deploy stages.
- Use centralised retrieval rather than embedding credentials in YAML, images, or environment files.
- Bind issuance to workload identity, not to a person’s long-lived access token.
- Prefer ephemeral secrets with automatic revocation over reusable static credentials.
- Log every retrieval request, denial, and secret rotation event for auditability.
- Block plaintext exposure in logs, artifacts, and chatops outputs.
NHI Management Group’s CI/CD pipeline exploitation case study and 230M AWS environment compromise both illustrate the same pattern: once a delivery system can fetch broad credentials without strong context checks, it becomes a high-value identity target. These controls tend to break down in self-hosted runners and ad hoc deployment jobs because local persistence, shared caches, and inconsistent logging defeat the assumptions behind short-lived access.
Common Variations and Edge Cases
Tighter secrets controls often increase pipeline friction, so organisations have to balance delivery speed against exposure risk. That tradeoff becomes visible when teams migrate from developer-managed credentials to centrally issued, short-lived secrets, because some workflows that “used to work” were actually relying on hidden privilege and manual overrides.
There is no universal standard for this yet, but best practice is evolving toward contextual issuance for each environment. Production deployments usually justify stricter policy, narrower scopes, and shorter TTLs than ephemeral preview environments, while lower-risk jobs may tolerate broader automation if the blast radius is tightly bounded. The hard part is consistency: if one toolchain uses vault retrieval, another uses static environment variables, and a third copies secrets through ticket comments, governance fails at the seams.
Watch for edge cases such as break-glass access, air-gapped build systems, and legacy release tooling that cannot do workload identity natively. Those environments often require transitional controls, but the goal remains the same: secrets should be issued just in time, scoped to a specific task, and revoked automatically. Where teams rely on manual rotation or long-lived shared credentials, the process becomes brittle and review gaps widen. The 2024 State of Secrets Management Survey shows how common dissatisfaction remains when secrets are not centrally managed, which is why operational control and pipeline design have to be planned together from the start.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers secret rotation and lifecycle control for machine identities. |
| OWASP Agentic AI Top 10 | A-03 | Addresses credential exposure in autonomous or tool-using delivery agents. |
| NIST AI RMF | GOVERN | Governance requires accountability for how automated systems obtain and use secrets. |
Issue short-lived secrets, rotate them automatically, and revoke them on task completion.
