TL;DR: CI/CD pipelines still expose broad, long-lived credentials that attackers can steal from runners, logs and workflow configs, according to Aembit, with recent incidents showing that pipeline compromise can unlock production infrastructure at scale. Static secrets turn build systems into persistent breach surfaces, not isolated developer tools.
At a glance
What this is: This analysis argues that CI/CD secrets, not code alone, are the real breach surface because pipeline credentials routinely unlock production systems and are repeatedly exposed through runners, logs and workflow configuration.
Why it matters: IAM, PAM and NHI teams need to treat pipeline identity as production access, because static credentials in build systems create standing privilege that outlives the job and expands breach impact.
By the numbers:
- 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.
Context
CI/CD secrets are credentials used by build and deployment pipelines to reach cloud accounts, registries, databases and third-party services. The governance problem is not the code path itself but the fact that those credentials often sit outside normal lifecycle controls, making the pipeline a high-value identity container.
The article’s central claim is that pipeline compromise is now a production access problem. Static secrets, duplicated across runners and configuration files, create a breach surface that persists long after the workflow that used them has finished.
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 do privileged credentials in CI/CD pipelines create higher breach risk?
A: Privileged credentials in pipelines create higher risk because they are used repeatedly across build, test, and deployment systems, often by machines and service accounts rather than people. If an API token, SSH key, or delegated machine credential is exposed, an attacker can move quickly through connected systems, abuse overprivileged access, and reach production assets before defenders notice.
Q: How can security teams tell if a pipeline identity is over-permissioned?
A: Look for workflows that can deploy, provision, or administer environments without separate approval, short-lived credentials, or environment-specific scoping. If a single action can access cloud, Kubernetes, and source control secrets, the identity is larger than the job it supports. Over-permissioning shows up where compromise can cross control planes.
Q: What should teams do when CI/CD pipeline access must span cloud and SaaS services?
A: They should centralize trust and audit around workload identity rather than creating separate long-lived credentials for each destination. The goal is to issue short-lived, scoped access at runtime and keep offboarding, logging and policy enforcement consistent across every service the pipeline can reach.
Technical breakdown
Why static pipeline secrets create standing privilege
Static credentials in CI/CD environments behave like long-lived service accounts without the governance discipline that normally surrounds them. They remain valid until explicitly revoked, they are often copied into environment variables or config files, and they are reused across jobs, runners and environments. That combination creates standing privilege: if an attacker reaches one workflow or runner, the credential can usually be replayed elsewhere. In identity terms, the pipeline is not just executing code, it is holding production authority in a form that is easy to exfiltrate and hard to inventory.
Practical implication: Treat every persisted pipeline secret as production access and remove standing credentials wherever a workflow can authenticate at runtime.
How OIDC federation changes CI/CD authentication
OIDC federation replaces stored credentials with a short-lived token exchange. The CI/CD platform proves the workflow’s identity through signed claims such as repository, branch, environment and triggering actor, then the cloud provider issues temporary access scoped to that specific run. This changes the attack surface in two ways. First, there is no reusable secret sitting in the pipeline to steal. Second, access is minted only when the job is executing, which sharply narrows replay opportunities and makes credential theft much less durable.
Practical implication: Use OIDC-based workload identity for pipeline-to-cloud access so authentication happens at runtime instead of through stored secrets.
Why federated pipelines still need governance beyond a token exchange
Federation removes secret storage but it does not eliminate identity governance. A pipeline may still need access to multiple clouds, SaaS services and internal systems, each with its own trust relationship. That can fragment audit trails and leave policy gaps around runner posture, deployment windows and contextual access. In other words, federation solves one failure mode, but it does not automatically give you centralized policy, consistent visibility or cross-environment lifecycle control for the workload identity itself.
Practical implication: Centralize policy and logging for pipeline identities so each federated trust relationship is governed as part of one lifecycle, not as an isolated integration.
Threat narrative
Attacker objective: The objective is to obtain durable production access by stealing pipeline credentials that can be reused beyond the original build job.
- Entry occurs when an attacker compromises a repository, workflow, runner or supply-chain dependency that can trigger CI/CD automation.
- Credential access follows when the workflow, build log or runner memory exposes long-lived secrets such as cloud keys or personal access tokens.
- Escalation happens when those credentials are replayed against cloud, registry or deployment services that grant broader production access than the pipeline actually needs.
- Impact is production infrastructure compromise, secret exfiltration or downstream supply-chain poisoning across many repositories and services.
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.
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
CI/CD secrets are not a build-system convenience, they are production identities. Pipelines sit at the boundary of source control and runtime authority, which means a leaked credential is not a developer nuisance but a standing access path into cloud and deployment systems. The security model fails when teams treat those credentials as temporary configuration rather than governed identity. Practitioner implication: pipeline secrets must be managed as privileged non-human identities, not as incidental variables.
Secret persistence is the real breach multiplier in CI/CD environments. The article’s pattern is not a single exposed token but a credential estate that is copied into logs, runners, images and configs until one compromise becomes many. That is classic NHI reuse and long-lived secret debt, and it increases the blast radius of every supply-chain incident. Practitioner implication: the control question is no longer where the secret lives once, but how many places it can be replayed from.
Workload identity federation is the right direction, but only when paired with lifecycle governance. Short-lived tokens remove the stored-secret problem, yet the governance burden shifts to trust policy, scope, issuer validation and auditability across services. Without centralized lifecycle control, teams can still end up with fragmented federation sprawl that is hard to review and harder to offboard. Practitioner implication: judge federation by its governance model, not by whether it eliminates a password-shaped secret.
Credential debt is becoming a category-level risk in software delivery. As CI/CD systems absorb more cloud targets, third-party APIs and AI-driven automation, the number of identities that need issuance, scope control and revocation keeps rising. The breach surface is no longer the pipeline alone, but the accumulation of every exception made to keep delivery moving. Practitioner implication: identity architecture for software delivery has to be designed for continuous issuance, not static access.
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.
- Read next: Cloud Workload Identity Guide
What this signals
Pipeline identity is moving from exception handling to core access governance. Once build systems can reach cloud accounts, registries and third-party APIs, they belong in the same identity lifecycle as services and workloads. Teams that keep treating CI/CD credentials as temporary implementation detail will keep missing the fact that they are governing production authority, not convenience access.
Credential duplication is the hidden control failure in most delivery environments. A secret that appears in logs, runners and config files is no longer a single credential, it is a replicated access surface. That makes revocation, attestation and offboarding more important than the original issue of how the secret was created.
Workload identity should become the default control point for CI/CD access. Short-lived tokens and centralized policy do not just reduce leakage, they give IAM and NHI teams a coherent place to enforce scope, expiry and audit for every build-time identity. The governance win is not only stronger authentication, but a controllable lifecycle for machine access.
For practitioners
- Replace stored pipeline keys with federated workload identity Use OIDC-based authentication for GitHub Actions, GitLab CI/CD and other build systems so workflows exchange a signed identity assertion for short-lived cloud credentials.
- Reduce pipeline blast radius with run-scoped permissions Map each deployment, test and signing job to the narrowest cloud role it needs, then separate read-only, write and release privileges by workflow stage.
- Inventory every place a pipeline secret can reappear Search runner images, build logs, environment files, config repositories and troubleshooting chat history for duplicated credentials that survive the original job.
- Govern third-party and AI-connected pipeline identities Treat every external service, agent and integration that touches CI/CD as an identity subject with explicit onboarding, scope and offboarding controls.
Key takeaways
- CI/CD pipelines have become a production access surface because their credentials often unlock cloud infrastructure, registries and deployment systems.
- The article ties that risk to scale, with 28.65 million new hardcoded secrets on public GitHub in 2025 and 59% of compromised machines in Shai-Hulud 2 being CI/CD runners.
- Short-lived workload identity shifts the control point from secret storage to runtime trust, which is the only durable answer to pipeline credential debt.
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 MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets 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 centers on secrets exposed in runners, logs and workflow configs. |
| NHI-07 — Long-Lived Secrets | Static pipeline credentials and four-year-valid secrets are the core failure mode here. | |
| NHI-05 — Overprivileged NHI | Pipeline credentials often have broader access than the job actually needs. | |
| Recommendation — Scan CI/CD environments for exposed secrets and remove any credential that can be replayed outside the job. Replace long-lived pipeline credentials with short-lived runtime tokens and revoke persistent secrets. Reduce pipeline entitlements to the minimum resource scope required for each workflow stage. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The incident pattern is credential theft from pipelines leading to production impact. |
| Recommendation — Map pipeline secret exposure to credential access and impact to prioritise detection on build runners. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle and rotation are central to the article’s risk model. |
| Recommendation — Apply authenticator management to rotate or eliminate pipeline secrets that persist beyond the job. | ||
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.
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
- 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.
- Runner Posture: The security condition of the system executing a CI/CD job, including its hardening level, isolation, logging, and trustworthiness. For build identity, runner posture matters because even correctly issued credentials can be abused if the execution environment is compromised or poorly controlled.
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 June 6, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org