SBOM Requirements: Minimum Elements, SPDX vs CycloneDX and Who Asks

SBOM requirements have moved from good practice to legal and contractual obligation. A software bill of materials is a structured, machine-readable list of the components that make up a piece of software: open-source libraries, third-party modules, their versions and how they depend on each other. When a vulnerability like Log4Shell is disclosed, an organisation with SBOMs can answer "which of our products and releases contain this component?" in minutes. Without them, the answer takes days of manual searching.

The EU Cyber Resilience Act requires manufacturers to draw up SBOMs, the US FDA requires them in premarket submissions for cyber devices, CISA publishes minimum elements, and CERT-In in India has issued technical guidelines that extend the idea to cryptography, AI and hardware. This guide explains what an SBOM must contain, the main formats, how to generate and share them, VEX, and the regulatory expectations that software companies now face.

What is an SBOM?

CISA describes an SBOM as a formal record containing the details and supply chain relationships of various components used in building software. Think of it as an ingredients list. It records each component's supplier, name, version and identifiers, and how components relate, for example which library depends on which.

An SBOM is not a list of vulnerabilities. Vulnerability status is a separate, changing piece of information that is matched against the SBOM. The Vulnerability Exploitability eXchange (VEX) format lets a producer state whether a known vulnerability in a listed component actually affects the product.

Types of SBOM

SBOMs can be produced at different points: design (planned components), source (from source code and manifests), build (from the build process, usually the most accurate), analysed (from a binary or artifact after the fact), deployed (from what is installed) and runtime (from what is loaded). Build SBOMs generated in the pipeline are generally the most reliable for software you produce.

History and why SBOMs became required

Modern software is mostly assembled from open-source and third-party components. Supply chain incidents, such as the SolarWinds compromise and the Log4Shell vulnerability in a ubiquitous logging library, showed that organisations often did not know what was inside the software they ran. US Executive Order 14028 (2021) directed the Department of Commerce to define minimum elements, and the NTIA published "The Minimum Elements for a Software Bill of Materials" in July 2021. CISA took over SBOM work and published a draft update of the minimum elements for comment in 2025.

The US Food and Drug Administration required SBOMs for cyber devices under section 524B of the Federal Food, Drug, and Cosmetic Act from 2023. The EU Cyber Resilience Act, adopted in 2024, made an SBOM part of manufacturers' vulnerability handling requirements. CERT-In published SBOM guidelines and later a version 2.0 covering additional bills of materials.

Who needs SBOMs?

• Manufacturers of products sold in the EU under the Cyber Resilience Act, for technical documentation and vulnerability handling.
• Medical device makers submitting cyber devices to the FDA, and software developers working under IEC 62304.
• Vendors to US federal agencies, where agencies and contracts may require SBOMs, including after OMB's 2026 change to software attestation policy, which left SBOM requests available to agencies.
• Vendors to Indian government and regulated sectors, where CERT-In guidelines and sector regulators encourage or require them.
• Any software company whose enterprise customers ask for component transparency in security reviews.

Minimum elements

The 2021 NTIA minimum elements fall into three areas:

Data fields

Field	Meaning
Supplier name	The entity that creates, defines and identifies the component
Component name	The name assigned by the supplier
Version of the component	Identifier used by the supplier to specify a change
Other unique identifiers	Such as a package URL (purl) or CPE, to look the component up in databases
Dependency relationship	That upstream component X is included in software Y
Author of SBOM data	Who created the SBOM
Timestamp	When the SBOM data was assembled

Automation support

SBOMs must be machine-readable in a widely used format, such as SPDX or CycloneDX, so tools can generate and consume them.

Practices and processes

Including frequency (a new SBOM for each new build or release), depth (at least top-level dependencies, with enough detail to find transitive ones), known unknowns (stating where information is incomplete), distribution and delivery, access control and accommodation of mistakes.

CISA's 2025 update

CISA's 2025 draft of the minimum elements proposes adding fields such as a component hash, licence information, the tool used to generate the SBOM, and the generation context (for example before build, during build or after build), and tightening expectations on coverage. At our last review the update was still described as a draft that had received public comment; check CISA's SBOM page for the final text.

Formats: SPDX and CycloneDX

	SPDX	CycloneDX
