Pipeline parasitism shows why CI/CD now needs production-grade controls

At a glance

What this is: This is an analysis of 2025 supply chain attacks that reused ordinary CI/CD weaknesses, maintainer trust, and exposed secrets rather than relying on exotic new vulnerabilities.

Why it matters: It matters because identity and access controls around pipelines, maintainer accounts, tokens, and developer endpoints now determine how far one compromised workflow can spread across software delivery.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Boost Security's analysis of pipeline parasitism in 2025 supply chain attacks

Context

Supply chain compromise becomes more dangerous when attackers can reuse the same CI/CD and secrets-management weaknesses defenders have already documented. In this pattern, the control failure is not a single broken product but a governance model that lets untrusted code, over-privileged tokens, and maintainer trust sit too close together in the delivery path.

The article focuses on pipeline parasitism, a term for attacks that live off legitimate build and release machinery rather than replacing it. That creates a real identity bridge for NHIMG readers because the attack surface includes maintainer accounts, service tokens, secrets, and developer endpoints, all of which are identity-bearing assets in software delivery.

The starting position described here is unfortunately typical for modern software ecosystems, not exceptional. Many teams still separate application security, IAM, and developer tooling governance, even though the compromise path increasingly crosses all three.

Key questions

Q: What breaks when CI/CD workflows can run untrusted code with privileged tokens?

A: The trust boundary breaks. Once untrusted code runs with repository secrets or a write-capable token, attackers can steal credentials, alter branches, poison packages, or persist through workflow changes. At that point, the pipeline becomes a supply chain entry point rather than a control point.

Q: Why do maintainer accounts become high-value targets in software supply chains?

A: Because one maintainer identity often controls publishing rights, package metadata, and downstream trust. If that account is compromised, attackers can push malicious updates through legitimate channels without needing a fresh exploit. Phishing-resistant authentication, delegated access review, and rapid revocation are the controls that limit that blast radius.

Q: How do security teams know whether secrets in CI/CD are actually controlled?

A: Look for three signals: how many secrets a workflow can reach, how long those secrets remain valid, and whether any of them can publish or sign artefacts. If a build job can touch long-lived credentials or production systems, the environment is not controlled. The objective is to reduce reachable secrets and shorten exposure windows.

Q: Who is accountable when a compromised pipeline publishes malicious packages?

A: Accountability usually sits with the organisation that issued the publishing credential, maintained the pipeline trust boundary, and failed to constrain release authority. In practice, this is an IAM, DevSecOps, and platform governance issue together, not a developer-only mistake.

Technical breakdown

Why pull_request_target workflows create an access boundary problem

GitHub Actions workflows that use pull_request_target run in the context of the target repository, not the contributor’s fork. That matters because attacker-controlled input can reach shell execution while privileged secrets are already available to the job. The failure mode is a broken trust boundary: code review assumes a pull request is inert, but the workflow turns it into executable production logic. Once shell interpolation, unsanitised branch names, or comments reach the runner, the workflow can leak tokens, modify releases, or invoke downstream systems with legitimate privileges.

Practical implication: Separate untrusted pull request validation from trusted release workflows, and treat any secret-bearing runner as production scope.

Why maintainer account compromise becomes a transitive supply chain event

When attackers take over a maintainer account, they do not need to invent a new exploit path. They inherit the package, the publishing rights, the trust of downstream consumers, and often the automation that republishes updates. That makes account takeover a transitive compromise: one identity breach becomes many consumers’ problem. In practice, signed releases, package metadata, and dependency trust all collapse if the identity that controls them is not strongly bound to phishing-resistant authentication and lifecycle monitoring.

Practical implication: Anchor package publishing to phishing-resistant MFA and monitored access policies, not just passwords or shared recovery paths.

How secret exfiltration turns developer tooling into an attack multiplier

Secrets in CI/CD are not static configuration values. They are credentials that can open registries, cloud accounts, package managers, and support systems, often across multiple environments. Once harvested, they extend the attacker’s reach beyond the original workflow into broader infrastructure. This is why pipeline attacks so often become secret theft campaigns: the valuable target is not the build itself but the credentials the build can touch. The operational risk rises sharply when secrets are long-lived, reused across services, or exposed to tooling that was never meant to handle them.

Practical implication: Classify build-time secrets by blast radius and remove anything from CI that does not need to exist there.

Threat narrative

Attacker objective: The attacker aims to convert trusted software delivery machinery into a distribution and credential-theft channel that reaches downstream users at ecosystem scale.

1. Entry occurs through a CI/CD foothold such as a vulnerable pull request workflow, a compromised maintainer account, or a poisoned release path.
2. Credential access follows when the workflow exposes tokens, package publishing rights, or cloud secrets that can be reused outside the original pipeline.
3. Escalation happens as those credentials are used to publish malicious artifacts, pivot into downstream systems, or widen compromise across ecosystem consumers.

NHI Mgmt Group analysis

