Supply Chain Replication

A supply chain attack pattern in which one compromised trusted component is used to create additional infected artefacts automatically. In package ecosystems, republishing rights, workflow access, or build automation can turn a single incident into broad propagation across downstream consumers.

Expanded Definition

Supply chain replication describes a propagation pattern where a trusted component is compromised once, then used to generate further malicious artefacts automatically. In NHI security, that trusted component is often a package publisher token, CI/CD runner credential, workflow secret, or build automation identity. The risk is not only initial compromise but the speed at which signed releases, republished packages, or templated build outputs can multiply downstream exposure.

Usage in the industry is still evolving because teams sometimes label any package compromise as a supply chain issue, even when there is no automatic secondary spread. A stricter reading focuses on repeatable propagation through legitimate release paths, which is why controls discussed in the OWASP Non-Human Identity Top 10 matter here: the identity used to build, publish, or sign artefacts becomes the vehicle of spread. The most common misapplication is treating a single leaked token as an isolated incident, which occurs when teams do not inspect whether the compromised identity can republish, trigger workflows, or mint additional artefacts.

Examples and Use Cases

Implementing controls against supply chain replication rigorously often introduces release friction, requiring organisations to weigh deployment speed against the cost of tighter publisher verification and build isolation.

• A compromised npm publisher token is used to publish a poisoned version, then a downstream automation job republishes the same artifact into internal mirrors.
• A CI/CD runner credential is abused to modify build scripts, causing each subsequent build to embed secrets or backdoors until the pipeline is rebuilt.
• An attacker who steals a GitHub Actions secret uses it to trigger authenticated workflows across multiple repositories, creating repeated artefact generation from one foothold. See NHIMG’s Reviewdog GitHub Action supply chain attack for a real-world pattern.
• A package maintainer’s access is hijacked and the attacker pushes a malicious release that is automatically accepted by consumers using broad version ranges, amplifying distribution.
• For broader context on self-propagating behaviour, NHIMG’s Miasma and Hades Supply Chain Worms shows how trusted automation can become the propagation layer.

Why It Matters in NHI Security

Supply chain replication is a governance problem because one compromised non-human identity can cascade across repositories, registries, and build systems faster than human responders can manually contain it. NHIMG research shows that 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, underscoring how automation identities are now high-value propagation points. The same pattern appears when secrets spread beyond code, because artefacts are often rebuilt, mirrored, and promoted by systems that assume trust rather than verify it.

This is where identity controls, secret rotation, and provenance enforcement intersect. If a publishing token, signing key, or workflow credential can be reused without step-up checks, the blast radius expands with every automated action. The NHI lesson from incidents such as the LiteLLM PyPI package breach and the Shai Hulud npm malware campaign is that distribution mechanics matter as much as the first compromise. Organisations typically encounter the replication impact only after downstream consumers begin receiving tainted artefacts, at which point supply chain replication becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is supply chain amplification in Agentic AI security?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• When should organisations rotate credentials after a supply chain incident?
• How should security teams reduce the risk of secret theft from npm supply chain attacks?