A Software Bill of Materials (SBOM) is a machine-readable inventory of all components, libraries and dependencies in your software product. Modern applications rely for 70 to 90 percent on code someone else once wrote. If one of those building blocks breaks, your product breaks.
Since the CRA this is no longer a best practice but a legal requirement: with every release you must be able to produce an up-to-date, machine-readable SBOM (Annex I).
Two formats: SPDX and CycloneDX
You don't compile an SBOM by hand: mature open-source tools (such as Syft, Trivy or cdxgen) generate it automatically from your build. You only pick the format — there are two recognised standards, each with its own focus:
SPDX
Designed from a legal and compliance perspective (Linux Foundation). Unrivalled in licence detail. Officially ISO-certified and often required by governments.
CycloneDX
Designed by security engineers (OWASP). Lightweight and perfectly integrated into fast CI/CD pipelines. Offers native support for VEX documents.
The Transitive Iceberg
An SBOM that shows only the "direct" ingredients (the libraries your developers added explicitly) gives a false sense of security. As soon as you add one library, it drags in its own requirements. We call this transitive dependencies. A simple project with 5 libraries quickly explodes beneath the surface into a web of 500+ nested components. Your SBOM scanner must be able to map the full depth of this iceberg.
The Rescue: VEX (Vulnerability Exploitability eXchange)
VEX is an additional, machine-readable document that lives alongside the SBOM. In it you specify the actual status of a vulnerability. Is the status set to Not Affected (because the vulnerable code is never called)? Then your dashboard turns green and you filter out the noise. VEX enables your team to patch only what actually poses a risk to the end product.
Drowning in the noise
As soon as your SBOM is generated fully automatically, the next problem arises: the scanner raises the alarm. Often hundreds of "Critical" CVEs (vulnerabilities) are found in your thousands of transitive dependencies. Developers often import a huge library just to use 5% of the code (a single function). Is the vulnerability in the unused 95%? Then your application is not exploitable (unreachable).
Two techniques do the heavy lifting. Reachability analysis checks whether the vulnerable code sits in an active code path at all; VEX records, per vulnerability, whether your product is actually affected. Switch them on below and watch a typical list of nearly 500 alerts shrink to the handful that truly matter:
How much noise is in your pipeline?
Find out in two minutes how mature your SBOM and VEX approach is with the free Quickscan, or build it step by step in the 4-week Survival Challenge.