Open source supply chain attacks are now a daily build risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on StepSecurity's research: 56 open source supply chain attacks in 12 months, with the cadence accelerating and CI/CD runners increasingly becoming the compromise point.

Why it matters: IAM, PAM, and CI/CD teams need to treat build-time identity, token scope, and runner egress as first-class controls because compromise is now happening before production deployment.

By the numbers:

• StepSecurity tracked 56 distinct supply chain attacks in 12 months.

Context

Open source supply chain attacks are no longer a downstream malware problem. They are a build-time identity problem, because poisoned packages, mutable tags, and compromised actions execute inside trusted automation before deployment controls can intervene.

This matters for IAM and CI/CD governance because the attacker often steals the credentials that make the pipeline itself trusted, including tokens, signing keys, cloud credentials, and repository access. In that model, the runner is not just infrastructure, it is a privileged identity surface.

The article’s baseline is typical of the current threat pattern: trusted components are being subverted after adoption, not merely blocked at intake, and that is why conventional production-focused scanning misses the point.

Key questions

Q: What breaks when malicious packages reach build pipelines unchecked?

A: Unchecked packages can execute before conventional controls inspect them, which means secrets, environment variables, and internal tokens can be exposed during install or runtime. Once those credentials are captured, attackers may pivot into CI, cloud services, or downstream tools. The failure is not just malware execution, but trust in package provenance without continuous validation.

Q: Why do trusted packages and actions create such a large supply chain risk?

A: Because attackers do not need to invent trust, they hijack existing trust. A maintainer account, mutable tag, or installed package already sits inside a privileged workflow, so malicious code inherits execution and secret access immediately. Once the attacker captures those credentials, the next compromise can be staged from inside the same ecosystem.

Q: How should security teams govern credentials used by CI/CD pipelines?

A: Security teams should treat CI/CD credentials as production-grade machine identities and apply least privilege, short lifetimes, and continuous monitoring. The key is to limit what the pipeline can reach, revoke secrets quickly, and audit every privilege path that could let one stolen token spread across repositories, cloud accounts, or SaaS systems.

Q: Should organisations treat package maintainers as privileged identities?

A: Yes. Maintainers can change what thousands of downstream systems execute, which is functionally privileged access. They should be governed with the same seriousness as other high-impact roles, including stronger authentication, tighter recovery controls, separation of duties, and rapid revocation when compromise is suspected.

Technical breakdown

Why malicious packages are different from vulnerable packages

A vulnerable package contains a defect that may be exploitable later. A malicious package is already the attack, because the harmful code runs as soon as the dependency is installed or executed in a build job. That distinction changes the control model: the relevant trust boundary is not production release, but package install, workflow execution, and runner memory. In supply chain attacks, adversaries seek credentials, tokens, and signing material that are already present in trusted automation, then pivot into repositories and registries. The important technical point is that the attacker does not need a long exploitation chain if the build pipeline itself is an execution environment with secrets loaded into memory.

Practical implication: Treat dependency installation and workflow execution as high-risk trust boundaries, not routine development activity.

How GitHub Actions and CI/CD runners become credential targets

GitHub Actions introduces three common attack paths. First, attackers compromise an Action maintainer and repoint mutable version tags to malicious code. Second, they poison a package that runs inside a job and harvest secrets from runner memory. Third, they use stolen developer credentials to plant workflows that execute across accessible repositories. In each case, the problem is identity propagation through automation: a trusted principal, tag, token, or workflow gains enough authority to execute and exfiltrate without needing a separate privilege escalation step. Runner egress controls matter because they can cut off the final theft step even after code execution has occurred.

Practical implication: Restrict tag mutability, minimise runner permissions, and block outbound exfiltration paths from build environments.

Why worms make supply chain attacks self-propagating

A worm in the software supply chain uses one compromised identity to generate the next compromise. If a maintainer token is stolen, the attacker can publish poisoned packages that reach downstream maintainers, whose credentials are then reused to continue the chain. This is what makes recent campaigns more dangerous than isolated package compromises. The blast radius expands through trust relationships already embedded in open source ecosystems, CI/CD secrets, and repository permissions. The technical failure is not just compromise of one artifact, but reuse of the same identity and publishing path across many artifacts and ecosystems.

Practical implication: Assume a single maintainer compromise can become an ecosystem event unless publishing and signing authority are tightly segmented.

Threat narrative

Attacker objective: Steal trusted build-time credentials and use them to extend compromise across repositories, packages, and CI/CD pipelines.

1. Entry begins with compromise of a trusted package, GitHub Action, or maintainer account, rather than with direct intrusion into production systems.
2. Credential harvesting occurs when the malicious code runs in a developer machine or CI/CD runner and captures tokens, cloud keys, or signing secrets loaded into memory.
3. Escalation follows when stolen credentials are reused to publish new poisoned packages, repoint tags, or plant workflows across other repositories and ecosystems.
4. Impact is build-system compromise at scale, with secrets theft, malware propagation, and downstream repository or release contamination.

Breaches seen in the wild

