Before requesting an SBOM
- Define the products, versions and environments covered by the component inventory.
- Select a system that can ingest SPDX or CycloneDX and connect entries to assets.
- Assign analysis roles across procurement, security, operations and the service owner.
- Set expectations for proprietary, open-source and commercial components, including nested dependencies.
Without a consumption process, the document becomes a contract attachment and is obsolete after the first update.
Supplier requirements
- The SBOM represents the delivered version and uses a machine-readable format with component identifiers.
- Dependency relationships, format version, creation date and document author are present.
- Update frequency and delivery channel are defined.
- A vulnerability disclosure channel, acknowledgement targets and customer notification rules exist.
- The supplier explains how VEX statements connect to remediation or mitigation.
VEX complements an SBOM by stating whether a vulnerability affects the product and why. A not-affected label without justification is not a completed assessment.
Acceptance checks
- The inventory matches the installed build, not an entire product family.
- Components have versions and stable identifiers suitable for automation.
- A test vulnerability can travel from detection to decision and notification.
- A new SBOM arrives with the release and remains linked to its predecessor.
- The team can separate CVE presence from exploitability in the deployed configuration.
Operation after the contract
Feed SBOM data into asset and vulnerability management rather than a document archive. Monitor new CVEs, VEX statements and supplier advisories. Reconcile the inventory with deployed software and test the supplier contact periodically.
Useful measures include coverage by current SBOM, time to qualify a new issue, components without versions and time to remediation. They turn a procurement clause into an operating control.