TL;DR: Breached accounts rose nearly eight times year over year in 2024, and more than 1.4 billion records were breached globally in May 2025, according to Probely, but the deeper issue is that security scans are still too often treated as one-off checkpoints rather than continuous pipeline controls. CI/CD security fails when governance is bolted on after development instead of being embedded across commit, build, and deployment stages.
At a glance
What this is: This article argues that CI/CD security breaks down when teams rely on isolated scans instead of continuous controls across code, build, and deployment stages.
Why it matters: It matters because identity, secrets, and pipeline governance all sit inside CI/CD workflows, so a weak integration model can expose development systems and the environments they deploy into.
By the numbers:
- 2024 saw breached accounts skyrocket to nearly eight times the number recorded in 2023.
- In May 2025, more than 1.4 billion records were breached globally.
Context
Secure CI/CD integration is the practice of embedding security controls into the software delivery pipeline rather than checking for problems only at the end. The governance gap is that many teams still treat scanning as a point-in-time task, which leaves code, builds, and deployments exposed between checkpoints.
That model is especially weak where pipeline components handle credentials, build artifacts, and deployment permissions. In practice, CI/CD becomes an identity and access problem as much as a code-quality problem, because compromise at any stage can affect the trust boundary for everything downstream.
Key questions
Q: How should teams stop treating CI/CD security as a one-time scan problem?
A: Treat CI/CD security as a continuous control problem. The practical shift is from isolated testing to pipeline-embedded checks that run at commit, build, test, and deploy. That lets teams catch vulnerable code, misconfigurations, and dependency drift before release, instead of discovering them after the software has already crossed the trust boundary.
Q: Why do CI/CD pipelines create secret governance risk?
A: Because they combine stored credentials, automated execution, and broad operational access in one place. If a pipeline can read a secret and use it to perform a privileged action, the secret becomes a standing access path. That risk grows when variables, logs, artifacts, or runner environments expose the credential beyond the intended job.
Q: What breaks when security scans are only run late in the delivery cycle?
A: When scans happen late, teams discover vulnerabilities after code has already moved far through the pipeline. That increases rework, makes fixes more disruptive, and encourages rushed remediation. Late scanning also reduces the chance of stopping insecure dependencies or misconfigurations before they reach release, which weakens both security posture and delivery confidence.
A: They should review whether the added component changes access scope, secret exposure, or the provenance of the build path. A trusted integration can still widen blast radius if its permissions are excessive or if its behavior changes unexpectedly. The control question is who can act, what they can reach, and how quickly access can be revoked.
Technical breakdown
Why point-in-time scanning misses pipeline risk
CI/CD pipelines are not static assets. They are chained systems where repositories, build runners, artifact stores, and deployment targets each introduce different exposure points. A single scan only measures a snapshot, while vulnerabilities, dependency changes, and pipeline configuration drift continue to accumulate after the scan completes. That means the control objective is not simply detection, but sustained assurance across commit, build, test, and release. In mature pipelines, security checks must align to the stage where the risk appears, otherwise findings arrive too late to change the outcome.
Practical implication: Treat scanning as a control embedded in each pipeline stage, not as a final gate before release.
How CI/CD becomes an identity and secrets problem
Build and deployment systems rely on service credentials, tokens, certificates, and other non-human identities to move work between stages. If those credentials are over-permissioned, long-lived, or loosely scoped, the pipeline becomes an attractive path for abuse. That is why secure CI/CD is not only about code analysis tools, but also about how the pipeline authenticates services, limits access, and handles secrets. The real governance question is whether the pipeline can prove who or what is acting at each step, and whether those permissions are still valid for that task.
Practical implication: Map every pipeline credential to an owner, a scope, and a rotation or revocation process.
Why security and delivery speed are in tension
The article reflects a common operational trade-off: teams want faster delivery, but security controls add friction when they are bolted on late or configured inconsistently. The answer is not to weaken controls, but to move them earlier and make them automated, predictable, and tied to workflow events. That reduces rework, prevents noisy late-stage failures, and avoids the false choice between velocity and assurance. When governance is built into the delivery path, security stops being an interruption and becomes part of the release system itself.
Practical implication: Design controls to run automatically in the pipeline so they support delivery instead of blocking it at the end.
Threat narrative
Attacker objective: The attacker wants to turn the software delivery pipeline into a trusted path for introducing vulnerable code, stealing secrets, or pushing unauthorised changes into production.
- Entry occurs when a vulnerable dependency, misconfigured pipeline step, or exposed code path reaches the build or deployment flow without being caught by continuous controls.
- Credential abuse follows when pipeline tokens, service accounts, or deployment secrets can be reused outside their intended stage or scope.
- Impact occurs when the weak pipeline trust model allows vulnerable code or unauthorised changes to ship into production and expose downstream systems.
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 and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Secure CI/CD is fundamentally a governance problem, not a tool-selection problem. The article is right to separate capability from control: scanning tools do not create security if they are used as periodic checkpoints. What matters is whether the pipeline has enforced ownership, scoped access, and continuous validation across commit, build, test, and release. Practitioners should judge CI/CD security by control coverage, not by how many tools are installed.
CI/CD pipelines now carry non-human identity risk whether teams acknowledge it or not. Build runners, service accounts, tokens, and deployment credentials are operational identities, and they often outlive the task they are meant to support. That creates a governance boundary problem for IAM and PAM teams, because pipeline access has to be limited, revocable, and auditable at machine speed. Practitioners should treat pipeline identities as first-class assets.
Continuous assurance is the only model that matches modern delivery speed. Point-in-time security checks assume a stable target, but pipelines change too quickly for that assumption to hold. The more release automation increases, the more security has to move upstream and become event-driven. Practitioners should realign CI/CD security around continuous enforcement rather than end-stage review.
Secure delivery depends on the relationship between code integrity and access control. A pipeline that cannot prove which identity changed what, or that cannot limit the blast radius of a leaked token, is not operating under a defensible trust model. This is where CI/CD security intersects with identity governance in a direct way. Practitioners should make token scope, pipeline provenance, and revocation speed part of the same control conversation.
Pipeline controls are becoming part of resilience planning. When delivery systems can be used to introduce compromise, the issue is no longer only prevention but containment and recovery across the software factory itself. That means security leaders should review release governance alongside incident response and change control. Practitioners should expect CI/CD security to be measured as operational resilience, not just application hygiene.
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
CI/CD governance is converging with NHI control. The more delivery systems depend on service accounts, runners, and tokens, the more security leaders need to manage them as a distinct identity estate. That pushes pipeline access into the same conversation as lifecycle control, privilege scope, and revocation speed, especially where CI/CD runs at scale.
Pipeline identity sprawl is the hidden failure mode. If credentials are scattered across repositories, build tooling, and deployment orchestration, security teams lose the ability to reason about who or what can still act. The operational signal to watch is not just scan coverage, but whether each automated identity has a documented owner and a short exposure window.
Secure CI/CD will increasingly be judged on control placement, not tool count. Teams that keep relying on end-stage security gates will continue to find vulnerabilities after the most expensive point in the lifecycle. Practitioners should prepare for governance models that emphasise issuance-time control, pipeline provenance, and automated revocation rather than manual sign-off.
For practitioners
- Embed security checks at every pipeline stage Move from one-off scanning to automated checks at commit, build, test, and deploy so risk is evaluated where it appears.
- Inventory and scope pipeline identities List every service account, token, certificate, and runner credential used in delivery, then assign a clear owner and minimum required privilege.
- Shorten the lifetime of delivery credentials Replace long-lived pipeline secrets with tightly scoped, revocable credentials that expire as soon as the workflow step ends.
- Tie security gates to workflow events Trigger policy checks from pipeline actions such as merge, build, and release rather than from manual review cycles that lag behind delivery.
- Review pipeline trust after any third-party action change Reassess the access and secret exposure of build-integrated plugins, actions, and dependencies whenever a trusted component changes hands or behavior.
Key takeaways
- CI/CD security fails when teams rely on isolated scans instead of continuous controls across the delivery pipeline.
- The core governance issue is identity, because build and deployment systems depend on service credentials, tokens, and other non-human identities.
- Practitioners should embed checks earlier, scope pipeline access tightly, and tie revocation to workflow events rather than manual review cycles.
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 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | CI/CD tokens and runners often carry excess permissions across the delivery path. |
| NHI-07 — Long-Lived Secrets | The article warns against one-off controls, which leaves long-lived delivery secrets exposed. | |
| Recommendation — Audit pipeline identities for excess privilege and reduce each credential to the minimum release scope. Replace persistent pipeline secrets with short-lived credentials tied to the workflow step. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Pipeline secrets and tokens need lifecycle control, rotation, and revocation. |
| Recommendation — Apply authenticator lifecycle controls to rotate and revoke CI/CD credentials on a defined schedule. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centers on whether pipeline identities are properly scoped and controlled. |
| Recommendation — Review CI/CD entitlements regularly and remove permissions that exceed the workflow task. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Compromised pipeline credentials can be reused to move from build systems into downstream environments. |
| Recommendation — Map pipeline token abuse to credential access and lateral movement hunting in your detection logic. | ||
Key terms
- Build Pipeline Security: Build pipeline security is the practice of protecting the automation that compiles, tests, packages, and publishes software. It focuses on the scripts, workflow definitions, runners, secrets, and third-party actions that execute during build time, because compromise there can alter artifacts, expose credentials, or propagate malicious output downstream.
- Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.
- Shift-left security: Shift-left security means moving security checks and remediation earlier in the software delivery lifecycle, especially into development and pull request workflows. The goal is to surface issues when they are cheapest to fix and closest to the code change that introduced them.
- Shared Trust Boundary: A shared trust boundary is the point where multiple systems, teams, or identities rely on the same security controls and assumptions. It defines where trust is inherited rather than independently verified, so a weakness in one participant, credential, or control can affect others within that boundary.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect delivery pipeline controls to broader identity governance across modern environments.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org