Software Composition Analysis & Supply Chain Security

Most of a modern application isn't code anyone on the team wrote — it's open-source libraries, and the libraries those libraries depend on, sometimes dozens of layers deep. Software composition analysis inventories all of it, matches every component against databases of known vulnerabilities, and flags the dependencies that need attention, because a team can't secure what it doesn't know it's running.

The supply chain adds a sharper edge to that problem: packages themselves can be tampered with or actively malicious, so a vulnerability doesn't have to be in code you wrote to become code you ship.

The problem it solves

A typical project pulls in a handful of direct dependencies and, transitively, hundreds more nobody explicitly chose or reviewed. New vulnerabilities surface in open-source packages constantly, and a codebase can go from clean to exposed overnight with no first-party code change at all. Tracking which packages, at which versions, carry known issues isn't something a person can do reliably at scale.

The risk isn't limited to accidental bugs, either. Attackers now target the supply chain directly — publishing malicious packages under names that look like popular ones, or compromising a legitimate package's publishing pipeline — so the dependency itself can be the attack.

How it works

A scanner builds a full dependency tree for the project — direct and transitive — and matches each package and version against vulnerability databases to flag known issues. Because open-source licenses carry legal obligations too, most tools also check license terms against policy and flag anything that would create exposure if shipped.

Beyond known vulnerabilities, supply-chain checks look for signs of tampering: a package that suddenly changed maintainer, added unusual install-time behavior, or was published under a name deliberately close to a popular one (typosquatting). Findings are typically exported as a software bill of materials — a standardized component inventory that increasingly doubles as required proof of what shipped.

Not every flagged vulnerability is actually reachable — plenty of code sits in a library at rest and never runs. Reachability analysis checks whether a vulnerable function is genuinely called, letting most theoretical findings be safely deprioritized in favor of the handful an attacker could reach. Like SAST, checks are wired into pull requests and builds so a newly introduced vulnerable package is blocked before merge rather than found after release.

SCA vs SAST

Both scan source code, but for different code. SAST hunts for mistakes in the logic your own team wrote. SCA looks at everything else the application pulls in, checking third-party components against known vulnerability and license data rather than analyzing custom logic at all. Neither substitutes for the other: a perfectly written application can still ship a critical vulnerability living entirely in a dependency, and no dependency scan catches a bug in your own team's code.

The supply chain includes your infrastructure

A dependency tree doesn't stop at the packages your code imports. The base image a container is built from pulls in an entire operating system and its libraries; a Terraform or Helm module pulls in someone else's infrastructure definition the same way an npm package pulls in code. All of it is inherited, transitive, and capable of shipping a vulnerability or a malicious change nobody on the team wrote — exactly the problem SCA exists to catch.

So the supply-chain remit has widened to match. Tools now inventory base-image layers and IaC modules alongside application dependencies, and some go further with cloud connectors or agentless scanning that ties a flagged component back to where it is actually running — overlapping with the cloud-native protection platforms (CNAPP) built for the infrastructure side. When two tools both claim the container and IaC layer, check what you already own before adding another.

Choosing one

Reachability and prioritization quality matter more here than almost anywhere else in application security, because raw vulnerability counts in dependencies are enormous and mostly not exploitable in context — a tool that can't tell you which findings are real cuts straight to a backlog nobody will finish. Ask how a candidate separates reachable from theoretical risk before judging it on database size alone.

License compliance matters disproportionately to organizations that redistribute software or work under strict legal review, and barely at all to others — decide which camp you're in first. Finally, weigh how well SBOM output matches what customers or regulators require, since that document increasingly appears in contracts and audits rather than staying an internal nicety.