Steward	Linux Foundation; published as ISO/IEC 5962	OWASP; published as ECMA-424
Origins	Licence compliance, extended to security	Application security and supply chain risk
Strengths	Rich licence and provenance data; international standard	Security-focused features, VEX support, additional bills (services, hardware, machine learning, cryptography)
Typical use	Open-source compliance programmes, regulated industries	DevSecOps pipelines, vulnerability management

Both are accepted by most regulators and customers. Pick one as your primary output; many tools can export both.

Regulatory and government expectations

• EU Cyber Resilience Act: manufacturers must identify and document vulnerabilities and components, including by drawing up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies. Market surveillance authorities can request it; the CRA does not require making it public.
• US FDA: premarket submissions for cyber devices must include an SBOM covering commercial, open-source and off-the-shelf software components.
• US federal procurement: agencies may request SBOMs under their own risk-based policies, and CISA guidance describes how to share them.
• CERT-In (India): technical guidelines describe SBOM minimum elements and practices and extend them to cryptographic (CBOM), quantum readiness (QBOM), AI (AIBOM) and hardware (HBOM) bills of materials, for government, public sector and essential services organisations and their vendors.

How to implement SBOMs step by step

1. Pick a format (SPDX or CycloneDX) and a generation tool that supports your ecosystems (npm, Maven, Composer, pip, Go, containers).
2. Generate during the build in CI for every release, including container images and mobile apps.
3. Use unique identifiers (package URLs) so components can be matched to vulnerability databases.
4. Store SBOMs with each release, signed and versioned, so you can answer questions about old versions.
5. Feed SBOMs into vulnerability monitoring so new disclosures trigger alerts for affected products and releases.
6. Publish VEX statements when a vulnerable component is not exploitable in your product, to save customers investigation effort.
7. Decide how to share: on request, through a customer portal, or attached to releases, with access control where needed.
8. Include third-party and commercial components, asking suppliers for their SBOMs.
9. Review quality: check completeness, correct versions and known unknowns.

Receiving SBOMs from suppliers: what to check

Buying organisations increasingly ask vendors for SBOMs, and software companies ask the same of their own suppliers. A received SBOM is only useful if it is good enough to act on. Check:

• Which release it describes, and whether it matches the version you run.
• Format validity: it should parse in standard tools without errors.
• Identifiers: package URLs or CPEs present for most components, so they can be matched to vulnerability data.
• Depth: whether transitive dependencies are included or only top-level ones, and whether known unknowns are stated.
• Generation context: whether it came from the build or was reconstructed later from a binary.
• Update commitments: whether the supplier will send a new SBOM with each release and VEX statements when vulnerabilities are disclosed.

Write these expectations into contracts: format, timing, depth, delivery method, VEX and confidentiality. That turns SBOMs from a one-off document into a working part of supply chain risk management.

Documentation you will need

• SBOM policy: format, depth, frequency, storage and sharing.
• SBOMs per release, with signatures or hashes.
• Vulnerability monitoring records and VEX statements.
• Supplier SBOMs for third-party components.
• Licence review records if SBOMs support open-source compliance.

Assessment and certification

There is no SBOM certification. Quality is judged by customers and regulators, and by tools that check format validity, completeness and identifiers. Some organisations include SBOM generation in audits of secure development under ISO/IEC 27001 or SOC 2, or in OpenChain conformance for licence compliance.

Timeline and cost considerations

For most projects, adding SBOM generation to CI takes days rather than months, using open-source or commercial tools. The harder work is operational: keeping SBOMs per release, monitoring them continuously, issuing VEX statements, and covering legacy products and binaries without build access. Costs include tooling, storage, triage time and supplier management.

Benefits and the risk of not having SBOMs

SBOMs speed up vulnerability response, support licence compliance, make security reviews easier, and satisfy legal requirements in the EU and in regulated sectors. Without them, organisations scramble when a widely used component is found to be vulnerable, and may be unable to tell customers or regulators whether they are affected within the deadlines the CRA and other laws set.

Common mistakes and challenges for IT companies

