A software supply chain attack does not compromise your own system directly. It compromises what you install into it: open source libraries, build scripts and developer accounts. Defense rests on three principles: know the composition of your applications (SBOM), keep suspicious packages out of builds (policies and quarantine at the repository level), and protect developer and CI/CD secrets.
What a supply chain attack is
A modern application consists largely of someone else's code. A developer adds one dependency and gets dozens of transitive ones with it. Each of them is a potential entry point: if an attacker replaces a package or injects code into it, the malicious part reaches you automatically during a regular dependency installation.
The main scenarios are:
- A malicious package from scratch. The attacker publishes a package with an appealing name, and someone installs it.
- Typosquatting and name spoofing. A package is named almost like a popular one, counting on a typo or inattention. A related technique is namespace confusion.
- Hijacking a maintainer account. A genuine popular package receives a malicious version published under the legitimate author's name.
- Infiltration through trust. The attacker takes part in a project for years, gains maintainer rights and adds a backdoor.
- A worm dependency. Malware steals a developer's tokens and itself publishes infected versions of other packages.
The scale of the problem
According to Sonatype's "2026 State of the Software Supply Chain" report, 454,648 new malicious packages were recorded in 2025. In the same year, developers downloaded components 9.8 trillion times from Maven Central, PyPI, npm and NuGet. Sonatype notes that threats have shifted from spam to "persistent, industrialized campaigns", some of them state-sponsored. Malicious packages often serve as the first step of a multi-stage attack: secret theft, loaders, backdoors.
The report also describes concealment techniques: typosquatting, namespace confusion, imitation of build tools, and placing malicious payloads in AI models, container images and auxiliary binaries. A separate risk is AI assistants: they can suggest installing packages without verifying where they come from.
Real incidents
ua-parser-js (October 2021): account takeover
On October 22, 2021, attackers gained access to the developer account of ua-parser-js, a popular npm library that detects browser and OS from a user-agent string, and published three malicious versions: 0.7.29, 0.8.0 and 1.0.0. According to CERT-EU, a preinstall script checked the operating system. On Linux it downloaded the XMRig miner; on Windows it downloaded a miner and a DLL for stealing passwords from FTP clients, mail, messengers and browsers. A notable detail: on Linux the malware did not run in Russia, Ukraine, Belarus and Kazakhstan. The fixed versions are 0.7.30, 0.8.1 and 1.0.1.
Lesson: the malicious code ran at the installation stage, before the application even started, and the package was legitimate and popular.
XZ Utils (March 2024): a backdoor through trust
In March 2024, developer Andres Freund discovered a backdoor in the xz/liblzma compression library while analyzing slow SSH connections in a test version of Debian. The vulnerability was assigned CVE-2024-3094 and the maximum CVSS score of 10.0; versions 5.6.0 and 5.6.1 were affected. Public disclosure took place on March 29, 2024.
A distinctive feature of this case is the long preparation. According to Wikipedia, a user named "Jia Tan" ran a campaign for more than two years starting in 2021, and sock puppet accounts pressured the original maintainer until he handed over rights. The malicious part was contained in the release archives but not in the Git repository itself, so reviewing the source code on GitHub did not reveal it. The campaign was noticed by chance.
Lesson: code review and repository scanning are not enough; you need to check what actually enters the build and compare release artifacts against the source code.
Shai-Hulud (September 2025): a worm in npm
On September 23, 2025, the US agency CISA issued an alert about a large-scale compromise of the npm ecosystem. The self-replicating Shai-Hulud worm infected more than 500 packages. Once inside a developer's environment, it searched for credentials, including GitHub tokens and API keys for AWS, Google Cloud and Azure, sent them to the attackers' server and published them to a public repository. The worm then authenticated to npm as the developer and published infected versions of the developer's other packages. This is how it spread further.
CISA's recommendations: check lock files (package-lock.json, yarn.lock) for affected packages, including nested ones; find cached copies in artifact repositories; pin versions published before September 16, 2025; rotate all developer credentials; enable phishing-resistant MFA for GitHub and npm; restrict outbound connections.
Lesson: a leaked developer token becomes a distribution channel. Here, secrets and the supply chain are one and the same problem (see secrets management).
Why this matters for companies in Central Asia
Banks and financial companies in the region develop applications using the same npm, PyPI, Maven and NuGet as the rest of the world. Regional geography alone offers no protection: in CERT-EU's description of ua-parser-js, Kazakhstan is mentioned among the countries where the Linux variant of the miner did not run, but no such exception is noted for the Windows branch that steals passwords. In addition, developers often work from closed networks with proxy access to the internet, where a single uncontrolled channel for direct package installation nullifies protection.
How to protect yourself: practical measures
1. Know what you have
Without an inventory, you cannot quickly answer the question "are we affected?". Generate an SBOM with every build and store it together with the release. For details, see our article "What is an SBOM". SCA tools such as Sonatype Lifecycle find vulnerable and malicious components and show which applications use them.
2. Place a gateway between the internet and the build
All dependencies should go through an internal artifact manager, and direct access from build agents to npmjs.com and PyPI should be closed off. This creates a point of control. Sonatype Repository Firewall blocks malicious and vulnerable packages at download time, quarantines suspicious components and automatically releases those deemed safe. Policies can be based on package age, risk level and license. The product is designed for Nexus Repository; for other artifact managers, Sonatype offers Firewall Pro. For more on choosing, see Nexus Repository vs Artifactory.
3. Pin versions and review updates
- Use lock files and pin exact versions rather than ranges.
- Introduce a "novelty quarantine": do not accept a version into the build that was published very recently until it has been verified. Many attacks are detected within the first hours or days.
- Watch for suspicious changes in installation scripts (preinstall, postinstall).
4. Protect accounts and secrets
- Enable phishing-resistant MFA on GitHub, npm and PyPI.
- Do not store tokens in plain text in developers' environment variables or in repositories. Use a secrets vault and short-lived credentials.
- Prepare a procedure for mass rotation: after an incident like Shai-Hulud, everything has to be changed.
5. Verify your own code and build
A backdoor can enter through your contractor or through an internal package. SAST and binary analysis help find undocumented functionality in your own code and in third-party builds. For the classes of tools, see SAST, DAST, SCA and MAST.
6. Prepare your response
Define in advance: who makes the decision to block a package, how quickly you can find all applications containing a component, how to replace the infected version, and how to verify that the malware did not run on build servers or developer machines.
Where to start
- Close direct build access to external registries and route it through an artifact manager.
- Enable component scanning and SBOM generation for critical applications.
- Configure policies to block malicious packages and quarantine new versions.
- Audit tokens and enable MFA for developers.
- Rehearse the scenario "a malicious package has been found".
Frequently asked questions
How is a malicious package different from a vulnerable one?
Is it enough to scan dependencies in CI?
What should we do if we installed an infected package?
Does an SBOM help prevent an attack?
Want to check what enters your builds and close the door to malicious packages? As a Sonatype distributor in Kazakhstan and Central Asia, AST Cyber Lab will run a pilot of Repository Firewall and Lifecycle on your projects.
Sources
- Infosecurity Magazine: overview of the Sonatype 2026 State of the Software Supply Chain report
- CERT-EU: Security Advisory 2021-057 (ua-parser-js)
- Wikipedia: XZ Utils backdoor
- CISA: Widespread Supply Chain Compromise Impacting npm Ecosystem
- Sonatype: Repository Firewall