Software supply chain security: how your dependencies put you at risk

Software supply chain security is about protecting the code you did not write but still ship. In a modern application, most of the lines running in production do not come from your own team. They come from open source libraries, frameworks, and the dependencies of those dependencies. Every time you run npm install or pip install, you are trusting dozens, often hundreds, of developers you have never met. A supply chain attack targets exactly that trust: instead of breaking into your systems directly, the attacker poisons a component you already use, and the malicious code walks in as an invited guest the moment you update. Defending against it comes down to three habits: know what you depend on, scan those dependencies continuously, and lock down your build pipeline.

This is no longer a theoretical worry. In the 2025 edition of the OWASP Top 10, the most referenced list of web application risks, "Software Supply Chain Failures" entered directly at number three (A03). The earlier list described a narrower version of this risk as "vulnerable and outdated components"; the new entry widens it to cover build systems, package registries, and distribution infrastructure as well. In the community survey behind the list, half of all respondents ranked it as their single biggest concern. The reason is simple: one flaw in a shared component can reach thousands of companies at once.

The best known case is the 2020 SolarWinds incident. Attackers quietly inserted malicious code into an update for Orion, the network monitoring software many organizations run. The result: roughly 18,000 organizations installed the tampered update themselves, believing it was official and signed. Because the code arrived from inside their own trusted perimeter, no firewall stopped it. The lesson stuck: even a signed update from a vendor you trust is no longer something to accept without question.

A second case shows how widespread a single library can be. In December 2021, Log4Shell (CVE-2021-44228) surfaced in log4j, a logging library used almost everywhere in the Java world. It carried a CVSS score of 10, the highest possible. Exploiting it was so easy that a single line pasted into a text field could be enough to run code remotely. The number of exposed systems was estimated in the hundreds of millions. Most companies did not even know they were running log4j, because it was a dependency of a dependency buried inside some other product they had bought.

A third case shows how patient and deliberate these attacks can be. In March 2024, a backdoor (CVE-2024-3094) was found in xz-utils, a compression tool shipped with most Linux distributions. The attacker did not hack anything directly. Using the alias "Jia Tan", they contributed to the project for roughly two years, built up trust, eventually earned maintainer rights, and slipped the backdoor into the code slowly. It was built to give remote SSH access to servers. It was caught almost by accident, when a Microsoft engineer noticed that SSH logins were opening a few seconds slower than usual, and it was stopped days before it reached the stable releases of major distributions.

Public package registries are a direct target too. Attackers upload fake packages with names one typo away from a popular one, hoping a developer mistypes the install command (typosquatting). Another technique abuses the "post-install" scripts that run automatically during installation, using them to steal secrets and tokens straight off the machine. In 2025, a piece of malware called Shai-Hulud became the first self-propagating worm in the npm ecosystem: it used the npm tokens it found on an infected machine to publish malicious versions of other packages on its own, reaching more than 500 package versions before it was shut down.

First, know what you depend on

You cannot protect what you cannot see. Produce a software bill of materials (SBOM), a plain inventory of which libraries your application pulls in and at which versions. During the Log4Shell crisis, the companies that recovered fastest were the ones that could answer "where do we use log4j?" in minutes; those without an inventory searched blindly for days. That list has to include the indirect dependencies sitting underneath the packages you installed on purpose, because that is exactly where most of the risk hides.

Pin your versions and scan continuously

Pin dependency versions and commit the lockfiles (package-lock.json, poetry.lock, go.sum and the like) into your repository, so the code you build today is made of exactly the same components as the code you build tomorrow. Then add a tool that scans those dependencies automatically. Software composition analysis (SCA) tools such as GitHub's Dependabot, npm audit, or OWASP Dependency-Check alert you the moment a known flaw is published in a library you use. Wire those alerts into a regular patching routine, not a ticket queue nobody reads.

Lock the build pipeline and trim your dependencies

As Shai-Hulud showed, what attackers really want are the tokens and secrets sitting in your build environment. Give your continuous integration (CI/CD) pipeline only the minimum permissions it needs, keep publishing tokens narrowly scoped, and restrict scripts from reaching out to the internet freely where you can. At the same time, keep your dependency count deliberate: think twice before pulling in a whole library for a three-line job. A small set of well-maintained packages with a broad community behind them is safer than abandoned or one-person projects.

There is a fine balance here. Known vulnerabilities need to be patched quickly, but xz and Shai-Hulud both proved that the newest version can be the malicious one. The practical middle ground is to let a fresh release sit for a short cooldown before you take it into production, and to review automatic updates rather than merging them with your eyes closed.

At Wedevit we can map the dependencies inside the software you run, set up an SBOM and an automated scanning process, cut your build pipeline down to least privilege, and leave you with a setup where the next Log4Shell can be answered with "do we have it?" in minutes rather than days. Making the code you trust as visible as the code you write is one of the most concrete steps you can take right now.