A software bill of materials (SBOM) is a machine-readable inventory of every component in a piece of software, including open-source and third-party dependencies, their versions, and their relationships. It is the supply-chain equivalent of an ingredients label: you cannot assess or remediate risk in components you cannot see. The two dominant formats are SPDX and CycloneDX, and the practical challenge in 2026 is less about generating a one-time SBOM than about keeping it continuously accurate as builds and dependencies change.
Frequently Asked Questions
What is an SBOM? An SBOM is a formal, machine-readable record listing the components that make up a software product, along with metadata such as version, supplier, license, and dependency relationships. It gives producers and consumers a shared inventory to reason about vulnerabilities, licenses, and provenance. Without one, answering "are we affected by this new CVE?" turns into a multi-week manual hunt rather than a query.
Why do SBOMs matter so much now? Log4Shell in 2021 made the cost of not having an inventory painfully concrete: organizations spent weeks just discovering where Log4j ran before they could patch. Since then, US Executive Order 14028 and follow-on CISA and NTIA guidance have pushed SBOMs from best practice toward baseline expectation, especially for software sold to government. The underlying driver is simple — you can only defend a supply chain you can enumerate.
What are the two main SBOM formats, SPDX and CycloneDX? SPDX (Software Package Data Exchange) is a Linux Foundation standard published as ISO/IEC 5962:2021, with strong roots in license compliance. CycloneDX is an OWASP standard designed with security use cases in mind, including native support for vulnerabilities, VEX, and services. Both are widely supported; many teams generate CycloneDX for security workflows and SPDX where license or procurement requirements call for it.
What are the NTIA minimum elements of an SBOM? The NTIA's minimum elements define a baseline: supplier name, component name, version, unique identifiers, dependency relationships, the author of the SBOM data, and a timestamp. They also cover practices like the depth and frequency of generation. Meeting the minimum elements is the floor, not the ceiling — a genuinely useful SBOM also carries license and provenance data.
How are SBOMs generated? SBOMs are produced by tools that resolve a project's dependency graph from manifests, lockfiles, and built artifacts, then emit the inventory in SPDX or CycloneDX. Generation can happen at build time from source, from a container image, or from a deployed system, and each vantage point yields slightly different results. Safeguard's SBOM Studio generates and ingests SBOMs automatically across the build pipeline so the inventory reflects what you actually ship.
What is the difference between the types of SBOMs? CISA describes several SBOM types tied to the moment of creation — source, build, analyzed, deployed, and runtime — and each captures a different truth. A source SBOM reflects declared dependencies, while a build SBOM captures what was actually compiled and linked, which can differ significantly. For supply-chain security, build- and artifact-derived SBOMs are usually the most trustworthy because they describe the real bits rather than intentions.
What is a purl and why does it appear in SBOMs?
A purl (package URL) is a standardized identifier that encodes an ecosystem, namespace, name, and version — for example pkg:npm/lodash@4.17.21. It gives components a portable, unambiguous name that tools can match against vulnerability data without guessing. Consistent identifiers are what make an SBOM machine-actionable rather than a static document.
Does having an SBOM mean I know my vulnerabilities? Not by itself. An SBOM is an inventory; it becomes security value only when analysis is layered on top to match components against known vulnerabilities and assess exploitability. This is where SBOMs and software composition analysis meet — the SBOM says what is present, and reachability-aware SCA says which of those components carry risk you can actually reach.
What is VEX and how does it relate to SBOMs? VEX (Vulnerability Exploitability eXchange) is a companion artifact that states whether a product is actually affected by a given vulnerability, and why. It lets a producer tell downstream consumers "component X is present but the vulnerable function is unreachable, so you are not affected." Pairing an SBOM with VEX prevents the flood of false-positive alerts that comes from matching CVEs to component versions with no exploitability context.
How do I keep an SBOM from going stale? A one-time SBOM is out of date the moment a dependency changes or a new CVE is disclosed. The fix is to generate SBOMs automatically on every build and to continuously re-evaluate stored inventories against fresh vulnerability data, rather than treating the document as a deliverable you produce once for an audit. Drift detection — comparing today's build against the last known-good inventory — flags unexpected component changes early.
How are SBOMs signed and trusted? Because an SBOM is only as trustworthy as its origin, teams increasingly sign SBOMs and attach them as signed attestations using tools like Sigstore/cosign and frameworks such as in-toto and SLSA. A signed attestation binds the SBOM to a specific artifact and build, so a consumer can verify it was not swapped or tampered with. Provenance and signing turn an SBOM from a claim into verifiable evidence.
Do I need SBOMs from my vendors, not just my own code? Increasingly, yes. Much of your risk lives in commercial and third-party software you did not build, and requesting SBOMs from suppliers extends visibility across the parts of your stack you cannot scan directly. Ingesting third-party SBOMs into a central store lets you answer a new CVE question across first-party and vendor software in one place.
Can SBOMs cover more than traditional software? Yes. The same standards now extend to containers, firmware, and machine learning systems — CycloneDX and SPDX have both added support for AI and dataset components, giving rise to the AIBOM (AI bill of materials). If your product embeds models, an SBOM strategy should account for those artifacts too, not just packages.
How does Safeguard help with SBOMs specifically? Safeguard treats the SBOM as a living, continuously updated inventory rather than a point-in-time snapshot. SBOM Studio generates SPDX and CycloneDX output, ingests vendor SBOMs, and detects drift, while Griffin AI reasons over the inventory to surface anomalies and prioritize real exposure. When a reachable vulnerability is confirmed, automated fix pull requests close the loop from inventory to remediation.
Register at app.safeguard.sh/register, or read the documentation at docs.safeguard.sh.