TL;DR: CI/CD pipelines still concentrate long-lived secrets that can unlock production infrastructure, and Aembit says build runners, not developer workstations, are now a primary theft vector as federation replaces stored credentials with short-lived tokens and cryptographic attestation. The governance challenge is no longer whether federation works, but whether teams can manage trust, scope, and audit across multi-cloud delivery paths.
At a glance
What this is: This analysis argues that CI/CD pipelines have become high-value identity targets because static secrets in build systems remain exploitable far beyond the jobs that use them.
Why it matters: It matters because IAM, PAM, and NHI teams need to replace credential storage with workload identity federation while still governing scope, trust, and audit across delivery environments.
Context
CI/CD pipeline secrets and workload identity federation sit at the centre of a growing governance gap. Build systems now hold deployment credentials, cloud keys, and third-party tokens that can reach production, which means pipeline access is no longer an engineering convenience but an identity security control surface.
Aembit’s analysis focuses on the shift from static secrets to workload identity federation. The core problem is that persistent credentials outlive the workflow that created them, while federated tokens can narrow exposure if trust policies, cloud relationships, and audit trails are governed as a single operating model.
The practical question for identity teams is not whether pipelines can authenticate without stored secrets, but whether the surrounding governance can keep pace with multi-cloud delivery, AI-assisted automation, and expanding non-human identity estates.
Key questions
Q: What breaks when CI/CD pipelines rely on static secrets?
A: Static secrets create a reusable attack path into production infrastructure. Once they are copied into workflow files, logs, runner images, or environment variables, a single compromise can expose broad access long after the original job finishes. That is why pipeline secrets should be treated as production identity, not temporary configuration.
Q: Why does a CI/CD breach create so much downstream risk for authentication credentials?
A: CI/CD systems often sit close to source code, deployment workflows, and production access, so a breach can expose credentials that unlock many connected environments at once. When secrets are reused or long lived, attackers can move from the build system into repositories, cloud accounts, or administrative controls with very little friction.
Q: How do you know if workload identity federation is actually reducing risk?
A: You should see fewer long-lived credentials stored in containers, secrets managers, and pipeline variables, plus a smaller set of systems able to mint or reuse Anthropic access. If teams still depend on copied secrets for routine execution, federation has not yet changed the governance model in practice.
Q: What should organisations do when CI/CD identity spans multiple clouds and services?
A: They should treat federation as a governance model, not a one-off integration. Each additional cloud or service adds another trust relationship, another audit trail, and another place where context can drift. Central policy, consistent claim mapping, and unified logging become necessary once the pipeline must authenticate beyond a single provider.
Technical breakdown
Why static CI/CD secrets create persistent identity risk
CI/CD pipelines often use long-lived keys, passwords, and tokens to reach cloud accounts, registries, databases, and third-party services. Those credentials tend to spread into logs, environment variables, runner images, and configuration files, so compromise of one build path can expose far more than the original job needed. The technical problem is not just leakage. It is persistence plus over-scoping: the credential remains valid after the workflow ends and usually has broader access than the task requires. That combination turns every compromised runner into a reusable access path.
Practical implication: treat stored pipeline secrets as standing identity risk, not just secrets hygiene.
How workload identity federation changes pipeline authentication
Workload identity federation replaces stored credentials with a runtime exchange. The pipeline proves identity through a signed assertion such as OIDC, the target service validates claims about the repository, branch, environment, or actor, and temporary credentials are issued for a narrow purpose. The security gain is not magic trustlessness. It is a reduction in credential persistence and replay value. If the token expires quickly and is scoped tightly, an attacker who reaches the runner has less material to steal and reuse. The control still depends on accurate trust mapping between workload claims and allowed actions.
Practical implication: map each workload claim to a narrowly scoped authorization policy before removing static secrets.
Where federation still leaves governance gaps across CI/CD environments
Federation removes stored secrets, but it does not solve the full governance problem. Most real pipelines authenticate to multiple clouds and services, which multiplies trust relationships and creates fragmented audit evidence. A static cloud role can also miss contextual controls such as runner posture, deployment window, or environment state. That means federation answers who the workload is at the moment of access, but not always whether the surrounding context is acceptable. In practice, the remaining risk shifts from secret storage to policy sprawl and inconsistent enforcement across delivery paths.
Practical implication: govern federation as a cross-platform access model, not a point-to-point authentication feature.
Threat narrative
Attacker objective: The attacker wants reusable access to production infrastructure and trusted build paths by stealing credentials from CI/CD systems.
- Entry begins when attackers target CI/CD workflows through malicious pull requests, poisoned actions, or compromised build infrastructure that can execute with pipeline privileges.
- Credential access follows when the workflow exposes long-lived tokens, runner memory, or embedded secrets that the attacker can extract from logs or configuration.
- Escalation occurs when those credentials unlock cloud accounts, deployment systems, or third-party services with broader access than the original build job required.
- Impact is the reuse of pipeline-derived access to reach production infrastructure, exfiltrate secrets, or poison downstream software supply chains.
Breaches seen in the wild
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
- SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Static pipeline secrets are now credential debt, not just a configuration flaw. CI/CD environments accumulate access that outlives the job, the runner, and often the team that created it. Once a secret is embedded across configs, logs, and images, the organisation inherits a persistent identity liability that behaves like standing privilege. Practitioners should treat every stored pipeline secret as an exposure window that keeps reopening.
Workload identity federation is a trust model, not a destination. Replacing static credentials with short-lived tokens removes the easy replay path, but it also shifts governance to trust policy design, claim mapping, and audit coherence. If repository, branch, environment, and actor claims are loosely defined, federation can simply move risk from secret storage into mis-scoped authorization. Practitioners must evaluate the trust fabric, not just the authentication mechanism.
CI/CD has become the control plane where non-human identity and software supply chain risk converge. Pipelines now authenticate cloud resources, deployment systems, and AI-assisted automation in the same operational path. That means identity governance, supply chain controls, and workload access management can no longer be treated as separate programmes. Practitioners should align CI/CD access with broader NHI governance because the attack path now spans all three.
Identity blast radius is the right concept for modern delivery systems. The critical question is no longer whether a pipeline can authenticate, but how far a compromised workload can travel once it does. Static secrets amplify blast radius through persistence and reuse, while federation can narrow it only if scope is enforced at issuance time. Practitioners should measure pipeline access by reachable systems, not by credential count.
Agentic automation will make pipeline identity governance harder before it makes it easier. As AI-powered bots and automated agents interact with build systems, the number of non-human identities that can request or inherit access grows quickly. That increases the need for lifecycle governance, because every new automated actor expands the set of trust decisions the programme must control. Practitioners should assume the non-human identity estate inside CI/CD will keep expanding.
From our research library:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Credential debt is the operational failure mode this topic exposes. CI/CD environments accumulate secrets faster than teams can govern them, and each copied credential expands the number of places an attacker can harvest access. The next stage for practitioners is to redesign issuance so the pipeline never needs a reusable secret in the first place, rather than trying to chase every storage location after the fact.
The governance shift is from secret rotation to access issuance. Once a workflow can prove identity at runtime, the control question becomes who may receive what token, under which claims, and with what downstream scope. That is a better fit for workload identity than for inherited static credentials, especially where build and deployment paths cross multiple clouds.
For practitioners
- Inventory every pipeline-held secret Map credentials stored in code, config files, runner images, logs, and CI/CD variables before deciding what can be replaced with federation.
- Replace static deployment keys with federated tokens Use short-lived workload assertions for deployments, registry pushes, and service calls so the pipeline never stores reusable cloud credentials.
- Tighten trust policies around workflow claims Bind repository, branch, environment, and actor claims to specific roles and deny broad reuse across unrelated workflows or environments.
- Centralise audit for multi-cloud access paths Correlate access decisions across cloud providers and delivery services so investigators can trace which workload accessed which resource and why.
- Review runner posture before issuing credentials Require hardened runners, verified workflow context, and controlled deployment windows before temporary credentials are minted.
Key takeaways
- CI/CD pipelines have become high-value identity targets because static secrets remain reusable long after the build job that created them ends.
- The article ties that risk to real-world pipeline compromise patterns and to evidence that build runners are now a primary theft surface in major supply chain attacks.
- Workload identity federation helps by eliminating stored secrets, but practitioners still need tighter claim mapping, scope control, and audit across multi-cloud delivery paths.
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, MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on secrets exposed in CI/CD runners, logs, and configs. |
| NHI-07 — Long-Lived Secrets | Static credentials in pipelines remain valid long after the job that created them. | |
| NHI-05 — Overprivileged NHI | The article highlights broad pipeline permissions that exceed the job's actual needs. | |
| Recommendation — Eliminate leaked pipeline secrets and revoke any reusable credentials found in runners, logs, or config files. Replace long-lived pipeline secrets with short-lived credentials issued at run time. Scope CI/CD identities to the minimum resources each workflow requires. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The threat pattern is secret harvesting from build infrastructure and downstream reuse. |
| Recommendation — Map pipeline secret theft to TA0006 and TA0010, then hunt for runner log and memory exposure. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing pipeline entitlements and token scope. |
| Recommendation — Apply PR.AA-05 to constrain CI/CD entitlements to the exact workflow and resource set. | ||
| CIS Controls v8 | CIS-5 — Account Management | Pipeline identities and service accounts require lifecycle control and revocation discipline. |
| Recommendation — Use account management controls to inventory, review, and revoke pipeline identities on schedule. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Federated token exchange and service authentication are central to the pipeline access model. |
| Recommendation — Protect pipeline token exchange paths so workflows cannot authenticate outside approved claims and trust rules. | ||
Key terms
- Workload Identity Federation: A mechanism allowing workloads in one environment to authenticate to another using short-lived tokens rather than stored credentials, based on mutual trust between identity providers.
- Credential Debt: The accumulation of persistent, over-scoped, or duplicated credentials across systems that are hard to inventory and revoke. In CI/CD environments, credential debt increases blast radius because old secrets remain usable long after the original job or workflow should have ended.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Cryptographic Attestation: Cryptographic attestation is a method of proving that a workload or service is genuine by using cryptographic evidence instead of static shared secrets. It is especially useful for short-lived access models because identity proof is tied to runtime context rather than reusable credentials.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 30, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org