SBOM and VEX Policy Template (CISA 2026, CycloneDX, SPDX)

SBOM and VEX Policy: [Organisation name]

Organisation policy for producing, consuming, signing, distributing and retaining software bills of materials (SBOMs) and vulnerability exploitability exchange (VEX) statements. Data fields and practices follow the joint CISA guidance 2026 Minimum Elements for a Software Bill of Materials (SBOM) (version 2.1, 29 July 2026), which updates and replaces the NTIA 2021 minimum elements. Formats: CycloneDX 1.7 (ECMA-424, 2nd edition, December 2025) and SPDX 3.0.1 (December 2024). VEX follows the CISA Minimum Requirements for VEX (April 2023) and is expressed in CycloneDX, the OASIS CSAF 2.0 VEX profile or OpenVEX v0.2.0. Appendix A maps every 2026 minimum element to CycloneDX 1.7 and SPDX 3.0.1 fields. Replace every [bracketed] value and every row marked Example. Worked examples use Corvid Commerce, a fictional SaaS company that also ships an on-premises point-of-sale agent and an open-source SDK. This is a documentation format, not legal advice.

Document control

Approvals

Revision history

Contents

• 1. Purpose and drivers
• 2. Scope and applicability
• 3. Roles and responsibilities
• 4. SBOM production
• 5. VEX and exploitability statements
• 6. Distribution and access
• 7. Consuming third-party SBOMs and VEX
• 8. Retention and records
• 9. Exceptions and risk acceptance
• 10. Compliance measurement
• 11. Review cycle
• 12. Related documents
• 13. Glossary and references
• Appendix A. Field mapping: CISA 2026 minimum elements to CycloneDX 1.7 and SPDX 3.0.1
• Appendix B. VEX status and justification mapping
• Standard and licence note

1. Purpose and drivers

1.1 Purpose

This policy makes software composition transparent, both for the software [Organisation name] ships and for the software it buys. It sets one organisation-wide rule set so that every product produces SBOMs with the same minimum content, signs them the same way, publishes VEX statements to explain vulnerability status, and keeps the records long enough to answer a customer, auditor or regulator about any supported version.

The policy has three outcomes. Know what we ship: for every released version, an accurate, signed, machine-processable component inventory exists and is retrievable. Answer "are we affected?" quickly: when a vulnerability is published, the security team can tell within hours which products and versions contain the component and can publish a VEX status. Know what we buy: third-party software that processes our data or runs in our environment comes with SBOM data that we validate and ingest.

1.2 Drivers

2. Scope and applicability

2.1 In scope and out of scope

2.2 Lifecycle

Each arrow is a control point covered by a numbered statement in sections 4 to 7.

3. Roles and responsibilities

3.1 Roles

3.2 RACI

R = responsible, A = accountable, C = consulted, I = informed.

4. SBOM production

The keywords MUST, MUST NOT, SHOULD and MAY are used as in RFC 2119 and RFC 8174 when written in capitals.

4.1 Formats and versions

• SBV-01 Every SBOM MUST be produced in a format that is open, machine-processable and widely supported. The approved formats are CycloneDX and SPDX, the two formats the 2026 minimum elements name as widely used.
• SBV-02 The primary format MUST be [CycloneDX 1.7] in JSON. Products MAY additionally publish [SPDX 3.0.1] in JSON-LD where a customer or regulator asks for it.
• SBV-03 Products MUST NOT emit a format version that its maintainer has declared deprecated. The policy owner reviews supported versions at each review (section 11). At the time of writing CycloneDX 1.7 is current (Ecma published ECMA-424 2nd edition in December 2025; specification patch 1.7.2 was tagged in September 2026) and SPDX 3.0.1 is current, with SPDX 3.1 at release candidate stage only.
• SBV-04 When a new major or minor format version is published, the build platform team SHOULD support it within [6 months] and MUST keep support for the previous version for at least [12 months] so that customers' tools keep working.