Pipeline parasitism is the right name for a control failure, not just a family of attacks. The article shows that attackers are no longer limited to finding novel software bugs. They are chaining ordinary CI/CD trust, maintainer access, and secret handling into a repeatable compromise path. That makes the real governance problem identity-bearing pipeline assets that were never scoped as production systems. Practitioners should treat release pipelines as high-value access environments, not developer convenience.

CI/CD now exposes a privilege concentration problem that IAM teams cannot ignore. A workflow runner with access to signing keys, package registries, and cloud tokens is acting like a privileged service account with a short attention span. The governance gap is not just overprivilege. It is the lack of lifecycle control over ephemeral machine access that can still reach durable infrastructure. Security teams should map pipeline identities into the same governance model used for NHI and PAM.

Maintainer compromise is becoming the software supply chain equivalent of account takeover fraud. The attacker does not need to own the code base if they can own the person or service that publishes it. That pattern belongs in identity governance discussions because the identity is the control plane. The practitioner conclusion is simple: if publishing rights are not bound to strong authentication, monitored delegation, and rapid revocation, the package ecosystem remains exposed.

Secret sprawl and release automation create a shared blast-radius problem across development and security teams. The article’s examples show that one compromised workflow often reaches cloud accounts, package registries, and developer endpoints simultaneously. That is why secrets management, endpoint hardening, and pipeline isolation must be governed as one system. The field needs to move from point fixes to blast-radius control, because attackers are already doing that math.

What this signals

Pipeline attacks now blur the line between application security and identity governance. When a workflow can impersonate a release process, the control problem is no longer just code integrity. It is whether the organisation can prove which identity was allowed to publish, for how long, and under what conditions.

Pipeline identity drift: this is the point at which build automation accumulates privileges faster than governance teams can document them. The practical signal is simple: if your CI jobs can reach secrets, registries, and cloud accounts, you are already managing machine identities and should govern them accordingly.

The broader trend is that software delivery now behaves like a high-speed credential environment. That makes secrets lifecycle, maintainer authentication, and runner isolation core resilience issues, not niche engineering concerns.

For practitioners

• Separate untrusted and trusted pipeline paths Run forked pull requests in isolated validation workflows that cannot reach signing keys, publishing tokens, or production cloud credentials. Keep release jobs on protected branches only, with manual promotion or policy gates where feasible.
• Reduce maintainer account takeover exposure Require phishing-resistant MFA for package maintainers, disable weak recovery methods, and review delegated access to registries and source control with the same rigor used for privileged production accounts.
• Inventory secrets reachable from CI/CD jobs Document every token, key, certificate, and registry credential that a workflow can access, then remove anything that is not needed for that job. Prioritise secrets that can open cloud control planes or publish artefacts.
• Instrument pipelines with canaries and anomaly detection Use decoy credentials, publish-time alerts, and runner telemetry to detect when a workflow touches a secret or executes unexpected shell behaviour. Make exfiltration visible before the attacker reaches downstream systems.
• Review developer endpoint exposure as part of supply chain defence Protect IDEs, browser sessions, and extension ecosystems used by maintainers and release engineers, because those endpoints increasingly host the credentials and tokens attackers target before they ever touch the build.

Key takeaways

• 2025 supply chain attacks succeeded by reusing the ordinary trust paths built into CI/CD, maintainer access, and secrets handling.
• The evidence points to a governance problem: one compromised workflow or account can propagate into package publishing, cloud access, and downstream consumer impact.
• Teams need to treat pipelines as privileged production systems, with isolated trust boundaries, tighter secret scope, and stronger maintainer authentication.

Key terms

• Pipeline Parasitism: A supply chain attack pattern in which adversaries live off legitimate CI/CD, maintainer, and release processes rather than replacing them. The attacker reuses trusted workflows, accounts, and tokens so malicious activity blends into normal software delivery.
• Pwn Request: A pull request or related contribution flow that can execute attacker-controlled content in a privileged build context. The risk appears when workflow design lets untrusted input reach shell commands, secrets, or release tooling without a clean trust boundary.
• Maintainer Account Takeover: A compromise in which an attacker gains control of a software maintainer’s publishing identity. In package ecosystems, that can be enough to replace legitimate releases with malicious ones, making the account itself a production-grade access path rather than a simple administrative login.
• Secrets blast radius: Secrets blast radius is the amount of access exposed when a single credential is compromised or over-shared. It depends on privilege scope, reuse, export rights, and downstream trust relationships, not just on whether the secret was stored securely.

What's in the full article

Boost Security's full article covers the incident detail and campaign-by-campaign mechanics this analysis intentionally leaves at the pattern level:

• Forensic breakdowns of the Ultralytics, Kong, tj-actions, GhostAction, Nx, GlassWorm, and Shai-Hulud cases
• The research and tooling references the article used to detect pwn requests and workflow abuse in practice
• Specific attacker tradecraft, including shell injection, maintainer compromise, worm behaviour, and blockchain-based command channels
• The operational sequence behind each campaign, useful if you are building detections or post-incident triage

👉 Boost Security's full article covers the breach sequence, tooling references, and case-by-case attack mechanics.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps security practitioners connect access control, lifecycle discipline, and governance across the systems that now carry release privilege.