Frequently Asked Question

What is an SBOM and why do regulators keep asking for one?

A Software Bill of Materials (SBOM) is a machine-readable inventory of every component that goes into a piece of software: the direct dependencies, the transitive dependencies they pulled in, the versions, the licences, and ideally the cryptographic hashes that identify each one. The two widely used formats are SPDX (Linux Foundation) and CycloneDX (OWASP), both JSON or XML, both supported by mainstream build tools and scanners.

The reason regulators ask for SBOMs is that you cannot patch what you do not know you are running. When CVE-2024-3094 (xz) or CVE-2021-44228 (Log4Shell) lands, every operator's first question is "do we have the vulnerable version anywhere in our stack?", and the only way to answer that quickly is a current, accurate inventory. The US Executive Order 14028 (2021) and the EU Cyber Resilience Act effectively mandate SBOMs for software sold to government and to many consumer markets.

For a Linux operator the practical work is to generate SBOMs at build time (syft, cyclonedx-cli, distribution-native tools like dpkg-query and rpm -qa), store them alongside the artefacts, and feed them into a vulnerability scanner (grype, Trivy, OpenSCAP) on a schedule. The SBOM is only as useful as the process that consumes it.