They spread because the attacker is exploiting shared trust in the maintainer and build process, not a single registry. If the same identity, workflow, or release automation can affect multiple ecosystems, one compromise can be reused across all of them. The risk is trust reuse, not just package reuse.
Why this keeps happening across registries
Supply-chain compromise is usually a trust-path problem, not a registry problem. Attackers target maintainer accounts, CI/CD tokens, signing keys, or release automation because those controls can publish to more than one ecosystem, or because downstream projects mirror the same package into multiple places. Once the trusted release path is compromised, the attacker inherits the same distribution power everywhere that path is reused.
That is why a single incident can show up in npm, PyPI, GitHub Actions, or a vendor SDK at roughly the same time. The package ecosystems are different, but the compromise often sits above them in the maintainer workflow. When the same person, token, pipeline, or automation identity has authority across ecosystems, the attacker does not need a separate exploit for each registry.
Cross-ecosystem spread is also accelerated by dependency convergence. Popular libraries, build tooling, and release automation are reused by many projects, so one poisoned maintainer workflow can cascade into multiple products and installation paths. In practice, the blast radius is determined by where trust is shared, not by how many package names appear in the incident report.
How trust reuse turns one compromise into many
The common failure pattern is reuse of the same release capability in different places. That can mean one compromised maintainer account publishing to multiple registries, one stolen CI token signing multiple builds, or one compromised build step injecting malicious code into every artifact produced by the pipeline. The attacker is exploiting authority, not just code content.
There is also a strong transitive effect. If a package is embedded in another package, or a build script is copied into several repositories, compromise of the upstream maintainer can propagate quietly through downstream dependencies. The more an organisation treats package publishing as a routine developer task instead of a controlled release operation, the easier it is for a stolen secret or hijacked session to reach many ecosystems at once.
This is why package ecosystems do not have to be technically connected for the attack to spread. Shared identities, shared secrets, shared build automation, and shared release habits are enough. The registry is only the last mile of distribution.
What actually limits spread
The practical limit is separation of trust domains. If signing keys, publishing tokens, and build credentials are isolated per ecosystem, per project, and per release path, then a compromise tends to stay local. If they are reused across repositories or mirrored into multiple automation systems, the compromise becomes portable.
Another constraint is whether release artifacts are independently verified. Strong provenance checks, package signing, and reproducible or attestable builds can reduce the chance that a compromised maintainer workflow turns into a silent multi-ecosystem event. When consumers trust the package name alone, they inherit the producer’s weakest control. When they verify provenance, they make reuse harder for the attacker.
For teams operating at scale, the real question is whether one secret or one maintainer approval can publish to more than one ecosystem, and whether that path is visible enough to detect abnormal releases before downstream users install them. If the answer is yes, spread is not just possible, it is expected.
Risk and Threat Considerations
When trust is reused across registries, the main risk is blast-radius expansion. A compromise of one maintainer, token, or CI workflow can become a multi-ecosystem supply-chain event because the attacker inherits the same release authority everywhere that trust path reaches.
Failure mechanism: The attacker compromises a shared identity or automation path, then uses legitimate publishing or signing capability to push malicious artifacts into multiple ecosystems without needing separate registry exploits.
Impact: Downstream users can receive poisoned packages from more than one source, detection becomes harder because the releases look routine, and response has to cover every ecosystem touched by the shared trust path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, SLSA, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | The question centers on provenance and build-path trust reuse across ecosystems. |
| Recommendation — Adopt SLSA-aligned provenance checks to make cross-ecosystem publishing harder to abuse. | ||
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | Cross-ecosystem spread is driven by compromised supplier and release paths. |
| CM-5 — Access Restrictions for Change | The issue hinges on who can publish or modify release artifacts across systems. | |
| Recommendation — Apply SA-12 to reduce shared-trust exposure across package and build ecosystems. Restrict who can change release pipelines and publishing paths across ecosystems. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Package ecosystems and maintainers are supplier relationships that can amplify compromise. |
| Recommendation — Define supplier security expectations for package maintainers and release channels. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Cross-ecosystem spread depends on architecture choices that reuse trust and release paths. |
| Recommendation — Design release architecture so one compromise cannot publish broadly by default. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | The subject directly concerns attacker use of trusted software delivery paths. |
| Recommendation — Map observed activity to T1195 and hunt for poisoned builds or maintainer abuse. | ||
Practitioner Guidance
What to prioritise: Map every publishing path to the identities, tokens, and CI jobs that can affect more than one registry. If a single credential can publish broadly, treat it as a high-value trust concentration, not a convenience.
What to verify: Check whether release automation is isolated per ecosystem, whether publishing tokens are scoped to one package or one registry, and whether build provenance is recorded well enough to distinguish an approved release from a replayed or injected one.
Common mistake: Teams often harden the registry while leaving the maintainer workflow untouched. That protects the endpoint, but not the path the attacker actually used.
Practitioner takeaway: The control point is the shared trust relationship, if one maintainer workflow can publish in multiple places, one compromise can become many.
Related resources from NHI Mgmt Group
- How do attackers turn a supply-chain incident into wider NHI compromise?
- Why do package ecosystems remain vulnerable to credential stealing supply chain worms even when provenance is signed?
- Why do npm supply chain worms spread so quickly when maintainers reuse credentials across packages and CI workflows?
- How should security teams respond when a zero day software supply chain campaign starts spreading through package ecosystems?