In short
Software supply chain attack refers to an attack in which it is not your application itself that is compromised but a link in its supply chain: a dependency from npm or Packagist, a build server, a package registry, an update channel or an extension such as a shop plugin. The attacker smuggles code in where you trust it anyway, and your own installation or deploy process distributes it further.
In the end, the victim is not the maintainer but everyone who installs their package.
Over the past three years, the term has had a career it would rather not have had. What was regarded in 2020, with SolarWinds, as an exceptional case for intelligence services has been everyday life in every Node.js project since 2025: a worm compromises a package, the package steals tokens, the tokens infect further packages. Nobody attacked you, and yet your AWS keys ended up in someone else's GitHub repository.
The unpleasant thing about this class of attack: it does not arise from a mistake in your code. Your team can program cleanly, do reviews and validate every input, and a credential stealer still lands in the CI pipeline via npm install. That is why OWASP fundamentally restructured the topic in the 2025 edition of the OWASP Top 10.
Classification: A03:2025 Software Supply Chain Failures
In the OWASP Top 10:2025, the category is called A03:2025 Software Supply Chain Failures. It replaces the old 2021 category "Vulnerable and Outdated Components" and extends it considerably: it is no longer only about known vulnerabilities in outdated libraries but about any compromise in building, distributing or updating software.
The figures from the OWASP document are remarkable. In the community survey, exactly 50 per cent of respondents put this category in first place, more than any other. The category bundles 6 CWEs, has the highest average incidence rate of all ten categories at 5.72 per cent and a weighted exploit score of 8.17. OWASP explicitly names SolarWinds, Log4Shell and the Shai-Hulud worm with over 500 affected package versions as examples.
The fact that a category with only 11 mapped CVEs ranks so high says something about the data: supply chain incidents rarely produce a CVE for the victim. They show up as incidents, not as vulnerabilities. OWASP itself admits that these cases are hard to detect, even though they occur frequently. Anyone who only runs CVE scanners does not see precisely this part of the threat.
Forms of attack: where the supply chain breaks
A software supply chain has many links, and each one is an attack vector of its own. The range extends from a stolen maintainer password to a manipulated compiler. In practice, attacks on package registries have dominated since 2025, because that is where the effort is lowest and the reach greatest. The following table arranges the most important forms by the link they hit.
| Form of attack | Affected link | Mechanics | Known example |
|---|---|---|---|
| Compromised maintainer account | Registry / publish rights | Stolen token or password, then publication of a manipulated version under a legitimate name | Shai-Hulud (npm, 2025/2026) |
| Typosquatting | Registry / namespace | Package with a name similar to a popular package, waiting for typos or AI-hallucinated package names | Ongoing on npm and PyPI |
| Dependency confusion | Resolver / private registry | Public package with the name of an internal package but a higher version number; the resolver prefers the public source | Alex Birsan, 2021 |
| Malicious install scripts | Installation process | preinstall/postinstall executes code on every machine that installs the package, including in CI | CHAINDROP (npm, 08/2026) |
| Manipulated build | Build pipeline / tarball | The source code is clean, the distributed artefact is not; malicious code is only injected during the build | SolarWinds 2020, xz-utils 2024 |
| Compromised update channel | Delivery | Signed, legitimate updates carry the malicious code to all customers at the same time | SolarWinds Orion 2020 |
| Malicious extension | Plugin / app in the target system | Extension runs with the application's permissions and uses or bypasses its sandbox | Shopware app script sandbox escape 2026 |
Manipulated builds: SolarWinds and xz-utils
The two textbook cases of manipulated builds are four years apart and could hardly be more different. At SolarWinds, the build process of the Orion platform was altered so that a backdoor got into the signed updates of versions 2019.4 HF 5 to 2020.2.1 HF 1. The US agency CISA warned of active exploitation on 13 December 2020 (CISA alert). OWASP puts the number of affected organisations at around 18,000.
The xz-utils case of March 2024 was an attack on an open-source project from within. A contributor built up maintainer trust over two years and then hid a mechanism in the release tarballs of versions 5.6.0 and 5.6.1 that injected a prebuilt object file into liblzma during the build. The target was the SSH daemon of many Linux distributions. CVE-2024-3094 received the maximum CVSS score of 10.0 (NVD). It was discovered by chance, because a developer wondered about a 500-millisecond log-in delay.
Real-world examples 2025 and 2026: the npm year
For teams with Node.js, NestJS or a headless storefront, the relevant story is that of the npm registry. Within a year, a pattern has become established there that now has a name: the self-propagating registry worm.
Shai-Hulud, first and second wave
In September 2025, the Shai-Hulud worm compromised hundreds of npm packages in several waves. The principle: an install script steals the npm and GitHub tokens of the developer installing the package and uses these tokens to infect all packages the developer has publish rights to as well. Every victim thus becomes a distributor.
Shai-Hulud 2.0 followed between 24 November and 1 December 2025. Microsoft published guidance on detection and defence on 9 December 2025 (Microsoft Security Blog). The second wave used a preinstall script called set_bun.js, installed the Bun runtime, set up a GitHub Actions runner called "SHA1HULUD" on the victims' machines and searched for credentials with TruffleHog. Maintainer accounts of Zapier, PostHog and Postman were affected.
According to Microsoft, a smaller wave followed in May 2026 that for the first time hit npm and PyPI at the same time: over 170 npm packages and 2 PyPI packages in 404 malicious versions.
CHAINDROP, 4 August 2026
On 4 August 2026, Elastic Security Labs reported the CHAINDROP variant: over 400 compromised npm packages with a combined total of more than 1.3 billion downloads a month (Elastic Security Labs). Among them were keyv with 600 million monthly downloads, flat-cache with 580 million and cache-manager with 16 million. The payload carried the description "Shai-Hulud: Here We Go Again" and a credential harvester that searches for over 300 patterns: keys for Anthropic, OpenAI and Gemini, credentials for AWS, GCP and Azure, GitHub tokens, SSH keys and Kubernetes credentials.
The punchline for NestJS teams: keyv is inside cache-manager, and cache-manager is behind the CacheModule that many projects register in app.module.ts. Whether you were affected is shown by running npm ls keyv in the project folder. Anyone who did not know this in August most probably did not check.
npm 12 switches off install scripts
The registry has reacted, and it did so before CHAINDROP. npm 12 was released on 8 July 2026 and no longer runs install scripts of dependencies by default; allowScripts is now an explicit approval per package. Git dependencies (--allow-git) and remote tarballs (--allow-remote) are blocked by default, and access tokens that bypass two-factor authentication are deprecated (InfoQ, August 2026).
According to JFrog, these three vectors were behind around 53 per cent of the malicious npm attacks observed in the previous year. npm was thus the last major package manager to introduce these defaults; pnpm, yarn and bun already had them.
The fact that CHAINDROP still worked via preinstall four weeks after npm 12 shows the inertia of the supply chain: a new default only protects machines on which it has arrived. CI images, Docker base images and developer laptops with npm 10 or 11 remained open.
The scale
Sonatype counted a total of 454,648 newly discovered malicious open-source packages in 2025, published in the State of the Software Supply Chain report of 28 January 2026 (Infosecurity Magazine). Sonatype classifies 56 per cent of them as repository abuse and 28 per cent as potentially unwanted applications. The report's finding: the attacks have developed from spam and experiments into industrialised campaigns.
The Shopware side: apps and plugins are code with shop permissions
Composer does not have install scripts in the npm form, and Shopware plugins mostly come from the Shopware Store with a review. That does not mean that a shop's supply chain is secure. It just runs somewhere else: through the extensions themselves. Every app and every plugin is third-party code to which you give your shop's permissions, including customer data, orders and payment flows.
That is exactly why Shopware put apps in a sandbox: app scripts run in a restricted Twig environment without direct PHP access. On 25 August 2026, however, Shopware published the advisory GHSA-6qhw-38wm-7g7h: a malicious or compromised app could execute arbitrary PHP functions and operating system commands from its app scripts with the permissions of the web server process; CVSS 9.6. Shopware 6.5.4.0 to 6.6.10.22 and 6.7.0.0 to 6.7.13.0 were affected, patched in 6.6.10.23 and 6.7.13.1.
As early as 11 March 2026, Shopware closed a gap in app registration with CVE-2026-31889 (CVSS 8.9): anyone who knew the app secret could redirect the communication channel between shop and app to their own server via a new registration and thus siphon off the shop's API credentials (GitHub Advisory). Both cases have the same core: the extension is part of the supply chain, and its trust boundary is the shop.
For shop operators, this leads to a simple rule: every installed extension is a supplier that deserves a security assessment. Who maintains it, how quickly updates arrive, what permissions it requests and whether it is really still needed. A plugin that nobody has updated for two years is not a feature but an open item.
Countermeasures: what really protects
There is no single tool against supply chain attacks, but there is a handful of measures that would have caught most of the real incidents of the past two years. The most important one is unspectacular: do not let yourself be lifted automatically to the latest version. A committed lockfile plus npm ci in CI ensures that exactly the versions someone has deliberately checked are installed.
A waiting period of a few days before adopting new versions would have made almost every Shai-Hulud wave fizzle out, because the registry removed the malicious versions within hours to days.
The second measure is switching off install scripts as long as you are not on npm 12. In CI, this looks like this:
# Strict lockfile, no install scripts from dependencies
npm ci --ignore-scripts
# Check whether an affected package is in the tree
npm ls keyvPackages that do not work without an install script (such as native add-ons) you then approve individually, instead of allowing all packages to execute code across the board. Exactly this opt-in model has been the default since npm 12.
Third, you need visibility: a software bill of materials (SBOM) lists every direct and transitive dependency with its version. In the next wave, it answers the question "are we affected?" in minutes instead of days. OWASP names the SBOM as the first preventive measure of category A03.
It is supplemented by signatures and provenance: npm supports provenance attestations via Sigstore, which can be used to prove that a package comes from a particular repository and build workflow. A package without provenance is not an exclusion criterion, but it is a question mark.
Fourth, the accounts: two-factor authentication on all npm, Packagist and GitHub accounts, without long-lived tokens that bypass the second factor. Shai-Hulud lived off exactly such tokens. CI pipelines should publish with short-lived, scope-limited credentials, ideally via OIDC instead of stored secrets. The principle of least privilege applies to build jobs just as it does to users.
Fifth, the build environment itself: build servers, artefact registries and code repositories are production systems and should be hardened, monitored and operated with separate responsibilities. OWASP explicitly recommends separation of duties in CI/CD and staggered roll-outs instead of simultaneous updates on all systems. Anyone running their CI on a forgotten Jenkins with an admin token has a supply chain with an open back door. If you want an architecture for your team in which these questions are considered from the outset, that is part of our enterprise software development.
Regulation: NIS2 and the Cyber Resilience Act
Supply chain security has also been a legal requirement since 2024. The NIS2 Directive explicitly requires essential and important entities to take measures for "supply chain security", including relationships with direct suppliers and service providers. Anyone covered by NIS2 must be able to demonstrate how they assess the security of their software suppliers.
The Cyber Resilience Act (CRA) goes one step further and addresses manufacturers of products with digital elements directly. The regulation entered into force on 10 December 2024; the reporting obligations for actively exploited vulnerabilities under Article 14 have applied since 11 September 2026, and full application of all obligations follows on 11 December 2027 (CRA Article 71).
From then on, an SBOM, a process for handling vulnerabilities and secure update mechanisms, among other things, are mandatory for all products placed on the market in the EU. For software vendors, plugin manufacturers and agencies that deliver their own products, this is the deadline to which the countermeasures above relate.
Distinction
Vulnerable and outdated components was OWASP category A06 until 2021 and has been a sub-aspect of A03 since 2025. The difference: an outdated component has a known, accidentally created vulnerability that a scanner finds. A supply chain attack brings deliberately injected malicious code into a current version that no CVE scanner knows about until the registry has reacted.
The countermeasures overlap, but patching alone does not help against the second case; on the contrary, anyone who updates to the latest version on the day of publication is first in line for the worm.
Insider threat means an attacker with legitimate access within your own organisation. The xz-utils case shows the grey area: the attacker was an insider of the open-source project but an outsider for every distribution that used the package. For you as a user, it is a supply chain attack; for the project, an insider case.
Broken access control (A01) describes missing or incorrect permission checks within your application. A supply chain attack can exploit or bypass such gaps, for example when an extension with shop permissions leaves the sandbox, but it is a separate attack route that brings the code into your system from outside.
Frequently asked questions
Is a dependency scanner such as npm audit or Dependabot enough against supply chain attacks?
No. These tools compare versions with known CVEs. A compromised package has no CVE in the first hours or days and appears as a harmless new version. Scanners are necessary for the "outdated components" part, but against worms such as Shai-Hulud what helps is a lockfile, a waiting period, disabled install scripts and an SBOM with which you can quickly check in an emergency whether you are affected.
Does the topic also affect a Shopware shop without its own Node.js project?
Yes, in two ways. First, the build of the storefront and the administration itself runs via npm, even if you never write a line of JavaScript. Second, apps and plugins are your supply chain: they run with your shop's permissions, and advisories such as the app script sandbox escape of August 2026 show that the sandbox is no guarantee. Keep the number of extensions small and their versions up to date.
What is the first step if I want to start today?
Generate an SBOM for every production project and switch CI to npm ci --ignore-scripts; both take an afternoon. Then activate two-factor authentication without bypass tokens on all registry and GitHub accounts and introduce a waiting period for new versions. Only when that is in place are signature checks and provenance worthwhile as the next stage.