Who is accountable when a workload secret is exposed in CI/CD?

Accountability usually sits across platform, application, and security teams, because the leak often comes from deployment design rather than a single mistake. The practical answer is to assign ownership to the system that creates, injects, or stores the credential, then require lifecycle controls for every environment it touches.

Why This Matters for Security Teams

A CI/CD secret exposure is rarely just a “developer mistake.” It usually reflects a control gap in how the pipeline creates, injects, stores, and later revokes credentials. That is why accountability must be assigned to the system owner and the teams that approved the design, not only the person who committed the secret. In secrets-sprawl incidents, the impact also extends beyond one repository, because leaked values can persist across runners, environments, and downstream services. GitGuardian’s The State of Secrets Sprawl 2026 found that 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, which shows how often the pipeline becomes the blast radius.

Current guidance suggests treating the pipeline as part of the production trust boundary, not as a disposable build utility. That is consistent with the OWASP Non-Human Identity Top 10, which puts NHI ownership, rotation, and secret handling on the critical path. In practice, many security teams discover the accountability problem only after a revoked token was never fully revoked, rather than through intentional design review.

How It Works in Practice

The practical answer is to assign accountability by control plane, then map that to named human owners. The platform team is usually accountable for how the CI/CD system authenticates, stores, and injects secrets. The application team is accountable for whether the workload really needs the secret at all, and whether it can use workload identity instead. Security is accountable for policy, detection, and enforcement standards. That split matters because a leaked secret is often a symptom of static credentials where ephemeral, task-scoped access should have been used.

In mature environments, the preferred pattern is JIT credential provisioning with short TTLs, automated revocation, and workload identity as the default primitive. SPIFFE describes this as cryptographic identity for workloads, which is a better fit than embedding long-lived tokens in build jobs. See the SPIFFE workload identity specification and NHIMG’s Guide to SPIFFE and SPIRE for the identity layer. For real-world exposure patterns, NHIMG’s CI/CD pipeline exploitation case study shows how attackers often move from one leaked token to broader pipeline access.

• Define who owns the secret source, who approves its use, and who can revoke it.
• Prefer workload identity or short-lived tokens over static secrets in build steps.
• Store credentials centrally, inject them at runtime, and log every retrieval.
• Rotate and invalidate secrets automatically when a pipeline run completes or fails.

Where useful, pair this with the Guide to the Secret Sprawl Challenge and the Reviewdog GitHub Action supply chain attack to show how toolchain trust can become credential sprawl. These controls tend to break down when ephemeral runners are reused across projects because secret isolation and revocation become ambiguous.

Common Variations and Edge Cases

Tighter secret controls often increase deployment overhead, so organisations have to balance speed against auditability and blast-radius reduction. That tradeoff is especially visible in legacy CI/CD systems, where shared runners, long-lived service accounts, and manual approval gates were designed before workload identity became mainstream. There is no universal standard for who “owns” a leaked secret in every operating model, but best practice is evolving toward shared accountability with a single named system owner.

Edge cases include third-party build actions, multi-cloud pipelines, and agents that create or consume secrets autonomously. In those environments, the question is not just who exposed the secret, but which controller had the authority to issue it and whether the receiving workload should have been allowed to use it at all. NHIMG’s Shai Hulud npm malware campaign and the 52 NHI Breaches Analysis both show that exposed secret are often only the first step in a broader identity abuse chain. This is where Anthropic’s first AI-orchestrated cyber espionage campaign report is relevant: autonomous tooling can chain access faster than manual review can respond.

For governance, use The 52 NHI breaches Report to anchor your post-incident review, then map the result to policy frameworks such as OWASP-NHI, CSA-MAESTRO, and NIST-AIRMF.

Related resources from NHI Mgmt Group

• Why do CI/CD secrets create more risk than many teams expect?
• Should organisations prioritise workload identity over secret rotation?
• What breaks when CI/CD pipelines rely on static secrets?
• What breaks when CI/CD pipelines rely on static YAML alone?