Supply chain attacks are accelerating across CI, packages and AI tools

At a glance

What this is: Boost Security's analysis argues that package ecosystems, CI workflows and developer tooling are being abused in faster, more coordinated supply chain attacks.

Why it matters: For IAM, PAM and NHI practitioners, the important issue is that compromised developer accounts, tokens and pipeline secrets now function as reusable access paths into the software factory.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• 17 minutes.

👉 Read Boost Security's analysis of recent supply chain attacks across npm, PyPI and CI

Context

Supply chain security breaks when attackers can move from initial compromise to code publication or secret theft faster than teams can validate provenance, revoke access and contain the blast radius. In this article, Boost Security focuses on recent attacks across npm, PyPI, CI workflows and developer tooling, where the security gap is less about a single vulnerable package and more about the trust relationships around it.

The identity angle is real and increasingly central. Developer accounts, npm tokens, GitHub workflows, API keys and CI credentials are all non-human identities in practice, even when teams do not govern them that way. That makes this a governance problem for IAM, PAM and NHI programmes as much as a software supply chain problem.

Key questions

Q: What breaks when supply chain attacks can steal secrets as well as publish malware?

A: The biggest failure is that code compromise turns into identity compromise. Once attackers steal CI secrets, package tokens or developer credentials, they can continue accessing systems even after the malicious package is removed. That means incident response must focus on revocation, rotation and release containment, not only on deleting the bad artifact.

Q: Why do package ecosystem attacks create such large blast radius risk?

A: Because one trusted publishing identity can reach many downstream teams through normal dependency updates. If that identity is compromised, the attacker inherits the distribution channel and can spread malicious code or harvest secrets at scale. The more automation and reuse a pipeline has, the larger the eventual impact becomes.

Q: What do security teams get wrong about CI secrets in supply chain incidents?

A: They often treat CI secrets as temporary configuration rather than durable access. In practice, tokens in workflows or runners can be reused across repositories and services, so a single leak can expose multiple environments. Teams need lifecycle ownership, scope limits and rapid rotation for every credential used by automation.

Q: How should organisations respond when a developer account or workflow is compromised?

A: Contain publication paths first, then rotate every token and credential that the account or workflow could have reached. Review package signing, branch protections and runner permissions before resuming releases. The key is to assume secondary theft has already happened, because supply chain attackers frequently use one compromise to seed others.

Technical breakdown

How package ecosystem attacks turn trusted updates into delivery channels

Package ecosystems are attractive because they concentrate trust in a small number of publishing accounts and automated update paths. An attacker who compromises a maintainer account, CI workflow or build pipeline can inject malicious code into a package that downstream teams install as part of normal development. The issue is not only malware. It is the trust model itself, where code, credentials and automation are tightly coupled and often insufficiently segmented.

Practical implication: teams need stronger publishing controls, provenance checks and release separation before code reaches install paths.

Why secrets and tokens become the real payload in supply chain incidents

Many supply chain attacks now treat secrets as the primary objective rather than the only side effect. API keys, npm tokens, GitHub credentials and cloud access tokens can be harvested from local machines, workflows or repositories and then reused for further compromise. This is why NHI governance matters here: a token is an identity with authority, and if it lacks lifecycle control, the compromise can continue well beyond the original incident.

Practical implication: inventory and classify developer and pipeline secrets as governable identities, not just configuration data.

How self-propagating malware amplifies blast radius across ecosystems

Self-propagating supply chain malware changes the risk profile because the attacker does not need to repeat the initial compromise manually. Once a malicious package or workflow lands in one trusted location, it can search for more tokens, publish to more repositories or exfiltrate from more workflows. That creates a compounding propagation effect that overwhelms teams relying only on reactive detection after publication.

Practical implication: detection must cover package publishing behaviour, workflow mutation and token reuse across repositories.

Threat narrative

Attacker objective: The attacker wants persistent trust abuse across the software factory, using code distribution and credential theft to expand access and steal data or control downstream environments.

1. Entry begins with compromise of a developer account, vulnerable CI workflow or exposed credential in the software supply chain.
2. Escalation occurs when the attacker uses that trust to publish malicious packages, alter workflows or harvest additional secrets and tokens.
3. Impact follows when the malicious code, stolen credentials or propagated workflow reaches downstream users, repositories or AI-assisted tooling at scale.

NHI Mgmt Group analysis

Supply chain compromise is now an identity governance problem, not just a code integrity problem. The attacks described here rely on abused maintainer accounts, tokens and CI credentials, which are non-human identities with delegated authority. Once those identities are treated as operationally important, the control question changes from package scanning alone to lifecycle control, least privilege and revocation discipline across the software factory. Practitioners should govern publishing identities with the same seriousness as production service accounts.

