Supply chain attacks reach thousands of victims through one trusted supplier, and many recent ones started with a stolen identity or an unprotected build step rather than a novel exploit. ENISA's threat landscape for supply chain attacks, covering incidents from January 2020 to early July 2021, attributed half of them to advanced persistent threat actors, and the npm worms of 2025 showed criminals running the same playbook at scale. Lists of the biggest supply chain attacks or top supply chain attacks usually name incidents; this top 10 supply chain attacks list ranks the types of supply chain attacks behind them, by our judgement of frequency and impact, and uses notable supply chain attacks as examples of supply chain attacks for each type, from major supply chain attacks such as SolarWinds to recent supply chain attacks in npm. For every type: what it is, how to spot it and the control that matters most, then a mapping to MITRE ATT&CK v20, SLSA and OWASP. It is for security, platform and procurement teams. Dependency management, SBOMs and vendor assurance in depth are in the Software Supply Chain Security Guide.
The Top 10 at a glance
- Build system compromise
- Publishing account takeover and malicious package versions
- Dependency confusion and typosquatting
- CI/CD pipeline and third-party action compromise
- Malicious or compromised maintainers
- Hijacked updates and distribution channels
- Code signing key theft and abuse
- Developer tool and extension compromise
- Trusted vendor and SaaS integration compromise
- AI model and agent component poisoning
| # | Supply chain attack types | Supply chain attack examples | First control |
|---|---|---|---|
| 1 | Build system compromise | SolarWinds Orion, TeamCity exploitation | Isolated, hardened build platform with signed provenance |
| 2 | Publishing account takeover | ua-parser-js, Shai-Hulud | Phishing-resistant MFA and trusted publishing |
| 3 | Dependency confusion and typosquatting | PyTorch torchtriton, PyPI typosquats | One internal package index with scoped names |
| 4 | CI/CD and action compromise | tj-actions and reviewdog, Ultralytics | Pin actions to commit SHAs; least-privilege tokens |
| 5 | Malicious or compromised maintainer | XZ Utils | Producer due diligence and staged adoption |
| 6 | Hijacked updates and distribution | NotPetya, 3CX, Codecov | Verify signatures and provenance at install |
| 7 | Code signing abuse | NVIDIA certificates, HashiCorp GPG key | Keys in HSMs behind a signing service |
| 8 | Developer tool and extension compromise | GlassWorm, Cyberhaven, Nx | Extension allowlists and clean developer endpoints |
| 9 | Trusted vendor and SaaS integration | Salesloft Drift, JumpCloud, Bybit | Scoped, monitored third-party access |
| 10 | AI model and agent components | postmark-mcp, LiteLLM | Allowlisted, pinned AI components |
1. Build system compromise
What it is: the attacker gets inside the vendor's build environment and inserts code during compilation, so the output is genuinely built and signed by the vendor. CISA Emergency Directive 21-01 described an adversary with "longstanding, covert access to the build process that SolarWinds uses for Orion", resulting in malicious code in Orion versions 2019.4 through 2020.2.1 HF1. The SolarWinds compromise then moved into victims' identity systems. Build servers themselves are targets too, as the TeamCity CVE-2023-42793 exploitation showed.
How to spot it: build outputs that differ from a rebuild of the same source, unexpected processes or network connections on build agents, and changes to build scripts outside version control.
The control: SLSA Build Level 3, where "Builds are isolated from one another" and "only the control plane has access to cryptographic secrets", with ephemeral build agents and signed provenance that consumers verify. See the SLSA and Build Provenance Guide.
2. Publishing account takeover and malicious package versions
What it is: the attacker steals a maintainer's registry token or password and publishes a malicious version of a trusted package. CISA's September 2025 alert describes Shai-Hulud as a "self-replicating worm" that "compromised over 500 packages", stealing GitHub personal access tokens and AWS, Google Cloud and Azure keys, then authenticating as each compromised developer to publish more infected packages. Earlier cases such as the ua-parser-js hijack used a single taken-over account; the Shai-Hulud first wave made it self-spreading.
How to spot it: a release published without matching provenance or outside the normal CI workflow, new install scripts in a patch release, and packages reaching out to the network on install.
The control: for publishers, phishing-resistant MFA on registry and repository accounts, as CISA requires, and OIDC-based trusted publishing so no long-lived token exists. For consumers, pin versions in lock files, delay adoption of brand new releases, and rotate developer credentials after any exposure. See the Open Source Security Guide.
3. Dependency confusion and typosquatting
What it is: the consumer installs the wrong package. In dependency confusion, SLSA's example is to "Register a package name in a public registry that shadows a name used on the victim's internal registry"; the PyTorch torchtriton attack worked this way. Typosquatting relies on misspellings: the CISA and NIST 2021 guidance cites 12 malicious PyPI libraries found in 2018 with names such as "diango" and "djago".
How to spot it: internal package names appearing on public registries, builds resolving a dependency from an unexpected source, and new dependencies with near-match names.
The control: route all installs through one internal index or proxy, reserve your namespaces on public registries, use scoped package names and block direct public resolution for internal names. See the Malicious Package and Dependency Confusion Guide.
4. CI/CD pipeline and third-party action compromise
What it is: the attacker compromises a reusable pipeline component, or injects code into a workflow, to run inside thousands of builds that hold secrets. CISA's March 2025 alert covered tj-actions/changed-files (CVE-2025-30066), whose compromise was "potentially enabled by a compromise of another GitHub Action", and reviewdog/action-setup (CVE-2025-30154); exposed secrets included access keys, GitHub personal access tokens, npm tokens and private RSA keys. See the tj-actions compromise and the Ultralytics compromise, where a workflow injection and a leftover PyPI token put a cryptominer into an AI library.
How to spot it: action tags that suddenly point to new commits, encoded output in workflow logs, and workflow runs making unexpected outbound calls.
The control: pin third-party actions to full commit SHAs, allow only approved actions, give workflow tokens read-only defaults, replace stored cloud keys with OIDC federation, and rotate every secret a compromised workflow could read, as CISA directed. See the GitHub and GitHub Actions Security Guide.
5. Malicious or compromised maintainers
What it is: the trusted producer is the threat, through a long social engineering campaign or a maintainer turning hostile. SLSA calls this threat A, "Producer": provenance proves who built a package, not that the builder is honest. CISA reported malicious code in XZ Utils versions 5.6.0 and 5.6.1 (CVE-2024-3094) and advised downgrading to an uncompromised version such as 5.4.6. The XZ Utils backdoor came through a trusted maintainer identity.
How to spot it: a new maintainer gaining release rights quickly, pressure on existing maintainers, obfuscated test files or build changes, and release artefacts that differ from the repository.
The control: assess critical dependencies for maintainer depth and project health, prefer slower, staged adoption of new versions in production (OWASP A03:2025 recommends staged rollouts or canary deployments), and fund or support the projects you depend on.
6. Hijacked updates and distribution channels
What it is: the attacker tampers with software after it is built: in the update server, a download bucket or a mirror. CISA and NIST list "Hijacking Updates", "inserting malware into the outgoing update", citing NotPetya's 2017 spread through tax accounting software popular in Ukraine. CISA reported in March 2023 that 3CXDesktopApp "was trojanized, potentially leading to multi-staged attacks". In the Codecov breach a leaked cloud storage key let attackers alter a CI script customers downloaded.
How to spot it: hash mismatches between downloaded files and published checksums, updates arriving outside normal release cadence, and newly updated software making unfamiliar outbound connections (ATT&CK detection DET0537 looks for hash-mismatched delivery and suspicious first-run behaviour).
The control: verify signatures and provenance at install, never pipe downloaded scripts straight into a shell in CI, and stage updates through test rings before broad deployment.
7. Code signing key theft and abuse
What it is: signed malware inherits the trust of the signer. CISA and NIST describe attackers who "undermine codesigning by self-signing certificates", break signing systems or exploit weak access controls, naming APT41 as a routine user of the technique. The NVIDIA code-signing certificate theft led to signed malware, and the HashiCorp GPG key exposure showed the Codecov breach exposing the key that signs product downloads.
How to spot it: signing events outside release pipelines, signatures from certificates not in your inventory, and valid signatures on binaries with no matching build record.
The control: keep signing keys in HSMs behind a signing service that only the release pipeline can call, log every signature, and rehearse revocation. See the Code Signing Security Guide.
8. Developer tool and extension compromise
What it is: ATT&CK T1195.001 covers "Compromise Software Dependencies and Development Tools". IDE extensions, browser extensions and build tools run with the developer's access to source, tokens and cloud credentials. The GlassWorm campaign spread through VS Code extensions using stolen developer tokens, the Cyberhaven extension breach began with one phished OAuth consent, and the Nx s1ngularity attack turned a build tool into a credential stealer.
How to spot it: extensions updating with new permissions, developer machines contacting unfamiliar hosts, and tokens used from new locations soon after an update.
The control: allowlist extensions through managed IDE and browser policy, keep long-lived credentials off developer machines, and treat a compromised developer endpoint as a credential incident. See the Enterprise Browser and Browser Security Guide.
9. Trusted vendor and SaaS integration compromise
What it is: the supplier is a service, not software: an IT provider, identity platform or SaaS integration that already holds access to you. ATT&CK T1199 Trusted Relationship covers adversaries abusing outside organisations with existing access. The Salesloft Drift breach used stolen OAuth tokens from one chatbot integration to reach hundreds of Salesforce instances; the JumpCloud breach used an identity platform to reach its customers; OWASP A03:2025 cites the 2025 Bybit theft of $1.5 billion, which the Bybit hack page traces to one developer's AWS session tokens.
How to spot it: integration tokens used from new IP ranges or for bulk exports, and vendor accounts active outside agreed hours or scope.
The control: ATT&CK's mitigations are MFA for delegated administrators, segmentation, and tight management of third-party accounts. Scope OAuth grants, rotate integration tokens and keep an owner for each. See the SaaS and OAuth App Governance Guide and the Third-Party Risk Management Guide.
10. AI model and agent component poisoning
What it is: the same techniques aimed at models, AI libraries, MCP servers and agent plugins, which often hold API keys and broad data access. The postmark-mcp malicious MCP server copied every email an agent sent, and the LiteLLM PyPI breach began with a poisoned security scanner leaking a publishing token. MITRE ATLAS tracks AML.T0115 Publish Poisoned AI Artifacts and AML.T0109 AI Supply Chain Rug Pull.
How to spot it: new MCP servers or model files appearing on developer machines, AI packages requesting network access at install, and agent tools whose definitions change after approval.
The control: an allowlist of approved models, AI packages and tool servers pinned by version or digest, loaded from an internal mirror. See the AI Supply Chain and AI-BOM Guide.
Mapping to OWASP
OWASP Top 10:2025 ranks A03:2025 Software Supply Chain Failures third, defining it as "breakdowns or other compromises in the process of building, distributing, or updating software"; it covers all ten types. For AI components, OWASP maps to LLM04:2026 Supply Chain and ASI04 Agentic Supply Chain Vulnerabilities. ATT&CK IDs below were checked against ATT&CK v20; SLSA letters are from SLSA v1.2. Hardware supply chain compromise (T1195.003) is outside this list, which focuses on software and services.
| Attack type | MITRE ATT&CK v20 | SLSA v1.2 threat | OWASP |
|---|---|---|---|
| 1. Build system compromise | T1195.002 Compromise Software Supply Chain | E Build process | A03:2025 |
| 2. Publishing account takeover | T1195.001, T1195.002 | F Artifact publication | A03:2025 |
| 3. Dependency confusion and typosquatting | T1195.001 | H Package selection | A03:2025 |
| 4. CI/CD and action compromise | T1195.001 | E Build process; D External build parameters | A03:2025 |
| 5. Malicious maintainer | T1195.001 | A Producer | A03:2025 |
| 6. Hijacked updates and distribution | T1195.002 | G Distribution channel | A03:2025 |
| 7. Code signing abuse | T1195.002 | F Artifact publication (provenance must be signed) | A03:2025 |
| 8. Developer tool compromise | T1195.001 | Outside SLSA build scope | A03:2025 |
| 9. Trusted vendor and SaaS integration | T1199 Trusted Relationship | Not covered | A03:2025 (third-party integrations) |
| 10. AI model and agent components | T1195.001 | A, F, H as for any package | LLM04:2026; ASI04 |
Where to start
If you can do only three things this quarter: require phishing-resistant MFA and short-lived or federated credentials for every developer, maintainer, CI and registry identity (types 2, 4, 8, 9); route every dependency, action, extension and AI component through an internal allowlist or proxy with pinned versions (types 3, 4, 8, 10); and verify signatures and provenance before anything reaches production (types 1, 6, 7). Across the supply chain attack case studies above, the most common supply chain attacks share one pattern: a stolen token, then a trusted release. Track monthly: share of builds with verified provenance, share of third-party actions pinned to SHAs, long-lived publishing tokens remaining, median time to rotate secrets after a supplier incident, and third-party integrations without a named owner. The NIST SSDF (SP 800-218) and SP 800-161 Rev. 1 give the programme structure. See the CI/CD Security Guide.
Standards and references
- CISA and NIST: Defending Against Software Supply Chain Attacks
- NIST: SP 800-161 Rev. 1 Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
- NIST: SP 800-218 Secure Software Development Framework (SSDF) Version 1.1
- ENISA: Threat Landscape for Supply Chain Attacks
- SLSA: Threats and mitigations (v1.2)
- MITRE ATT&CK: T1195 Supply Chain Compromise
- OWASP: A03:2025 Software Supply Chain Failures
- CISA: Widespread Supply Chain Compromise Impacting npm Ecosystem
Related NHI Mgmt Group resources: Software Supply Chain Security Guide · Malicious Package and Dependency Confusion Guide · SLSA and Build Provenance Guide · CI/CD Pipeline Identity Security Guide · SBOM Guide