TL;DR: Attackers are increasingly reaching production through upstream dependencies, CI/CD pipelines, and compromised credentials, with compromises propagating automatically across many organisations and exploiting secret leakage in minutes, according to Orca Security. The practical shift is clear: pipeline security now depends on continuous iteration, identity control, and machine-speed response, not periodic review.
At a glance
What this is: This session argues that upstream dependencies and CI/CD systems have become part of the real enterprise perimeter because attackers can exploit them faster than traditional review cycles can respond.
Why it matters: IAM and security teams need to treat pipeline identities, tokens, and third-party trust as production controls, because compromise now scales through delivery paths rather than only through runtime systems.
Context
Upstream CI/CD risk describes the security exposure that sits before code reaches production, including third-party packages, build systems, automation tokens, and pipeline-linked service accounts. The governance gap is that many security programmes still separate software delivery from production trust, even though the pipeline now shapes what gets executed, signed, and promoted.
This article shows why that separation is breaking down. When dependencies, GitHub Actions, MCPs, and AI-assisted workflows can all touch the same delivery path, identity becomes the control plane for build integrity as much as for runtime access.
Key questions
Q: What breaks when CI/CD pipelines are treated as non-production systems?
A: Teams miss that pipelines can authenticate, sign, deploy, and propagate trust into production. When build infrastructure is excluded from perimeter thinking, attackers can abuse tokens, runners, and upstream dependencies to reach systems that were never meant to be directly exposed. The result is a control gap between development convenience and production risk.
Q: Why do CI/CD systems increase the impact of compromised credentials?
A: CI/CD systems often hold powerful secrets that can unlock source code, deployment pipelines, cloud environments, and internal services. That concentration makes them attractive to attackers, because one exposed credential can provide broad downstream access. The risk grows further when secrets are long-lived, reused across systems, or not tightly monitored for unexpected use.
Q: What signs show that pipeline identity controls are failing?
A: Look for shared service roles, long-lived tokens, secrets stored outside a managed vault, and runner behaviour that does not match the declared build task. If credentials can be reused across jobs or environments without clear expiry, the pipeline is already operating with excessive trust and weak containment.
Q: Should security teams prioritise pipeline identity controls over more vulnerability scanning?
A: They should treat them as complementary, but pipeline identity controls usually deliver faster risk reduction because many recent compromises succeed through legitimate credentials rather than pure software flaws. Scanning still matters, but it does not stop an attacker who already has a valid token or service role.
Technical breakdown
Why upstream dependencies behave like part of production
Upstream dependencies are no longer just software inputs. They are executable trust relationships that can introduce code, permissions, and workflow logic into the pipeline before any runtime control has a chance to inspect them. In practice, that means package ecosystems, action runners, and build services operate as part of the extended production environment. Once attackers compromise one upstream component, the blast radius is not limited to a single repository. It can propagate through downstream consumption, automated builds, and signed releases across many organisations.
Practical implication: Treat dependency ingestion and pipeline execution as governed production paths, not separate development convenience layers.
Why CI/CD credentials are the fastest route to impact
CI/CD environments concentrate high-value credentials because they need to authenticate to registries, cloud services, repositories, and deployment targets. When those secrets are long-lived or widely scoped, they become a reliable pivot point from a build compromise into broader identity abuse. The article’s examples point to a familiar pattern: a token, auth key, or service role is exposed, then reused to access systems that were assumed to be isolated. That is why credential hygiene matters more here than in many other control planes.
Practical implication: Map every pipeline credential to its effective blast radius and remove standing access that is broader than the build task requires.
How AI changes the defensive operating model in pipelines
AI does not remove the need for controls in build security. It changes the pace and volume of analysis defenders can perform, especially when teams are small and change rates are high. The useful pattern is not full autonomy by default, but targeted automation that can review, detect, and triage with machine speed. The article also implies that human review alone does not scale to large pull requests or rapidly changing dependency graphs. In that environment, AI becomes a control amplifier, not a control substitute.
Practical implication: Use AI to accelerate detection and policy checks, but keep explicit guardrails around what automation can approve or deploy.
Threat narrative
Attacker objective: The attacker wants to turn trusted delivery infrastructure into a scalable entry point for production access, credential theft, and downstream compromise.
- Entry occurs through an upstream dependency, build tool, or CI/CD surface that developers trust and consume automatically.
- Credential access follows when attackers harvest tokens, auth secrets, or service roles from the compromised pipeline.
- Escalation and lateral movement happen as those credentials are reused to reach production systems, cloud services, or downstream consumers.
- Impact is broad compromise at scale, including secret exposure, automated propagation, and production access through legitimate trust paths.
Breaches seen in the wild
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
- CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
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
Upstream CI/CD risk is now a trust-governance problem, not just a tooling problem. Once the delivery pipeline becomes part of the production perimeter, security teams have to govern what enters the build path, who can alter it, and how quickly trust can be withdrawn. The old split between software supply chain risk and identity governance no longer holds. Practitioners should model the pipeline as an access system with its own policy and blast-radius controls.
Pipeline credentials are a standing-privilege problem in disguise. The article’s core pattern is not novel malware, but the repeated abuse of tokens, service roles, and automation auth. That is a governance failure around identity scope, rotation, and offboarding. Security teams should treat build-time credentials as high-value NHIs and challenge any design that assumes they are safe because they are “just for CI.”
Machine-speed compromise forces machine-speed defence. If exploitation can move from introduction to credential exfiltration in minutes, then alerting plus human triage is too slow as a primary control. That does not justify handing over full autonomy, but it does require automated detection, policy enforcement, and constrained response paths. The practitioner conclusion is clear: the control objective has shifted from review to containment.
AI in the pipeline widens the governance surface as much as it improves productivity. Multiple automation layers, including AI agents and MCP-style tool access, can amplify both delivery speed and the consequences of weak identity controls. The challenge is not whether to use AI, but where to bound its authority. Teams should assume every new automation layer inherits the same trust and privilege questions as the code it touches.
Secret sprawl is the named concept this article sharpens. The security problem is no longer only exposed credentials in one place, but credentials distributed across code, pipeline tools, runners, and third-party integrations. That makes discovery, scoping, and revocation a continuous governance duty. Practitioners should baseline where secrets live before trying to optimise how fast they rotate.
From our research library:
- 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.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Secret sprawl is now a pipeline governance issue. When secrets are stored in code, config files, and CI/CD tools, the control problem shifts from hiding credentials to governing where they can be used and how quickly they can be revoked. That matters because the delivery path is now part of the trust boundary, not an administrative afterthought. according to the Ultimate Guide to NHIs
The practical signal for security teams is to baseline pipeline-authenticated access as a first-class identity estate and to assume that upstream compromise can reach production through legitimate automation. That pushes governance toward continuous inventory, narrower credentials, and stronger offboarding for machine identities and third-party trust paths.
For practitioners
- Define the pipeline as production perimeter Map repositories, build runners, actions, package sources, and deployment jobs into one governed trust boundary with named owners.
- Inventory and scope every CI/CD credential Catalogue tokens, auth keys, service roles, and machine identities, then record which systems each can reach and whether the scope is still necessary.
- Shorten credential lifetime and narrow blast radius Replace broad, persistent pipeline access with task-scoped permissions and remove any shared role pattern that can reach thousands of workloads.
- Automate detection for upstream compromise signals Monitor dependency changes, runner behaviour, secret access, and unusual pipeline authentication so compromise is caught before downstream promotion.
- Use AI as a control amplifier, not a sole reviewer Deploy automated checks for pull requests, dependency integrity, and policy drift, but keep approval paths constrained to specific, auditable conditions.
Key takeaways
- The article frames upstream delivery systems as an enterprise trust boundary because attackers can reach production by compromising dependencies, runners, and automation credentials.
- The core evidence is not a single flaw but a repeatable pattern of secret exposure, shared roles, and propagation through trusted build paths.
- The strongest control response is to govern pipeline identities as production identities, with tighter scope, faster revocation, and machine-speed monitoring.
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 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 leaked pipeline secrets and credentials in CI/CD tooling. |
| NHI-05 — Overprivileged NHI | Shared roles and broad automation credentials create excessive machine privilege. | |
| NHI-07 — Long-Lived Secrets | The article highlights persistent auth tokens and weak rotation as core failure modes. | |
| Recommendation — Scan build paths for exposed secrets and revoke any leaked pipeline credential immediately. Reduce pipeline and service-role scope so CI/CD identities only reach the resources they must use. Replace long-lived pipeline secrets with short-lived credentials and enforce expiry by default. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The attack pattern relies on stealing credentials and reusing them across systems. |
| Recommendation — Map pipeline compromise paths to credential access and lateral movement to improve detection coverage. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | CI/CD trust depends on precise entitlements for tokens, service accounts, and runners. |
| Recommendation — Review pipeline entitlements under PR.AA-05 and remove standing access that exceeds build task needs. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article’s risk centers on unmanaged machine accounts and shared auth paths. |
| Recommendation — Apply account management discipline to pipeline identities, including inventory, ownership, and timely deprovisioning. | ||
Key terms
- Upstream Dependency: An upstream dependency is any package, action, image, or external component that a software delivery process consumes automatically before runtime. If that component is compromised, the trust it inherits can become an attack path into production systems.
- 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.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
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 gives practitioners a practical base for connecting identity control to modern delivery and automation risk.
Published by the NHIMG editorial team on July 9, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org