SBOM (Software Bill of Materials)

What Does an SBOM Actually List?

A software bill of materials (SBOM) is a formal record of the components inside a piece of software and the supply chain relationships between them, including open-source libraries and their versions. It works like an ingredients list for code. When a new flaw is disclosed in a component, an SBOM lets an organization determine whether that flaw affects software it runs.

The original baseline came from NTIA in 2021, which set seven data fields every SBOM should carry. Those fields are the supplier name, component name, version, other unique identifiers, dependency relationships, the author of the SBOM data, and a timestamp. The same guidance covered automation support and practices for SBOM depth, frequency, and delivery.

The 2026 Minimum Elements Replaced the 2021 Baseline

In July 2026, CISA, the NSA, the FBI, and international partner agencies released the 2026 Minimum Elements for a Software Bill of Materials, which updates and replaces the NTIA document. The update adds fields including component hashes, license information, and details about the tool that generated the SBOM, and it applies the minimum elements to all software, including open-source, AI, and SaaS, while flagging AI- and cloud-specific elements as areas for future development.

Which SBOM Formats Matter?

SPDX and CycloneDX are the two SBOM formats named in the FDA's premarket cybersecurity guidance, and they're the formats teams adopt in practice for the EU Cyber Resilience Act's SBOM requirement. Each comes from a different standards body:

• SPDX, maintained by the Linux Foundation and published as the international standard ISO/IEC 5962:2021, with roots in license compliance.
• CycloneDX, an OWASP Foundation project standardized as ECMA-424 in 2024, built around application security and vulnerability management.

Specifying an acceptable format in vendor contracts means every SBOM a risk team receives can be ingested by the same tools.

VEX Tells You Which Vulnerabilities Actually Apply

A Vulnerability Exploitability eXchange (VEX) document is a companion to an SBOM. It assigns a known vulnerability in a listed component one of four statuses, which are Not Affected, Affected, Fixed, or Under Investigation. A Not Affected status can carry a justification, such as the vulnerable code not being in the product's execution path. Without VEX, a vulnerability matched to a listed component gives no signal about whether the product is actually exposed.

How Is an SBOM Different From Software Composition Analysis?

Software composition analysis (SCA) is a process that identifies the components in software and their known vulnerabilities, and an SBOM is a document that records those components. A vendor runs SCA tooling as part of how it builds and maintains software. The SBOM is what it can share with customers afterward.

The distinction matters in vendor reviews. A vendor's statement that it runs SCA describes an internal practice. An SBOM it delivers is a record the buyer can keep and check against new vulnerability disclosures over time.

Why Are Regulators Asking Vendors for SBOMs?

SBOM requirements trace back to U.S. Executive Order 14028 in 2021, which led NTIA to publish the original minimum elements. Those elements became the reference point for federal software attestation guidance and for FDA medical device guidance, which ties SBOMs directly to government risk management.

The EU's Cyber Resilience Act goes further. From December 11, 2027, manufacturers of products with digital elements must maintain a machine-readable SBOM covering at least the product's top-level dependencies. For technology companies selling software into the EU, that makes an SBOM part of placing a product on the market.

How Should a Risk Team Use a Vendor's SBOM?

A vendor's SBOM is useful when a risk team checks it against new vulnerability disclosures, and that only works if the SBOM stays current. Teams can put an SBOM to work in four ways:

• Answer exposure questions fast, checking whether a newly disclosed vulnerability sits inside a vendor's product without waiting for a questionnaire reply.
• Evaluate software before purchase, reviewing components and their vulnerability history during due diligence.
• Spot risky dependencies, such as abandoned open-source projects or libraries with a record of critical flaws.
• Set an update cadence, requiring a refreshed SBOM with every major release.

Open-Source Components Extend Your Dependencies Past the Vendor

Open-source libraries inside a vendor's product carry the buyer's dependencies past the vendor it contracts with and into fourth-party territory. Black Kite's 2026 Supply Chain Vulnerability Report found that open-source software carries 14.42% of all OSINT-discoverable supply chain risk in its dataset. The report places that risk inside software dependencies, well before a finished product reaches a buyer's procurement review.

Ask for the SBOM Terms in the Contract

An SBOM request is easier to enforce when the contract spells out what a usable one looks like. The terms worth defining are format, depth, frequency, and companion data. That means an agreed format such as SPDX or CycloneDX, coverage of transitive dependencies as well as direct ones, a refreshed SBOM with every major release, and VEX statements for vulnerabilities the vendor has already assessed. CISA's 2026 guidance tells organizations to request SBOMs that satisfy the updated minimum elements, which gives contract language a published baseline.

What Can't an SBOM Tell You?

An SBOM describes what's inside the software, and it can't say on its own whether any of those components are exploitable in your environment. Two limits apply to every SBOM.

An SBOM Describes One Version of a Product

An SBOM records the components of a specific release. When a vendor ships a new release with different components, an older SBOM no longer matches what's running, so the value of an SBOM depends on how often the vendor refreshes it.

Depth Varies From One Vendor to the Next

The EU Cyber Resilience Act's minimum is top-level dependencies, so an SBOM can meet that bar without listing transitive dependencies, the libraries that other libraries pull in. Matching an SBOM against CVE records also flags vulnerable components without saying whether the vulnerable code is reachable, which is the gap VEX exists to close.

How Does Black Kite Analyze the Components Inside Third-Party Software?

Black Kite’s Product Analysis module includes SBOM analysis for vendor software with public-facing open-source repositories. It discovers those repositories through OSINT, generates SBOMs in CycloneDX and SPDX formats, and analyzes the components and dependencies for known CVEs and outdated libraries. It combines that with CPE analysis of downloadable software and SaaS subdomain analysis to assess software supply chain risk at the product level. That matters because a strong overall vendor rating doesn't guarantee the security of each product the vendor offers.

Product Analysis supports technical evaluation of a product's components and vulnerability history before procurement, and it points to specific mitigation actions such as product upgrades and configuration changes. It's one layer of a broader supply chain cyber risk management program, and related resources sit in the cyber risk intelligence knowledge center.

See also: Do You Sbom [Software Bill of Materials], Brah?