Software Supply Chain Security: Why Your Vendors and Libraries Are the Real Risk

The Software You Run Is Built on Hundreds of Pieces You Didn't Write

When a company commissions a custom application, it tends to picture the code as something its development partner writes from scratch, line by line, entirely under its own control. The reality looks very different. A modern web or mobile application is typically made up of 70 to 90 percent code that nobody on the development team actually wrote: open-source libraries, frameworks, third-party components, cloud services, and build tools, all assembled together. That's not a flaw — it's how software is built everywhere today, and it's the reason something that took years to build two decades ago can now be shipped in weeks. The trouble starts when nobody stops to ask what happens if one of those pieces, over which the company has no direct control, gets compromised.

This web of dependencies — libraries, packages, external services, build and deployment tooling — is what's now called the software supply chain. And it has quietly become one of the most exploited attack surfaces in the industry, precisely because compromising a single widely-used library can reach thousands of applications in one move, instead of forcing an attacker to breach each company one at a time.

What the Software Supply Chain Actually Is

The term sounds abstract, but it's simple once broken into layers. The first layer is direct dependencies: the libraries a development team deliberately chose to use, such as a UI framework or a payments library. The second layer is transitive dependencies: the libraries those libraries in turn need in order to work, often dozens or hundreds for every single direct dependency, and almost always invisible to whoever writes the application code. The third layer is build and deployment tooling: the systems that compile code, test it automatically, and push it to production, frequently hosted by outside vendors. The fourth layer is the third-party services an application calls at runtime — a payment gateway, an email delivery service, a mapping API, an authentication provider.

A mid-sized business application can easily depend, directly or transitively, on several hundred distinct external components. Each one is maintained by different people, with different security standards, with its own speed of response to vulnerabilities — and none of it sits under the direct control of the company that ultimately runs the finished software.

Why Dependencies Became a Favorite Attack Vector

From an attacker's point of view, going after a single company directly means beating that company's specific defenses one at a time. Compromising a single widely-used open-source library, or the distribution system behind a popular package, instead reaches every one of the thousands of applications that depend on it, with no need to attack each one separately. That multiplier effect has made the software supply chain an increasingly attractive target compared to a direct assault on one well-defended system.

The most common techniques follow recognizable patterns. Typosquatting involves publishing a package with a name almost identical to a popular one — a swapped letter, an extra hyphen — hoping a developer installs it by typo. Compromising a maintainer's account lets an attacker push a malicious version of a legitimate, widely trusted library, which then gets pulled automatically by thousands of build systems around the world. Attacks on the update mechanism itself target the infrastructure that distributes updates, so that even diligent companies that install every patch end up running malicious code while believing they applied a security fix. None of these techniques require breaching a company's firewall — they all exploit the implicit trust every development team extends, every single day, to code it never wrote.

The Hidden Risk for Companies That Commission Software, Not Just Those Who Write It

It's tempting to treat this as a purely technical problem that only concerns developers. It isn't. A company that commissions a custom application, or buys business software from an outside vendor, inherits the risk of that software's entire supply chain automatically, even if it never writes a single line of code itself. If the payment library your vendor relies on gets compromised, your customers' data is at risk regardless of whether your company ever chose that library or even knew it existed.

That creates a responsibility that's often overlooked during vendor selection. Many companies carefully evaluate a development partner's price, timeline, and portfolio, but rarely ask how that partner manages its own dependencies, how often it applies security patches, or whether it even maintains an inventory of what's actually included in the software it's building for them. It's the same kind of due diligence a company would naturally apply to a physical-parts supplier in a manufacturing chain, yet it's almost always skipped for software, despite carrying a comparable — or greater — risk.

What Good Supply Chain Hygiene Looks Like in Practice

Organizations that manage this risk well adopt a set of concrete practices, none of which are exotic or prohibitively expensive. The starting point is the SBOM (Software Bill of Materials): a complete, kept-current inventory of every component, library, and version present in an application, much like the ingredient list on a food label. Without an SBOM, it's simply impossible to know with confidence whether a newly discovered vulnerability in a popular library also affects your own systems.

• Automated vulnerability scanning. Tools that continuously check the dependencies in use against public databases of known vulnerabilities, flagging automatically when something in use has a documented security issue.
• Defined patching policies. A clear cadence for applying security patches, kept separate from and faster than the normal feature-release cycle, so a critical vulnerability never has to wait for the next planned release.
• Verifying package provenance. Confirming libraries come from official, verified repositories, rather than pulling code from unverified sources just because it's more convenient.
• Least privilege in build systems. Limiting what an automated build and deployment system is allowed to do, so that if it's ever compromised, the breach doesn't grant unrestricted access to the whole production environment.

None of these practices eliminate the risk entirely — no security discipline ever does — but together they sharply cut both the odds of being hit and the time it takes to discover and contain a problem once one occurs.

The Questions Worth Asking Your Software Vendor

A company without the in-house technical expertise to evaluate these practices directly can still protect itself by asking the right questions before signing a contract, and continuing to ask them periodically afterward. It's worth asking whether the vendor maintains an SBOM for the projects it manages, how often it scans dependencies for known vulnerabilities, how long typically passes between discovering a critical vulnerability and applying the corresponding patch, and whether it has a documented response process for the case where one of the libraries it uses gets compromised. A mature vendor will have precise, immediate answers to these questions; the absence of a clear answer is itself a telling piece of information.

It's also worth asking, specifically, what happens to systems already in production once the project wraps up and the initial development contract ends: who remains responsible for monitoring and updating dependencies over time, and under what arrangement. It's exactly in this phase — after launch, when attention shifts elsewhere — that supply chain maintenance most often gets neglected, not because nobody is meant to handle it in theory, but because nobody ever made it explicit, in practice, who should.

An Ongoing Risk, Not a One-Time Check

Software supply chain security isn't a project with an end date, any more than cybersecurity in general is. Libraries that are trustworthy today can be compromised tomorrow; a dependency once considered safe can stop being maintained and quietly accumulate unpatched vulnerabilities; a diligent vendor today can shift priorities or staff without the client ever noticing. Treating supply chain vetting as a one-time check performed when a contract is signed gives a false sense of security that fades over time exactly as the real risk keeps building.

Companies that manage this risk well are the ones that treat it as an ongoing discipline: a kept-current inventory, continuous monitoring, and an explicit, recurring conversation with whoever builds or maintains their software about what's actually inside that application, and who is paying attention to keeping it safe. It isn't a technical question reserved for specialists — it's a business question that every company depending on software, which in practice means virtually every company, should be asking as routinely as it checks its own books.