Secret theft is the most durable failure mode because it outlives the original incident. A malicious package can be removed, but a copied token or workflow credential may remain valid across repos, cloud services or developer tools. This creates a standing-access problem that looks operationally small at entry and strategically large at impact. Teams should assume every leaked secret is a future access path until it is rotated and scoped down.

Self-propagating malware marks a new level of supply chain blast radius. When malicious code can search for more secrets and spread to other packages, the attacker is no longer dependent on a single compromise window. That makes package provenance, CI segregation and automated secret discovery part of the same defensive model. The practical conclusion is simple: if propagation is possible, containment must happen before publication.

AI-assisted development increases the attack surface by widening the number of trusted execution paths. The article notes payloads that look for AI CLI tools and abuse them, which means the software factory now includes AI tooling as a runtime trust domain. That introduces a named concept worth tracking: software-factory identity sprawl: the accumulation of developer, pipeline, package and AI-tool identities without unified governance. Practitioners should treat every new automation path as an identity boundary.

Blast radius is becoming the defining metric for supply chain defence. The article's repeated theme is that attacker sophistication is increasing and defenders are catching only the incidents they can see quickly. That means the meaningful question is not whether compromise is possible, but how far one compromised identity, token or workflow can travel before containment. Security teams should prioritise segmentation, short-lived credentials and release controls that limit propagation.

What this signals

Supply chain teams should expect identity governance to move closer to the build system. The practical pressure point is not only malware detection but the control of publishing identities, runner secrets and delegated access paths that let one compromise travel across repositories and environments.

Software-factory identity sprawl: the growing mix of developer, CI, package and AI-tool identities creates a governance problem that traditional appsec tooling does not resolve on its own. Teams should align publishing permissions, secret lifecycle controls and provenance checks across OWASP Non-Human Identity Top 10 guidance and package provenance controls.

The next stage of defence will be faster containment of leaked credentials, not just faster detection of malicious packages. If a workflow or package compromise is discovered late, the question becomes whether teams can revoke every related token before reuse spreads into other systems.

For practitioners

• Treat developer and pipeline credentials as governed identities Map npm tokens, GitHub workflow credentials, CI secrets and cloud keys into the same inventory so ownership, expiry and revocation are explicit. Use the NHI lifecycle view to force accountability for who can mint, rotate and retire each credential.
• Separate build trust from publish trust Require stronger controls on release workflows than on ordinary build execution, including protected signing steps, branch protections and restricted package publishing permissions. This reduces the chance that a compromised CI job can turn into a malicious release.
• Add secret discovery before and after publication Scan repositories, workflows and published artifacts for secrets before release, then repeat scanning after release when packages are updated or mirrored. Pair that with immediate rotation so leaked tokens cannot remain usable for the average 27-day remediation window described in adjacent secrets research.
• Constrain propagation paths in CI and package ecosystems Limit which runners, workflows and package identities can interact, and isolate high-risk automation from broad repository access. This reduces the chance that one compromised workflow can spread through multiple packages or repos.
• Use incident playbooks that assume secret reuse When a package or workflow compromise is detected, assume the attacker already harvested secondary secrets and tokens. Rotate credentials first, then review publishing permissions and downstream dependencies before restoring normal release operations.

Key takeaways

• Supply chain attacks are now exploiting trusted identities in CI, package publishing and AI-assisted tooling, which makes the problem as much about governance as code security.
• The evidence points to compounding blast radius, where stolen secrets, compromised workflows and malicious packages reinforce one another across ecosystems.
• Practitioners should manage developer and pipeline credentials as non-human identities, with lifecycle control, provenance checks and rapid revocation as core controls.

Key terms

• Software Identity Sprawl: Software identity sprawl is the uncontrolled growth of non-human identities inside development and delivery pipelines, including service accounts, tokens, keys, and tool credentials. It increases the number of trust relationships that must be governed, rotated, and revoked across the software lifecycle.
• Trusted Publishing: Trusted publishing is a release method that ties package publication to a verified CI workflow, usually with short-lived identity tokens and provenance evidence. It reduces the value of stolen legacy credentials, but only if older publish paths are fully removed and not left alongside the new flow.
• Secret Reuse: Secret reuse is the practice of using the same password, token, or credential across multiple systems or functions. It multiplies the impact of any single dump because one compromised secret can authenticate to several environments, creating a much larger blast radius.
• 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.

What's in the full article

Boost Security's full blog post covers the operational detail this post intentionally leaves for the source:

• Attack-by-attack breakdowns of the recent Nx, Qix, Shai-Hulud and GhostAction incidents and how each one was executed
• Examples of advanced detection techniques used to spot malicious package behaviour before it reaches runners
• Discussion of ecosystem hardening features such as minimum release age in package tooling
• References to the author's attack trees, open source scanners and incident-response tooling for supply chain security

👉 Boost Security's full post covers the attack patterns, detection themes and defensive responses in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management for practitioners responsible for access and lifecycle control. It helps identity and security teams apply governance discipline to the credentials and automation that run modern software delivery.