• Generating SBOMs from manifests only, missing what is actually bundled.
• One SBOM per product instead of per release.
• No identifiers, so components cannot be matched to vulnerabilities.
• Producing SBOMs nobody monitors.
• Sharing raw SBOMs without VEX, leaving customers to chase irrelevant findings.
• Ignoring container base images and operating system packages.

Best practices, tools and technologies

• Generate SBOMs for source, build and container stages, and reconcile them.
• Sign SBOMs and attach them to release artifacts, following SLSA provenance practices.
• Use dependency tracking tools that ingest SBOMs and alert on new vulnerabilities.
• Maintain VEX documents alongside SBOMs.
• Combine SBOMs with licence policy checks and OpenChain processes.

We add SBOM generation and dependency monitoring to client pipelines as part of development and maintenance work.

How SBOMs relate to other frameworks

Framework	Relationship
Cyber Resilience Act	Legal requirement to draw up an SBOM for products on the EU market.
NIST SSDF	PS.3 asks producers to archive releases with provenance data such as SBOMs.
SLSA	Build provenance that complements SBOM component data.
OpenChain ISO/IEC 5230	Open-source licence compliance programmes that use SBOMs.
OWASP Top 10	Software supply chain failures (A03:2025) are addressed partly through SBOMs.
IEC 62304	Medical device software standard covering software of unknown provenance, documented through SBOMs.

Real-world implementation examples

During the Log4Shell response in December 2021, organisations with component inventories identified affected systems far faster than those without, a lesson repeatedly cited by CISA and others in promoting SBOMs. Major software vendors and open-source foundations now publish SBOMs with releases, and package registries and build platforms offer built-in SBOM generation.

An illustrative case for a SaaS company with an on-premises edition sold in Europe: under the CRA, the on-premises product needs SBOMs. The company adds CycloneDX generation to its CI for every release, stores signed SBOMs, connects them to a dependency monitoring tool, and publishes VEX statements for common false positives. When a critical vulnerability is announced in a popular library, it confirms within an hour which releases are affected and prepares the advisory and, if exploited, its CRA report.

Next steps

1. Choose a format and generation tool.
2. Add SBOM generation to every release pipeline.
3. Store and sign SBOMs per release.
4. Monitor SBOMs for new vulnerabilities and publish VEX.
5. Agree how you will share SBOMs with customers and regulators.

Frequently asked questions

What is an SBOM?

A machine-readable inventory of the components in a piece of software, with their suppliers, versions, identifiers and relationships.

Is an SBOM mandatory?

For products under the EU Cyber Resilience Act and FDA cyber device submissions, yes. In other settings it depends on contracts and customer requirements.

What is the difference between SPDX and CycloneDX?

Both are standard SBOM formats. SPDX, an ISO standard, started with licence compliance; CycloneDX, an Ecma standard from OWASP, started with security use cases. Both are widely accepted.

Do we have to publish our SBOM?

Not necessarily. The CRA requires manufacturers to draw it up and provide it to authorities on request; sharing with customers is usually by agreement.

What is VEX?

Vulnerability Exploitability eXchange, a way for producers to state whether a known vulnerability in a component affects their product.

How often should SBOMs be generated?

For every build or release, so that each version has an accurate record.

Does an SBOM include transitive dependencies?

Minimum guidance requires at least top-level dependencies with enough detail to identify transitive ones; good practice is to include the full dependency graph.

What does CERT-In require for SBOMs?

CERT-In's technical guidelines set out SBOM elements and practices, and extend them to cryptographic, AI and hardware bills of materials, especially for government and essential sector organisations and their suppliers.

Can SBOMs help with licence compliance?

Yes. Licence information in SBOMs supports open-source licence review and programmes such as OpenChain.

Are SBOMs confidential?

They can reveal architecture details, so many producers share them under agreement or through access-controlled portals. Regulators can request them under laws such as the CRA. Weigh transparency benefits against any sensitivity, and avoid including secrets or internal hostnames.

Which tools generate SBOMs?

Many open-source and commercial tools generate SPDX or CycloneDX from source manifests, build systems and container images, and most code hosting and CI platforms now offer SBOM export. Choose tools that support all the ecosystems you use.

Do SaaS products need SBOMs?

Pure SaaS is outside the CRA, but customers increasingly ask SaaS providers for SBOMs or equivalent component transparency, and generating them internally improves vulnerability response.