Supply-chain poisoning

Expanded Definition

Supply-chain poisoning describes compromise of the software path before code reaches production, including package registries, build pipelines, update channels, and developer tooling. In NHI security, the danger is not only malicious code but also poisoned metadata, dependency confusion, compromised maintainer accounts, and trojanised automation that can silently inherit trusted execution authority. The term is broader than classic malware delivery because the attacker benefits from normal resolution rules and signed or inherited trust. That is why guidance from the OWASP Non-Human Identity Top 10 is often relevant when build identities, tokens, and CI/CD credentials are part of the attack path. Definitions vary across vendors on whether a poisoned dependency must be intentionally malicious at publication time or can also include later account takeover that changes a trusted artifact. The most common misapplication is treating supply-chain poisoning as a pure malware problem, which occurs when teams ignore identity abuse, package integrity, and pipeline trust boundaries.

Examples and Use Cases

Implementing supply-chain controls rigorously often introduces release friction, requiring organisations to weigh faster dependency adoption against stronger verification, provenance checks, and review gates.

• A public package is uploaded with a name that matches an internal dependency, so builds pull the attacker’s version during routine resolution.
• A maintainer account is hijacked and a legitimate library is republished with hidden payloads that execute in CI or on developer workstations, as seen in the LiteLLM PyPI package breach.
• A GitHub Action is altered after publication, turning a trusted workflow into a credential harvester, similar to the patterns described in the Reviewdog GitHub Action supply chain attack.
• Malicious npm or PyPI packages install post-compromise backdoors that steal API keys from build logs, local environments, or secrets stores, matching the behaviour documented in the Shai Hulud npm malware campaign.
• Federated build credentials are abused to push a tainted artifact into downstream systems, which is why CISA supply chain guidance is often paired with provenance enforcement and artifact signing.

Why It Matters in NHI Security

Supply-chain poisoning is an NHI problem because the attacker often does not need to break application logic if they can compromise the identities that publish, sign, or deploy software. Once an automation token, maintainer credential, or CI secret is captured, the poisoned artifact can move through trusted channels and inherit downstream authority. NHIMG research shows how quickly exposed credentials become operationally dangerous: in The State of Secrets in AppSec, 43% of security professionals said they are concerned about AI systems learning and reproducing sensitive information patterns from codebases, underscoring how poisoned supply chains can also seed secret exposure at scale. The risk is amplified when organisations rely on weak provenance checks, broad publish permissions, or long-lived secrets in build systems, conditions that appear in many real incidents including the Mastra npm Supply Chain Attack. Organisational controls improve only when package integrity, identity assurance, and secret hygiene are treated as one chain of trust, not separate checklists. Organisations typically encounter this consequence only after a trusted update has already been shipped, at which point supply-chain poisoning becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• MCP Supply Chain Poisoning
• 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?