SBOM procurement requirements: contract clauses and a supplier checklist
Asking suppliers for "an SBOM" produces documents of every shape and quality. Specific contract terms produce SBOMs you can use. This guide lists the terms to cover and a checklist for supplier assessment.
- CERT-In recommends SBOM requirements in all public-sector software procurement, and SEBI expects them for regulated entities' critical software.
- Specify format, version, field baseline, depth and delivery points, not just 'provide an SBOM'.
- Cover updates, VEX and advisories for the life of the contract, not only at delivery.
- Agree confidentiality, signing and an exception process for components the supplier cannot disclose.
Why procurement is the lever
For software you buy, the contract is where transparency is won or lost. CERT-In recommends that government, public-sector and essential-services organisations include SBOM requirements in all software and solution procurement, and that software supplied to them be accompanied by a complete SBOM [1]. SEBI's CSCRF FAQs require SBOMs for third-party software supporting core and critical operations, and ask for board approval where a vendor cannot provide one [2]. Contract terms make these expectations enforceable.
Clauses to cover
| Topic | What to specify |
|---|---|
| Delivery points | An SBOM with the initial delivery and with every release, patch and upgrade. NTIA's minimum elements require a new SBOM for each new build or release [3]. |
| Format and version | SPDX or CycloneDX, as named by CERT-In [1], with minimum versions you can process |
| Field baseline | The 21 CERT-In fields, or another named baseline such as the CISA 2026 Minimum Elements [4] |
| Depth | A complete SBOM including transitive dependencies; explicit declaration of known unknowns [3] |
| Lifecycle type | Which type is supplied (for example build or analysed) and, for hosted services, the runtime production environment. U.S. OMB guidance of February 2026 makes the same point for cloud providers [5]. |
| Integrity | Digitally signed SBOMs, as CERT-In recommends for shared documents [1], and hashes that match delivered artefacts |
| Vulnerability communication | VEX statements using the four standard statuses and a justification for "not affected" [6]; CSAF advisories for affected products [1] |
| Timeliness | Agreed response times for VEX after a relevant vulnerability is published, particularly for known-exploited vulnerabilities |
| EOL notice | Advance notice when components reach end of life, to populate the EOL field |
| Confidentiality | How SBOMs are shared, stored and protected. CERT-In recommends encryption and access controls [1]. |
| Redaction | Redaction only where contractually agreed, with the component marked as redacted rather than omitted, in line with CISA's framing guidance [7] |
| Flow-down | Integrators obtain SBOMs from their own suppliers and deliver an aggregated SBOM |
| Verification | The buyer's right to validate SBOMs and compare them with independent analysis |
| Remedy | A period to correct non-conforming SBOMs, and the consequence if they are not corrected |
Supplier assessment checklist
Use these questions in RFPs and vendor due diligence:
- Do you generate SBOMs automatically for every release? At which lifecycle stage?
- Which formats and versions can you deliver?
- Can you populate all 21 CERT-In fields? Which fields will be incomplete, and why?
- Do your SBOMs include transitive dependencies? How do you mark unknowns?
- Do you sign SBOMs? How can we verify the signature?
- Do you publish VEX and CSAF advisories? What is your response time?
- How will you deliver SBOMs: portal, API, or with release artefacts?
- Do you obtain SBOMs from your own suppliers?
- For SaaS, will you provide an SBOM of the production environment?
- Can you also supply a CBOM, AIBOM or HBOM where relevant?
Acceptance and ongoing management
Make SBOM validation part of delivery acceptance, so non-conforming SBOMs are rejected before payment milestones rather than discovered in an audit. See how to validate an SBOM. Track supplier performance over time: receipt rate, validation pass rate and VEX response times. Where a supplier cannot provide an SBOM, for example for legacy software, record the exception, the rationale and compensating controls; SEBI-regulated entities need board-level approval for this [2].
For the wider context, see SBOM compliance and, for public buyers, SBOM for government.
How IntelliXBOM helps
IntelliXBOM validates supplier SBOMs in CycloneDX and SPDX against the field policy written into your contracts, keeps each delivery's version history, and records VEX decisions. Results are mapped to framework controls with timestamped evidence, which supports acceptance decisions and supplier reviews.
This article summarises public guidance for information only and is not legal advice; refer to the current official documents before acting.
Frequently asked questions
What should an SBOM clause in a software contract include?
At minimum: delivery with every release, format and version, a named field baseline, complete depth including transitive dependencies, signing, VEX and advisory obligations, confidentiality terms and a remedy for non-conforming SBOMs.
Can a supplier refuse to share an SBOM for confidentiality reasons?
Suppliers may ask to restrict access or redact specific components. Agree confidentiality terms and require redacted components to be marked rather than silently omitted; where no SBOM is available, record a formal exception.
Should SaaS providers supply SBOMs?
SEBI's CSCRF FAQs include SaaS applications in scope for core and critical operations. Ask for an SBOM that describes the production environment running your service.
Sources
- Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, Version 2.0 (9 July 2025)CERT-In, Government of Indiawww.cert-in.org.in/PDF/TechnicalGuidelines-on-SBOM,QBOM&CBOM,AIBOM_and_HBOM_ver2.0.pdf
- Frequently Asked Questions (FAQs) on Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities (June 2025)SEBIwww.sebi.gov.in/sebi_data/faqfiles/jun-2025/1749647139924.pdf
- The Minimum Elements for a Software Bill of Materials (full report, PDF)NTIA, U.S. Department of Commercewww.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf
- CISA Releases the 2026 SBOM Minimum ElementsFOSSAfossa.com/blog/cisa-releases-2026-minimum-sbom-elements/
- OMB Rescinds Biden-Era Software Security Requirements, Directs Agency-Led and Risk-Based Approach (February 2026)Davis Wright Tremainewww.dwt.com/blogs/privacy--security-law-blog/2026/02/omb-changes-course-on-software-security
- Minimum Requirements for Vulnerability Exploitability eXchange (VEX), April 2023CISAwww.cisa.gov/sites/default/files/2023-04/minimum-requirements-for-vex-508c.pdf
- CISA Releases Guidance on Minimum Expectations for Software Bill of MaterialsCovington & Burling, Inside Government Contractswww.insidegovernmentcontracts.com/2024/11/cisa-releases-guidance-on-minimum-expectations-for-software-bill-of-materials/
Sources checked in September 2026. Regulations and guidance change; always refer to the issuing body’s current publication. This content is for general information and is not legal advice.