Cross-Ecosystem Supply-Chain Attack

An attack that moves across multiple package, build, or tooling ecosystems to preserve trust and reach. The attacker may begin in one registry, then use another package manager, editor marketplace, or build system to reach the final execution environment.

Expanded Definition

Cross-ecosystem supply-chain attack describes a compromise path that does not stay confined to one package registry, build service, or developer tool. Instead, the attacker uses trust relationships between ecosystems to move from an initial foothold into the final software delivery path. In NHI and software supply-chain contexts, that often means abusing tokens, automation identities, signing workflows, or CI/CD permissions that are accepted across more than one environment.

This term is related to, but narrower than, generic supply-chain compromise because the key feature is ecosystem hopping. A package in one registry may seed malicious behavior that later reaches an editor marketplace, a GitHub Action, a dependency resolver, or a build pipeline. Definitions vary across vendors on whether the movement must be fully automated or whether staged human-assisted pivoting also qualifies. The practical security question is whether trust, signing, and identity boundaries are actually isolated between ecosystems, or merely assumed to be. Guidance from the OWASP Non-Human Identity Top 10 helps frame the identity side of that problem, while MITRE ATT&CK Enterprise Matrix is useful for mapping the resulting intrusion path.

The most common misapplication is calling any dependency compromise “cross-ecosystem” even when the attacker remains inside one package manager and never pivots across distinct trust domains.

Examples and Use Cases

Implementing defenses for this term rigorously often introduces more friction in developer workflows, requiring organisations to weigh delivery speed against tighter verification at each ecosystem boundary.

• A malicious package uploaded to one registry is used to harvest CI credentials, then those credentials are reused to publish a compromised plugin in a separate marketplace.
• A build script from a dependency pulls in tooling from another ecosystem, allowing the attacker to piggyback on the downstream builder’s trusted execution path. The Reviewdog GitHub Action supply chain attack shows how trusted automation can expose secrets once execution authority is inherited.
• An editor extension installs a secondary dependency from a different repository and uses it to reach the organization’s internal package publish pipeline.
• A compromised npm artifact is used as a staging point before the attacker targets GitHub Actions or another automation layer, similar to patterns discussed in the Shai Hulud npm malware campaign.
• Maintainers inherit a dependency that looks benign in one ecosystem but behaves differently when mirrored, repackaged, or consumed by a second ecosystem.

For ecosystem-specific hygiene, the LiteLLM PyPI package breach illustrates how package trust can be abused, while the CISA cyber threat advisories remain a useful reference point for active supply-chain tradecraft.

Why It Matters in NHI Security

Cross-ecosystem attacks matter because NHI controls are often distributed across identities, secrets, automation tokens, and CI/CD permissions that were never designed to be portable between trust domains. When one ecosystem is compromised, the attacker may inherit signing capability, publish rights, or token scope that unlocks the next ecosystem. That is especially dangerous where secrets are reused, over-scoped, or not rotated quickly enough. In the broader NHI risk landscape, The State of Secrets in AppSec reports that only 44% of developers follow security best practices for secrets management, which helps explain why identity material remains easy to abuse after the initial intrusion.

Detection is hard because telemetry is fragmented across registries, pipelines, and developer tools, so the compromise may look like ordinary dependency activity until the attacker begins moving laterally through trusted automation. NHI programs should therefore treat package publish tokens, bot accounts, API keys, and build-signing credentials as distinct operational identities with separate boundaries, monitoring, and revocation paths. The 52 NHI Breaches Analysis reinforces how often identity misuse becomes the pivot point after an initial software trust failure. Organisations typically encounter the business impact only after a package update, pipeline run, or marketplace install has already propagated malicious code, at which point cross-ecosystem containment becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Who is accountable when a package token is abused in a supply-chain attack?
• How should security teams handle exposed developer secrets after a supply chain attack?
• What breaks when a supplier account is compromised in a supply chain attack?
• What breaks when a third-party identity is compromised in a supply chain attack?