4.2 Generation

• SBV-05 Each released software version or update MUST have its own SBOM, including patch releases and rebuilt container images whose base layers changed.
• SBV-06 SBOMs MUST be generated automatically in the release build from the resolved dependency graph (lockfiles, build manifests and the final artefact), not written by hand.
• SBV-07 Each SBOM MUST record its generation context. The default for release SBOMs is the build phase; products SHOULD add a post-build (analysed) SBOM for container images and firmware, produced by binary or image analysis, and reconcile it with the build SBOM.
• SBV-08 SaaS services MUST maintain a deployed-context SBOM for each production deployment unit, regenerated on every deployment, so that the running inventory can be matched against new vulnerabilities.
• SBV-09 When the producer discovers an error or new information about a component, a revised SBOM MUST be issued with an incremented SBOM Version and a new timestamp, and the previous revision kept (section 8).

4.3 Content and coverage

• SBV-10 Every SBOM MUST populate all 17 data fields of the 2026 minimum elements: nine SBOM Metadata fields and eight Component Data fields, as mapped in Appendix A. The SBOM Author MUST name the organisation that operated the generator (in full, not as an acronym), never the tool.
• SBV-11 Coverage MUST include all components that make up the target software, including transitive dependencies, with no minimum depth cut-off. If several instances of one component differ in metadata, each instance MUST be listed separately with its dependency relationship.
• SBV-12 Non-code files MAY be excluded, but security-relevant configuration files SHOULD be included.
• SBV-13 Where a field cannot be populated, the SBOM MUST state whether the value is unknown to the author or deliberately withheld. Silence is not allowed: an empty field is a gate failure.
• SBV-14 Component Producer MUST name the single organisation that created the component, using its full name rather than an acronym. When the producer cannot be determined, the SBOM MUST mark the component as of unknown provenance. Suppliers or redistributors (for example a Linux distribution) are recorded in the supplier field, not as producer.
• SBV-15 Component Identifiers MUST include a Package URL (PURL) where the ecosystem supports one, and SHOULD include every other identifier known (CPE, SWHID, OmniBOR identifier, commit hash).
• SBV-16 Component Hash Value MUST be computed over the executable artefact with an approved algorithm, [SHA-256] minimum, and the algorithm MUST be recorded. MD5 and SHA-1 MUST NOT be the only hash recorded.
• SBV-17 Component License MUST use SPDX licence identifiers or expressions where they exist; otherwise it MUST point to where the full licence terms are available and flag proprietary conditions.
• SBV-18 The SBOM Timestamp MUST be in UTC with an explicit offset (for example 2026-10-24T09:30:00Z), which is valid under RFC 3339 and RFC 9557 and accepted by both formats.
• SBV-19 First-party code copied from another project MUST be recorded as a dependency (an internal fork with a name), not hidden inside a first-party component.
• SBV-20 Withheld information MUST be limited to what Legal approves (for example unreleased internal component names in a public SBOM), and recipients MUST have a documented route to ask about withheld security-relevant data.

4.4 Signing and integrity

