Asking a supplier for "an SBOM" usually produces a one-off spreadsheet or a PDF that nobody can load into a scanner, and it is out of date by the next release. A useful request names the format, the fields, how often a new document arrives, how it is signed and delivered, what VEX statements come with it, and what happens when the supplier cannot supply something. This template gives you that request in a form you can send and paste into a contract: a tiering scheme, numbered requirement sections with [Organisation] placeholders, acceptance criteria, model contract wording and a short cover letter. It is built on the 2026 Minimum Elements for an SBOM published on 29 July 2026 by CISA and 17 partner agencies, and on the EU Cyber Resilience Act. It is for third-party risk, procurement, product security and vulnerability management teams. For what an SBOM is and how to run the pipeline that consumes it, see the SBOM Guide and SBOM operations.
How to use this template
- Customise: replace [Organisation], [Supplier], [Product], [n] and the bracketed choices. Keep section numbers so contract schedules and questionnaires can cross-refer.
- Tier first: section 2 says which sections apply to each supplier tier. A request that matches the supplier's role gets better data than a maximal one.
- Send before you sign: put sections 3 to 9 into the request for proposal, and section 10 into the contract or security schedule. A supplier that cannot meet them at tender rarely meets them later.
- Test what arrives: run the first delivery through section 9's acceptance checks and your SBOM tooling before accepting the deliverable.
- Have legal review it: the clauses are a starting text, not legal advice. Align them with your master agreement and the Third-Party Security Contract Clauses Template, whose section 6 this template expands.
1. Purpose and scope
1.1 [Organisation] requires software bills of materials (SBOMs) and vulnerability exploitability statements (VEX) from suppliers of software, firmware and software-containing devices so that it can determine, within [48 hours] of a new vulnerability being published, whether its deployed products are affected.
1.2 This requirement applies to [Product] and to every version, update, patch and configuration of it that is supplied to or operated for [Organisation], including embedded firmware, container images and on-premises components of hosted services.
1.3 Where [Product] is a hosted or software-as-a-service offering, the Supplier shall provide SBOMs for any agents, connectors, plug-ins or appliances installed in [Organisation]'s environment, and VEX or equivalent advisories for the hosted service.
2. Supplier tiers and sections to request
| Tier | Typical supplier | Sections to request | Delivery expectation |
|---|---|---|---|
| Tier 1: critical | Software in privileged, internet-facing or safety-relevant roles; identity, security, network and OT products | 3 to 10 in full | Signed SBOM per release, VEX per relevant CVE, contract clauses |
| Tier 2: important | Business applications holding sensitive data; on-premises agents | 3 to 7 and 9; section 10 clauses 10.1 to 10.4 | SBOM per major release and on request; VEX on request |
| Tier 3: standard | Low-impact desktop and utility software | 3, 4 and 6 | SBOM on request |
| Hosted only | SaaS with no installed component | 1.3, 7 and 10.5 | Advisories or VEX for the service; no SBOM of the hosted stack unless agreed |
3. Format and delivery
3.1 The Supplier shall provide each SBOM in a widely used, open, machine-processable format: SPDX (ISO/IEC 5962:2021 or a later SPDX release) or CycloneDX (ECMA-424; the second edition of December 2025 corresponds to CycloneDX 1.7), in JSON [or XML]. Spreadsheets, PDFs and screenshots do not satisfy this requirement.
3.2 The Supplier shall not use a format version that its maintainers have deprecated for new software, in line with the 2026 Minimum Elements.
3.3 Each SBOM shall be delivered by [one of: inclusion in the release package / a version-specific URL on the Supplier's portal / an API or repository that [Organisation] can poll], at the same time the corresponding software is made available to [Organisation].
3.4 Access controls on SBOM delivery shall not prevent [Organisation] from loading the SBOM into its own vulnerability management and SBOM tools or sharing it with its contractors bound by confidentiality.
4. Minimum content
4.1 Each SBOM shall contain, at a minimum, every data field in the 2026 Minimum Elements, populated for every listed component:
| Group | Field (2026 Minimum Elements name) | What [Organisation] checks |
|---|---|---|
| SBOM metadata | SBOM Author | The entity responsible for the data, not the tool |
| SBOM metadata | SBOM Author Signature | Signature verifies against the Supplier's published key (section 8) |
| SBOM metadata | SBOM Data Format Name and SBOM Data Format Version | SPDX or CycloneDX, version not deprecated |
| SBOM metadata | SBOM Generation Context | Lifecycle phase stated (for example build or post-build analysis) |
| SBOM metadata | SBOM Timestamp | Present; the 2026 document points to RFC 9557 date and time format |
| SBOM metadata | SBOM Tool Name and SBOM Tool Version | Present for each tool that generated or amended the SBOM |
| SBOM metadata | SBOM Version | Changes on every revision |
| Component | Component Name, Component Version, Component Producer | Present for every component; Component Producer replaces the 2021 Supplier Name |
| Component | Component Identifiers | At least one per component; [Organisation] requires a purl for open source packages and a CPE where one exists |
| Component | Component Hash Algorithm and Component Hash Value | Approved algorithm (for example SHA-256); hash of the shipped artefact |
| Component | Component License | SPDX licence identifiers |
| Component | Component Dependency Relationship | Dependency graph present, not a flat list |
4.2 For devices and appliances, the Supplier shall in addition list firmware images and their versions. See the Hardware and Firmware SBOM Guide.
4.3 [Optional] The Supplier shall disclose cryptographic libraries and algorithms in use, either within the SBOM or as a cryptographic bill of materials. See the Cryptographic Inventory and CBOM Guide.
5. Coverage and unknowns
5.1 Each SBOM shall list all components, including transitive dependencies, with no minimum depth, so that [Organisation] can determine whether a newly reported vulnerability affects [Product]. This exceeds the CRA floor, which covers at least the top-level dependencies.
5.2 Where the Supplier does not know a component's dependencies or a field value, the SBOM shall say so explicitly, and shall distinguish information that is unknown from information deliberately withheld. A missing field without that statement is a defect.
5.3 Where security-relevant information is withheld, the Supplier shall name a contact and process through which [Organisation] can request it under confidentiality.
6. Frequency and update triggers
6.1 The Supplier shall provide a new SBOM for every release, version, patch, hotfix and container image rebuild of [Product] supplied to [Organisation].
6.2 The Supplier shall issue a revised SBOM, with an incremented SBOM Version, within [10 business days] of discovering an error or new component details, and shall notify [Organisation] of the revision.
6.3 On request, the Supplier shall provide within [5 business days] the SBOM for any version of [Product] that [Organisation] still runs, for at least the support period of that version.
| Trigger | Deliverable | Deadline (suggested) |
|---|---|---|
| New release, patch or image | New SBOM | With the release |
| Error or new component data found | Revised SBOM | [10] business days |
| Critical or known-exploited CVE in a listed component | VEX status for each supported version | [2] business days; "under investigation" is acceptable as a first status |
| Request for an older supported version | Existing SBOM | [5] business days |
| Contract renewal | Confirmation that sections 3 to 9 are still met | Before renewal |
7. VEX and vulnerability statements
7.1 For [Tier 1] products, the Supplier shall publish VEX statements in [CSAF 2.0 / OpenVEX / CycloneDX] format stating, per product version and vulnerability, one of: not affected, affected, fixed or under investigation.
7.2 Every "not affected" statement shall carry a machine-readable justification (for example component not present, vulnerable code not present, vulnerable code not in execute path, vulnerable code cannot be controlled by adversary, or inline mitigations already exist) and, where helpful, an impact statement.
7.3 Every "affected" statement shall carry an action statement: the fixed version, a workaround, or a mitigation and its date.
7.4 The Supplier shall update an "under investigation" statement as soon as analysis completes, and in any case within [10 business days], and shall increment the VEX document version on every change.
7.5 VEX documents shall be signed or delivered through the same authenticated channel as the SBOM. Where the Supplier does not issue VEX, it shall provide a security advisory with equivalent per-version status. CISA notes that whether and when to issue VEX is a business decision for most suppliers, which is why [Organisation] makes it a contract term rather than an assumption. See the VEX Guide.
8. Integrity, authenticity and confidentiality
8.1 Each SBOM shall carry an SBOM Author Signature using an algorithm approved for secure use (the 2026 Minimum Elements cite the NIST Digital Signature Standard and ISO/IEC 14888-4:2024), created with the Supplier's existing signing infrastructure and key management.
8.2 The Supplier shall publish the verification key or certificate through [its website / a transparency log / a channel agreed in writing] and notify [Organisation] in advance of key rotation, and immediately of key compromise.
8.3 Where the SBOM is generated during the build, the Supplier shall bind it to the release artefact by hash and [where available] provide build provenance attestations. See the in-toto Attestations Guide.
8.4 [Organisation] shall treat SBOMs as confidential supplier information, limit access to staff and contractors with a need to know, and use them only for security, vulnerability management, licence compliance and regulatory purposes.
8.5 Accounts and API tokens used to retrieve SBOMs from a supplier portal shall be dedicated, read-only service identities owned by [Organisation]'s SBOM function, rotated at least [every 90 days] and removed when the contract ends.
9. Acceptance criteria
9.1 [Organisation] will accept an SBOM delivery only if it passes the following checks; failed deliveries are returned with the reason and a corrected SBOM is due within [10 business days].
| Check | Pass condition | Typical failure |
|---|---|---|
| Schema validity | Validates against the declared SPDX or CycloneDX schema version | Hand-edited JSON; unsupported version |
| Signature | Verifies against the published Supplier key | Unsigned; signed by a build tool account, not the Supplier |
| Product match | Product name, version and artefact hash match what was delivered | SBOM for a different build |
| Field completeness | Required fields present for at least [95]% of components; gaps explicitly marked unknown or withheld | Silent gaps in licence and hash fields |
| Identifier quality | Open source components carry a purl | Name and version only, which cannot be matched reliably |
| Coverage | Transitive dependencies present; dependency graph not flat | Top-level list only |
| Freshness | SBOM Timestamp and SBOM Version correspond to the release | Same SBOM reused across releases |
10. Contract wording
10.1 Delivery obligation. "The Supplier shall deliver to [Organisation] a software bill of materials for each version of the Product supplied under this Agreement, meeting the requirements of Schedule [X] (Supplier SBOM Requirements), at the time that version is made available."
10.2 Standard of content. "Each SBOM shall contain, at a minimum, the data fields and satisfy the practices described in the 2026 Minimum Elements for a Software Bill of Materials, or any successor publication notified by [Organisation] with [90] days' notice."
10.3 Updates and corrections. "The Supplier shall correct errors in, and issue revised versions of, any SBOM within [10] business days of becoming aware of the error or of new component information."
10.4 Vulnerability status. "Within [2] business days of a vulnerability rated critical, or listed in the CISA Known Exploited Vulnerabilities catalog, being published against a component listed in an SBOM, the Supplier shall provide a VEX statement or advisory for each supported version of the Product."
10.5 Hosted services. "For hosted services, the Supplier shall notify [Organisation] whether the service is affected by a vulnerability that [Organisation] identifies, within [2] business days of a written request."
10.6 Regulatory support. "Where the Product is a product with digital elements under Regulation (EU) 2024/2847, the Supplier shall make its SBOM available to [Organisation] to the extent needed for [Organisation] to meet its own obligations, and shall inform [Organisation] where the SBOM can be accessed."
10.7 Remedies. "Repeated failure to meet Schedule [X] shall be a material breach for which [Organisation] may [withhold acceptance / apply service credits / terminate] in accordance with clause [Y]."
10.8 Flow-down. "The Supplier shall obtain from its own suppliers the component information it needs to meet Schedule [X] and shall not rely on their non-cooperation as grounds for omitting information without marking it unknown under section 5.2."
11. Cover letter
"Dear [Supplier contact], [Organisation] is updating how it manages software supply chain risk. For [Product], we are asking all [Tier] suppliers to provide software bills of materials and vulnerability status statements as set out in the attached Supplier SBOM Requirements (sections [list]). Please confirm by [date] which requirements you can meet today, the formats and delivery channel you will use, and your timetable for any gaps. Please send a sample SBOM for your current release so our tooling can validate it. Contact [name, role, email] with questions. Thank you, [Name], [Role]."
Implementation guidance
- Start with the tier 1 list: send the request to your critical suppliers first, ideally at renewal, and record each response in the third-party risk register.
- Prove ingestion before scaling: load the first sample from each supplier into your SBOM platform and confirm you can answer "which products contain component X at version Y?" before requesting more. See the SBOM management platform buyer's guide.
- Accept partial compliance with dates: record gaps as findings with an agreed remediation date rather than refusing to buy; tighten to full acceptance at the next renewal.
- Exercise it: when the next widely reported open source vulnerability lands, time how long it takes to get VEX statements from tier 1 suppliers. That is the measure the whole request exists for.
- Review the template yearly: the 2026 Minimum Elements replaced the 2021 baseline and renamed fields; the CRA allows the Commission to specify SBOM format and elements in implementing acts under Article 13(24). Update section 4 when either moves.
Regulatory context: the CRA requires manufacturers to draw up an SBOM in a commonly used, machine-readable format and to provide it to market surveillance authorities on reasoned request; sharing it with users is the manufacturer's choice. The regulation applies from 11 December 2027, with Article 14 reporting obligations from 11 September 2026. A contract is therefore still how most customers obtain SBOMs. See the EU Cyber Resilience Act Guide.
Metrics
| Metric | Definition |
|---|---|
| Tier 1 SBOM coverage | Share of tier 1 products in production with a current, accepted SBOM |
| First-pass acceptance rate | Share of deliveries passing section 9 checks without return |
| VEX response time | Median days from critical CVE publication to supplier VEX status |
| Contract coverage | Share of tier 1 and 2 contracts containing clauses 10.1 to 10.4 |
Framework mapping
| Framework | Reference |
|---|---|
| NIST CSF 2.0 | GV.SC-05 (requirements in supplier contracts), GV.SC-07 (supplier risk monitored over the relationship), ID.RA-01 (vulnerabilities identified) |
| NIST SP 800-53 Rev 5 | SA-4 Acquisition Process, SR-3 Supply Chain Controls and Processes, SR-4 Provenance, SR-5 Acquisition Strategies, Tools, and Methods, RA-5 Vulnerability Monitoring and Scanning |
| ISO/IEC 27001:2022 Annex A | 5.20 Addressing information security within supplier agreements; 5.21 Managing information security in the ICT supply chain |
| MITRE ATT&CK | T1195.001 and T1195.002, the supply chain compromises that SBOM and VEX help scope |
Standards and references
- CISA and partner agencies: 2026 Minimum Elements for a Software Bill of Materials
- EUR-Lex: Regulation (EU) 2024/2847, Cyber Resilience Act
- Ecma International: ECMA-424, CycloneDX Bill of Materials Specification
- OASIS: Common Security Advisory Framework Version 2.0
- OpenVEX: OpenVEX Specification
- CISA: When to Issue VEX Information
Related NHI Mgmt Group resources: SBOM Guide · VEX Guide · Software Supply Chain Security Buyer's Guide · Security for Procurement Teams Guide · Third-Party Security Contract Clauses Template