What is an SBOM? A practical guide to the Software Bill of Materials

A Software Bill of Materials is the ingredient list for software. This guide explains what it contains, which baselines define it, how it is produced and why it only delivers value when it is maintained.

A plain definition

A Software Bill of Materials (SBOM) is a formal record of the components used to build a piece of software and the supply-chain relationships between them. U.S. Executive Order 14028 defines it as "a formal record containing the details and supply chain relationships of various components used in building software" and compares it to the ingredient list on food packaging ^[1]. India's CERT-In uses the same framing in its bill-of-materials guidelines, where the SBOM is the foundation for the cryptographic, quantum, AI and hardware BOMs that follow ^[2].

The idea comes from manufacturing. A car maker knows which supplier produced each part in each vehicle, so a recall can be targeted. Most organisations cannot say the same about the libraries, packages and runtimes inside their applications, even though those components are where many vulnerabilities and licence obligations sit.

Why SBOMs matter now

Modern applications are mostly assembled rather than written. A service declares a set of direct dependencies, and each of those pulls in further, transitive dependencies. When a serious flaw is disclosed in a widely used library, the first question for every security team is: are we affected, and where?

Log4Shell (CVE-2021-44228), disclosed in December 2021, is the reference case. The vulnerable logging library was often present only as a transitive dependency, and the flaw is listed in CISA's Known Exploited Vulnerabilities catalogue ^[3]. Teams with accurate inventories could search them; others had to scan and ask suppliers system by system.

Policy followed. Executive Order 14028 (May 2021) directed the publication of minimum SBOM elements and listed "providing a purchaser a Software Bill of Materials (SBOM) for each product" among secure-development practices ^[1]. In India, CERT-In's guidelines state that software supplied to government, public-sector and essential-services organisations must be accompanied by a complete SBOM ^[2], and SEBI's CSCRF requires SBOMs for software supporting core and critical activities of regulated entities ^[4]. The EU Cyber Resilience Act requires manufacturers to draw up an SBOM "covering at the very least the top-level dependencies" ^[5]. See SBOM compliance for the full regulatory picture.

What goes into an SBOM

The NTIA's 2021 report defined the first common baseline, in three parts: data fields, automation support and practices and processes ^[6]. Its seven data fields were supplier name, component name, version, other unique identifiers, dependency relationship, author of SBOM data and timestamp ^[7].

On 30 July 2026, CISA published the 2026 Minimum Elements for an SBOM with the NSA, the FBI and international partner agencies ^[8]. As summarised by FOSSA, it separates seven SBOM metadata elements from ten component elements, adding items such as the SBOM author's signature, the generating tool's name and version, the generation context, the component hash value and algorithm, and component licence ^[9].

CERT-In's list is the broadest because it includes operational attributes that change after release. Our field-by-field guide to the 21 CERT-In fields explains each one and where to source it.

Depth, coverage and "known unknowns"

An SBOM is only as useful as its coverage. The NTIA report set the minimum as all top-level dependencies, with enough detail to find transitive ones, and asked authors to state explicitly where the dependency graph is incomplete rather than leave gaps silent ^[6]. The 2026 CISA elements go further: an SBOM should cover all components including transitive dependencies, with no minimum depth ^[9]. CERT-In describes SBOM levels from top-level through n-level, delivery and transitive to complete ^[2].

Formats: CycloneDX and SPDX

Two open standards dominate, and both are named by CERT-In ^[2] and by the 2026 CISA guidance ^[9]:

• CycloneDX (OWASP), standardised as ECMA-424 in June 2024 ^[10]. Version 1.7 was released in October 2025 ^[11]. It covers software, services, hardware, cryptography and machine-learning BOMs as well as VEX, in JSON, XML and Protocol Buffers ^[12].
• SPDX (Linux Foundation). SPDX 2.2.1 is published as ISO/IEC 5962:2021, and SPDX 3.0, released in April 2024, adds profiles including Security, Build, AI and Dataset ^[13].

Most organisations accept both from suppliers and normalise internally. Our CycloneDX vs SPDX comparison covers the differences.

SBOM types across the lifecycle

An SBOM describes software at a particular stage. CISA's 2023 guidance distinguishes six types, which CERT-In adopts as classifications ^[14][2]:

The 2026 CISA elements require the generation context to be recorded for this reason ^[9]. See SBOM generation for how each type is produced.

SBOM, VEX and the other BOMs

An SBOM that lists a vulnerable component does not by itself mean the product is exploitable. A Vulnerability Exploitability eXchange (VEX) statement records that judgement using four statuses: not affected, affected, fixed and under investigation ^[15]. CERT-In recommends that suppliers issue VEX when a vulnerability is discovered and follow it with a CSAF advisory ^[2][16]. The relationship is covered in SBOM vs VEX.

The SBOM also anchors other inventories. A CBOM lists cryptographic assets, a QBOM addresses quantum-related components, an AIBOM describes models and datasets, and an HBOM covers hardware. CERT-In's Version 2.0 guidelines define minimum elements for all five ^[2].

Making SBOMs operational

Many organisations that "have SBOMs" have a folder of JSON files. Value appears when SBOMs are governed:

1. Generate automatically for every release. The NTIA report states that a new build or release needs a new SBOM ^[6].
2. Require SBOMs from suppliers and validate them on intake against a field policy; see SBOM validation.
3. Keep version history so you can answer "what changed since the last release?"
4. Correlate continuously with new advisories, known-exploited lists, licence policy and end-of-life data.
5. Attach business context such as owner, application and criticality.
6. Record VEX decisions so the same finding is not triaged repeatedly.

These practices are covered in SBOM management.

How IntelliXBOM helps

IntelliXBOM generates and ingests SBOMs in CycloneDX and SPDX, validates them against required-field policies such as the CERT-In list, and keeps version history with diffs. It correlates components with vulnerabilities, known-exploited lists, licences, end-of-life data and business services, records VEX decisions, and maps the inventory to framework controls with timestamped evidence. It runs self-hosted, including in air-gapped environments.