Why Your Dependencies Are an Attack Surface

A typical modern application pulls in hundreds, sometimes thousands, of third-party packages through its dependency tree. Almost none of that code was written by the team that ships the application, and almost all of it runs with the same trust and access as the code that was.

Known vulnerabilities in dependencies

The most straightforward supply chain risk is also the most common: a dependency with a publicly disclosed vulnerability that has not been updated. This is exactly what OWASP's "vulnerable and outdated components" category, covered in our OWASP Top 10 guide, is describing. The fix usually exists already, in a newer version. The gap is entirely in whether anyone applied it.

Leaked secrets in source

API keys, database credentials, and signing certificates committed directly into source code, sometimes in a commit history that was later "cleaned up" without realizing old commits remain accessible, show up constantly in supply chain reviews. Once a secret reaches version control history, rotating it is the only real fix. Deleting the file does not remove it from history.

Malicious or compromised packages

A smaller but more severe risk: a legitimate, previously trustworthy package gets compromised upstream, either through a maintainer account takeover or a malicious contribution that slips past review, and the malicious version gets pulled automatically by everyone who depends on it. This is rarer than an outdated dependency, but it has caused some of the most damaging incidents on record precisely because it bypasses every control an organization has over its own code.

CI/CD pipelines are part of the supply chain too

The systems that build and deploy your software are themselves a dependency, in every meaningful sense. A compromised build pipeline can inject malicious code into an otherwise clean codebase at build time, which is exactly the kind of software integrity failure OWASP calls out as its own category.

Testing for this deliberately

Supply chain review works best as an explicit phase, checking dependency manifests against known vulnerability databases, scanning source history for leaked secrets, and reviewing build pipeline configuration, rather than something a general web application test happens to notice in passing.