SBOM

What goes into an SBOM

The original US baseline is the NTIA's 2021 Minimum Elements for a Software Bill of Materials. For each component, an SBOM records:

• Supplier: who created or maintains the component
• Component name and version
• Other unique identifiers, such as a package URL (purl) or CPE
• Dependency relationship: which component pulls in which
• Author of the SBOM data and a timestamp for when it was produced

In July 2026, CISA, the NSA and international partners published the 2026 Minimum Elements, which replaces that baseline. It adds fields that make an SBOM easier to verify and act on, including a cryptographic hash of each component, its license, the tool that generated the SBOM and the generation context (whether it was produced from source, during the build or from the finished artifact).

SBOM formats: SPDX and CycloneDX

Two open standards cover almost every SBOM in use:

• SPDX, maintained by the Linux Foundation and published as ISO/IEC 5962. It grew out of license compliance and is strong on licensing detail.
• CycloneDX, created at OWASP and standardized by Ecma International as ECMA-424. It was built for security use cases and also describes services, vulnerabilities and VEX statements.

Both are machine-readable (JSON, XML and others), and most tools can produce either. Pick the one your customers or regulators ask for.

Types of SBOM

When an SBOM is produced changes what it can tell you. CISA describes six types:

Type	Produced from	What it reflects
Design	Plans or requirements	Software that doesn't exist yet
Source	The repository and its manifests	What the code declares it depends on
Build	The build process	What was actually pulled in and compiled
Analyzed	Scanning a finished artifact or image	What an outside tool can detect inside it
Deployed	The installed system	What was shipped to an environment
Runtime	The running system	What is loaded and executing

A source SBOM can miss a dependency that only resolves at build time; an analyzed SBOM can miss what a scanner doesn't recognize. A build SBOM, generated in CI/CD from what the build actually used, is usually the most accurate record of what's inside an artifact.

Who requires SBOMs

• US federal government: Executive Order 14028 (May 2021) made SBOMs part of federal software procurement, and agencies can ask suppliers for one.
• Medical devices: the FDA requires an SBOM in premarket submissions for networked ("cyber") devices.
• European Union: the Cyber Resilience Act requires manufacturers of products with digital elements to draw up an SBOM. Its vulnerability-reporting obligations began on September 11, 2026; the SBOM and other core requirements apply from December 11, 2027.
• Enterprise buyers: many security questionnaires and contracts now ask for an SBOM alongside a vulnerability disclosure policy.

How SBOMs are generated

Most teams generate SBOMs automatically in their CI/CD pipeline, so a new one is produced on every build. Open-source tools such as Syft, Trivy and cdxgen read lockfiles and manifests, or inspect a built container image, and output SPDX or CycloneDX. The SBOM is then stored alongside the artifact, often signed so that consumers can verify it hasn't been altered. For a worked example, see generating a CycloneDX SBOM in CI/CD.

Where SBOMs fall short

An SBOM is a document. It is accurate for one build at one moment, and it is out of date as soon as anything changes. That leaves the questions security teams actually get asked unanswered:

• Is it running? An SBOM says what's inside an artifact. It doesn't say whether that artifact is deployed, where, or since when.
• Which version is in production? Teams ship many builds a day. Matching the right SBOM to what's actually running is manual work.
• Does the vulnerability matter? A list of components with known CVEs produces a long backlog. VEX (Vulnerability Exploitability eXchange) statements help by recording which vulnerabilities don't affect a product, but someone has to write them.
• Is it trustworthy? Quality depends on when and how it was produced. Two tools run on the same artifact can disagree.

SBOMs and Crash Override

The board, an auditor or a regulator's reporting deadline all want the same thing: proof of what shipped, what's in it and where it's running. An SBOM is a document, and it's out of date almost as soon as it's produced. You don't need a better document; you need an answer.

Crash Override is AppSec for the AI era. The build sensor records what every artifact is, where it came from and what's inside it, and that record follows the artifact into production. Ask the data plane what's in any artifact, where it came from and where it runs, and the answer is current, because the evidence is a byproduct of normal builds. That's Continuous evidence: audit evidence on demand, with nobody pulled off the roadmap to assemble it.