Software Composition Analysis and the SBOM

Look at a modern application by line count and the uncomfortable truth is that you wrote very little of it. The overwhelming majority is third-party dependencies — frameworks, libraries, and their transitive pulls — assembled from public registries. Software Composition Analysis exists because that borrowed code carries borrowed risk, and the day a critical vulnerability drops in a ubiquitous library, the only question that matters is one most organisations still cannot answer quickly: where are we running it?

SCA identifies the open-source and third-party components in your codebase and cross-references them against known-vulnerability databases — sources such as the National Vulnerability Database, the GitHub Advisory Database, and the Open Source Vulnerabilities (OSV) feed. It reads your manifests and lockfiles, resolves the full dependency tree, and reports which components carry disclosed CVEs, which versions fix them, and often which license each imposes.

Transitive dependencies are the whole problem

You choose your direct dependencies deliberately. You inherit their dependencies, and theirs, without ever naming them. A single library you added may pull dozens of packages you have never heard of — and the vulnerability that hits you is far more often in that transitive layer than in anything you selected. This is why reading a manifest by eye is useless: the risk lives several hops down, in the lockfile, where only a resolver can see it.

The SBOM: an inventory you can query

A Software Bill of Materials is a formal, machine-readable list of every component in a piece of software, with versions and relationships. Two formats dominate: SPDX and CycloneDX. An SBOM turns “are we affected?” from a frantic code search into a database lookup. US Executive Order 14028 pushed SBOMs from nice-to-have toward baseline expectation for software sold to the federal government, and the practice has spread from there.

• Generate SBOMs at build time. The build is the one moment you know exactly what went into the artefact; capture it then, per release.
• Store and version them. An SBOM is only useful if you can retrieve the one matching what is actually deployed.
• Feed them to continuous monitoring. A component that is safe today gets a CVE tomorrow; re-check standing SBOMs against new advisories rather than only scanning at build.

Reachability separates noise from risk

Not every vulnerable dependency is an exploitable one. A CVE in a function your code never calls is real but not reachable, and treating it with the same urgency as a live path is how backlogs become unworkable. Advanced SCA adds reachability analysis — checking whether your code actually invokes the vulnerable code path — to separate the handful you must fix now from the many you can schedule. The emerging VEX (Vulnerability Exploitability eXchange) format exists to record and share exactly that judgement: “we ship this component, and here is why this CVE does or does not affect us.”

Beyond vulnerabilities

SCA also surfaces license obligations — a copyleft license pulled in transitively can carry legal consequences a security team never thinks to check — and increasingly flags supply-chain signals like unmaintained packages, suspicious version jumps, and typosquatted names. The remit has widened from “known CVEs” to “what exactly did we assemble, and can we trust its provenance?”

An SBOM is discovery made durable: a standing answer to what your software is actually made of. The next critical library vulnerability is already written; whether it costs you an afternoon or a week comes down to whether you can list, in seconds, every place you run the affected code.