• 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).
• HashiCorp GPG key exposure 2021: Codecov's poisoned Bash Uploader exposed the GPG key HashiCorp used to sign download checksums; HashiCorp rotated it and re-signed its releases.

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

Build-time identity has become the real control plane: supply chain attackers increasingly target the identities trusted by pipelines, not the applications those pipelines eventually produce. When package maintainers, GitHub Actions tags, or runner tokens are the access path, the decisive question is who can execute inside automation and what secrets are already present there. Practitioners should treat CI/CD identity as production-grade privilege, not development convenience.

Self-propagating compromise is now a governance problem, not just an incident problem: worms in open source ecosystems convert one stolen token into repeated publishing authority across many packages and repositories. That means lifecycle controls around publishing rights, tag immutability, and maintainer offboarding now matter as much as malware detection. The named concept here is pipeline identity propagation: when one trusted automation identity can seed the next compromise. Practitioners need controls that break the reuse chain.

Secrets exposure is the operational failure mode that keeps repeating: the report’s most damaging cases are not exotic zero-days, but routine build environments that load cloud keys, signing keys, and repository tokens by default. That is a standing-credential problem in an automation context, and it exposes the weakness of assuming credentials are safe just because they are short-lived or machine-scoped. Practitioners should shift from after-the-fact secret review to issuance-time containment and runner-level exfiltration resistance.

Mutable trust objects are an attack surface in their own right: GitHub Action tags, package versions, and workflow files become delivery mechanisms when their ownership or reference integrity is weak. The issue is not only package security, but identity and provenance of the publishing path itself. Teams should consider tag repointing, repository access, and signing workflows as part of the same governance domain, because attackers exploit whichever trusted reference is easiest to rewrite.

CI/CD threat modelling now belongs inside identity governance: the report shows that build systems are carrying the same privilege density that used to be reserved for administrators. That means IAM, PAM, and CI/CD owners have to align on token scope, repository trust, and runner containment as one control family. Practitioners should treat every build principal as a non-human identity with a lifecycle, a purpose, and an offboarding requirement.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Pipeline identity propagation: once an attacker steals a maintainer token or runner credential, the compromise can spread through publishing rights, workflow execution, and downstream trust chains. That makes build-time identity a governance boundary rather than a developer convenience, and it should be managed as a non-human identity lifecycle with scope, ownership, and offboarding controls.

Runner egress is now a containment control: malicious packages often succeed because the build environment can both execute code and reach the internet with secrets in memory. Containing outbound traffic from CI/CD runners turns an otherwise invisible secret theft into a blocked event, especially when attackers rely on exfiltration after initial execution.

Open source ecosystems are now a repeatable attack surface, not an edge case, so teams should expect tag repointing, poisoned packages, and workflow tampering to recur across multiple build systems. The practical response is to align IAM, PAM, and pipeline governance so the same secret cannot authorise publishing, administration, and routine builds.

For practitioners

• Lock down build-time token scope Issue the minimum permissions needed for runners, actions, and publishing accounts, and separate read, write, and release paths so stolen credentials cannot pivot across environments.
• Make GitHub Action tags and package versions immutable Pin dependencies and workflows to commit SHAs or trusted release artefacts, and reject mutable references that let a maintainer compromise retarget existing workflows.
• Block outbound exfiltration from CI/CD runners Apply egress controls so malicious code cannot ship secrets to attacker-controlled endpoints after it executes inside the pipeline.
• Separate publishing identities from routine build identities Use distinct credentials for package publication, repository administration, and normal build execution so one compromise cannot contaminate the full release path.
• Monitor for workflow and tag tampering Alert on tag repointing, unexpected workflow creation, and repository changes that introduce new automation paths into already trusted projects.

Key takeaways

• Open source supply chain attacks now routinely exploit the identities trusted by build systems, not just the software those systems produce.
• StepSecurity’s data shows the pace reached roughly one attack every three days, which means the threat is operational and continuous rather than sporadic.
• The limiting control is build-time governance over secrets, runner egress, and publishing privileges, because malicious code often wins before production ever sees it.

Key terms

• Malicious Package: A malicious package is software published into a legitimate repository but designed to execute harmful code when installed. It abuses normal dependency workflows so that the attacker’s code reaches the environment through trust in the package ecosystem, not through a traditional exploit.
• Mutable Tag: A mutable tag is a repository reference that can be moved to a different commit after it has been published. In software supply chains, mutable tags are risky because they let an attacker or compromised maintainer change what future builds and workflows execute without changing the calling configuration.
• CI/CD runner: A CI/CD runner is the execution environment that performs build, test, or deployment jobs. It often has access to source code, tokens, and cloud credentials, which makes it a high-value identity surface when workflows are compromised.
• Build-time identity: Build-time identity is the set of service accounts, tokens, and permissions used by CI/CD systems, testing tools, and deployment automation. It matters because these identities often carry production access and can turn development speed into an access-control problem if they are over-privileged or poorly governed.

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course covers NHI governance, machine identity security, and secrets management in practical terms, with emphasis on how build-time identities should be controlled. It is designed for practitioners who need to connect identity governance to operational security decisions across modern environments.