Modern software is assembled, not written from scratch. A typical product pulls in hundreds of open-source libraries, each with its own dependencies. A Software Bill of Materials (SBOM) is simply the ingredient list for all of it — a machine-readable inventory of every component you ship.
Why it suddenly matters
Two forces made the SBOM non-optional: supply-chain attacks and regulation. When a vulnerability like Log4Shell lands, the first question is "are we affected?" — and teams without an inventory spend days finding out. Regulations like the EU Cyber Resilience Act now require you to know and document what's inside your product.
The formats
- CycloneDX — security-focused, widely adopted, tooling-rich.
- SPDX — an ISO standard, strong on licensing.
Either is fine; pick one and be consistent.
Generate it in the build, not by hand
A hand-written SBOM is stale the moment a dependency updates. Generate it automatically as part of your build pipeline so it always reflects what you actually shipped — and regenerate it on every release.
An SBOM you can't keep current isn't evidence. The value is in it being true today, not the day you wrote it.
Generating a current SBOM and monitoring it for vulnerabilities is step one of Proofwright's CRA workflow.