SBOM Requirements for Software Procurement and Assurance
An SBOM answers a narrow but valuable procurement question: what software components make up this delivered product? NTIA and CISA describe it as a nested inventory, not a security certification. Treat it as release evidence that enables later vulnerability, licensing, and supplier follow-up; it does not establish exploitability, absence of defects, or legal compliance by itself.
Turn requirement into a deliverable
Put SBOM delivery in purchase scope, acceptance criteria, and release handover. Ask for machine-readable CycloneDX, SPDX, or another agreed format. NTIA identifies those formats as practical interchange options; CycloneDX documents component, dependency, metadata, and vulnerability-related structures. A PDF or spreadsheet may help a human reader but cannot substitute for an artifact that can be parsed and compared.
Require one SBOM per releasable artifact: desktop installer, mobile package, container image, library, and separately deployed service. A single portfolio inventory hides version differences. Require supplier to state whether transitive dependencies, bundled binaries, optional modules, operating-system packages, and build tools are in scope. Absence is meaningful only when scope is explicit.
Minimum purchase schedule
| Contract field | Completed example | Acceptance evidence | Owner |
|---|---|---|---|
| Artifact identity | portal-api:2.4.1, digest sha256:ab12... | Signed release manifest and digest | Supplier release owner |
| Format and version | CycloneDX JSON 1.6 | Parser accepts file | Supplier build owner |
| Component identity | pkg:npm/[email protected] | purl, version, supplier where known | Supplier build owner |
| Relationships | application depends on express | dependency edge present | Supplier build owner |
| Delivery time | at release publication | artifact attached to release record | Procurement owner |
| Update channel | revised SBOM after component change | dated replacement and changelog | Supplier security contact |
A useful fragment is concrete enough for automated intake:
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"metadata": {"component": {"name": "portal-api", "version": "2.4.1"}},
"components": [{"type": "library", "name": "express", "version": "4.21.2", "purl": "pkg:npm/[email protected]"}]
}This is illustrative data, not proof about any product. Verify against actual build output. The important binding is artifact digest to SBOM record. Without it, a supplier can provide a valid inventory for an older or different build.
Acceptance test before payment milestone
Procurement owner obtains release artifact, digest, SBOM, generation timestamp, tool name/version, and supplier contact. Engineering independently calculates the delivered artifact digest, parses the SBOM, and confirms top-level name/version/digest match the release record. Security samples high-risk components: resolve their package identifiers, compare version with lockfile or image inspection, and check whether declared relationships make sense. Keep test output with procurement evidence.
Acceptance passes when all required artifacts are present, parser succeeds, identifiers are resolvable enough for the agreed use case, and release binding is demonstrated. It fails when inventory is only a static table, has no artifact linkage, omits declared scope, uses ambiguous component names without usable identifiers, or predates the delivered release. Mark incomplete data as incomplete; do not silently convert it into a clean result.
Exceptions need expiry and compensating action
Legacy supplier may not yet generate a complete SBOM. Record exception ID, missing fields, affected product, business owner, security owner, temporary alternative evidence, expiry date, and remediation date. Example: EXC-SBOM-014 permits an internally generated package inventory for one release while supplier enables CycloneDX output; acceptance remains conditional and expires on stated date. An exception is not a permanent waiver.
Use inventory after procurement
CISA describes VEX as an attestation about whether a known vulnerability affects a product. Request VEX or a supplier response channel when vulnerability triage matters, but keep it distinct from SBOM: inventory identifies possible exposure; VEX can communicate applicability. Security owner should reconcile new advisories against stored release inventories, open remediation work only after confirming product/version relevance, and preserve supplier response with decision evidence.
Remediation starts with release traceability: fix build generation, add package identifiers, repair dependency edges, or issue corrected SBOM linked to same artifact. Re-test parser and digest binding. Source-code review can examine whether component declarations and delivered build evidence agree.
Reproduce release binding
Run generator after dependency resolution, store output beside immutable release artifact, then record command, generator version, UTC time, artifact digest, SBOM digest, and reviewer. A parser success alone is insufficient: compare one resolved transitive package and dependency edge against build lock data. Expected result is matching package URL and version; mismatch, missing edge, or unsigned replacement is fail. Procurement owner opens remediation for supplier; security owner retains prior inventory for advisory triage.
Worked procurement check and closure
Ask supplier for one SBOM tied to exact delivered artifact, not a current inventory exported from another branch. For a container image, record immutable digest, generation time, tool version, component name and version, package URL, dependency relationship, hashes where available, and vulnerability-feed timestamp. A useful command is syft registry.example.test/payments@sha256:REPLACE_ME -o cyclonedx-json > payments.cdx.json; expected output is a JSON document whose metadata component and image digest identify same release candidate. Then compare digest with deployment manifest. If SBOM says 1.8.4 but deployed digest resolves to a build containing 1.8.3, evidence does not close procurement check.
Edge case: a package may be present only in a build layer, generated artifact, or optional runtime plugin. Absence from lockfile alone is not proof of absence from deliverable. Require supplier to explain scope, excluded files, and unresolved components. A vulnerability match is triage input, not automatic exploit proof; capture reachable path, configured feature, affected version range, and supplier remediation decision.
Close item when artifact digest, SBOM hash, validation result, exception owner, and retest date are stored together. Regenerate after dependency change, base-image rebuild, signing change, or new release; do not reuse old SBOM merely because product version label remains unchanged.