• SBV-21 Every distributed SBOM MUST carry an SBOM Author Signature that lets a recipient verify who produced it and that it was not modified.
• SBV-22 Signatures MUST use an algorithm approved by NIST (FIPS 186-5) or an equivalent national authority. [Example: ECDSA P-256 with SHA-256 via the organisation's keyless signing service, with transparency log entries.]
• SBV-23 The SBOM MUST be bound to the artefact it describes, either as a signed attestation that references the artefact digest or by listing the target component hash in the SBOM itself.
• SBV-24 Signing keys MUST be managed under the key management standard, with private keys in a hardware-backed or managed key service and rotation at least every [12 months] for long-lived keys.
• SBV-25 SPDX 3.0.1 has no in-document signature property, so SPDX SBOMs MUST be signed with a detached signature distributed beside the document. CycloneDX SBOMs MAY use the enveloped JSON Signature Format signature or a detached signature; the product records which.

4.5 Quality gate

Every release pipeline runs an automated SBOM gate. A release MUST NOT be promoted if the gate fails, unless an exception is approved (section 9).

4.6 Worked example

5. VEX and exploitability statements

5.1 When to issue VEX

• SBV-26 PSIRT MUST publish a VEX statement for a product version when any of the following is true: a vulnerability in a listed component is added to the CISA Known Exploited Vulnerabilities catalogue; a customer asks about a specific vulnerability; a vulnerability rated High or Critical is published for a component in a supported version; or the product is affected and a fix or mitigation is available.
• SBV-27 PSIRT SHOULD publish "not affected" statements proactively for widely reported vulnerabilities in components the product does not contain or does not reach, to reduce customer triage effort.
• SBV-28 An "under investigation" statement SHOULD be published within [2 business days] of a High or Critical vulnerability in a listed component being made public, and updated to a final status within [10 business days] (Example targets; align with the PSIRT procedure).

5.2 Status, justification and evidence

Every VEX statement MUST identify the product (and version), the vulnerability and one status. The four statuses come from the CISA minimum requirements for VEX (April 2023); the five "not affected" justification labels come from the earlier CISA document VEX Status Justifications (June 2022).

• SBV-29 A "not affected" status MUST NOT be published on the grounds of a compensating control the customer must configure; that is "affected" with a mitigation in the action statement.
• SBV-30 The justifications "vulnerable code cannot be controlled by adversary" and "inline mitigations already exist" MUST be approved by the head of product security, because they are hard to prove and frequently bypassed.
• SBV-31 Every change of status MUST produce a new VEX document version with a new timestamp; earlier versions are retained.

5.3 Formats and binding to SBOMs

• SBV-32 Customer-facing VEX MUST be machine-readable. Approved formats are the CSAF 2.0 VEX profile, CycloneDX 1.7 vulnerability analysis (embedded in or alongside the BOM) and OpenVEX v0.2.0 (a draft specification: use it where the ecosystem expects it, such as container image scanners and open-source projects).
• SBV-33 VEX statements MUST reference products with the same identifiers used in the SBOM (PURL or CPE plus version) so that tools can correlate them automatically.
• SBV-34 VEX documents MUST be signed under the same rules as SBOMs (4.4).
• SBV-35 Full advisories for affected products are produced with the Security Advisory template (security/security-advisory); this policy governs the VEX content only.

5.4 Worked example

6. Distribution and access

6.1 Rules

• SBV-36 SBOMs and VEX MUST be available promptly to those who need them, through the channel defined per product class below.
• SBV-37 Access controls MAY restrict SBOM data to authorised parties (for example customers under NDA), but MUST NOT prevent an authorised recipient from importing the data into its own security tooling.
• SBV-38 Each SBOM MUST be retrievable by a stable, version-specific URL or API query, and MUST be referenced from the release notes.
• SBV-39 Distribution services MUST follow the organisation's security policy (authenticated channels, TLS, logging of downloads for restricted documents).

6.2 Channels by product class

7. Consuming third-party SBOMs and VEX

• SBV-40 Contracts for software in scope (2.1) MUST require the supplier to provide an SBOM meeting the 2026 minimum elements for each delivered version, in CycloneDX or SPDX, with VEX or CSAF advisories for vulnerabilities in listed components. Use the supplier security assessment for the wider questionnaire.
• SBV-41 Received SBOMs MUST be validated on intake: schema validity, signature verification, the 17 data fields and a spot check of coverage (for example comparing with a binary scan of the delivered artefact).
• SBV-42 Validated SBOMs MUST be ingested into the central inventory and matched against vulnerability sources at least [daily].
• SBV-43 Supplier VEX "not affected" statements MAY be used to suppress findings only when the VEX is signed by the supplier and references the exact product version in use.
• SBV-44 SBOM quality issues (missing fields, failed signature, large undeclared components) MUST be raised with the supplier and recorded in the vendor risk register; persistent failure is a risk acceptance decision (section 9).

8. Retention and records

• SBV-45 Every SBOM and VEX revision MUST be retained, with its signature, for at least the longest of: the product version's support period plus [2 years]; the contractual retention period; and any legal retention period (for products under the EU Cyber Resilience Act, check the technical documentation retention requirement in the consolidated text).
• SBV-46 Records MUST be stored in the SBOM repository with integrity protection (write-once storage or signed manifests) and backed up under the backup policy.
• SBV-47 Deletion at the end of retention MUST follow the records schedule and be logged.

9. Exceptions and risk acceptance

• SBV-48 Any deviation from a MUST statement requires an exception recorded in the exception register with: the statement ID, product and version, reason, compensating measures, risk rating, owner and expiry date (maximum [6 months], renewable once).
• SBV-49 Approval levels: Low and Medium risk by the policy owner; High risk by the CISO; any exception that affects a regulatory or contractual obligation also requires Legal.

10. Compliance measurement

Example quarter for Corvid Commerce: 46 releases, 46 with passing signed SBOMs (M1 = 100%); 1,635 components across the latest SBOMs of three products, 27,795 field slots (1,635 × 17), 27,795 marked and 27,402 populated (M2 = 100% marked, 98.6% populated); median VEX time 6 business days (M3 met); 19 of 20 customer requests on time (M4 = 95%); 12 of 18 suppliers compliant (M5 = 66.7%, below target, action owned by Procurement).

11. Review cycle

The policy owner reviews this policy at least annually, records the outcome in the revision history, and also reviews it when any of these triggers occurs:

• a new edition of the CISA minimum elements or of related guidance, such as the G7 Software Bill of Materials for AI: Minimum Elements (May 2026);
• a new CycloneDX or SPDX version (SPDX 3.1 final, CycloneDX 1.8) or CSAF 2.1 approval as an OASIS standard;
• an EU implementing act specifying SBOM format or elements under the Cyber Resilience Act;
• an incident where SBOM or VEX data was wrong, late or missing;
• two consecutive quarters below target on any metric in section 10.

12. Related documents

13. Glossary and references

13.1 Glossary

13.2 References

Appendix A. Field mapping: CISA 2026 minimum elements to CycloneDX 1.7 and SPDX 3.0.1

A.1 SBOM Metadata

A.2 Component Data

A.3 Practices and Processes

Appendix B. VEX status and justification mapping

SPDX 3.0.1 class names are shown as defined in the model; in the JSON-LD serialisation they carry the profile prefix (for example security_VexNotAffectedVulnAssessmentRelationship).

CycloneDX protected_at_perimeter relies on a control outside the product and does not meet SBV-29 for a "not affected" statement to customers.

Standard and licence note

Based on the joint guidance 2026 Minimum Elements for a Software Bill of Materials (SBOM) led by CISA (July 2026) and the CISA Minimum Requirements for VEX (April 2023), works of the United States Government; minimum element names are used exactly as published and their meanings are paraphrased. Field names are cited from CycloneDX 1.7 (Apache License 2.0; ECMA-424), the SPDX Specification 3.0.1 (Community Specification License 1.0, with earlier portions under CC BY 3.0; attribution: SPDX project, The Linux Foundation, spdx.dev), the OASIS CSAF 2.0 standard (Copyright OASIS Open; this template comments on and assists implementation of it and reproduces no specification text) and the OpenVEX specification (CC0 1.0). The text of this template is original. Check the current official versions at cisa.gov, cyclonedx.org, spdx.dev and oasis-open.org before relying on this policy, because SPDX 3.1 and CSAF 2.1 were in progress at the time of writing. Template licence: MIT.