SBOM / software supply chain binding

When to use SBOM binding

• You ship a release artifact (package, container, firmware) and need a verifiable SBOM reference.
• A buyer, regulator, or platform needs machine-checkable evidence that the SBOM matches the release.
• You participate in DORA, procurement, or supplier evidence workflows that require SBOM identity.

CycloneDX vs SPDX

Choose the SBOM format that fits the consuming workflow. Both formats can coexist for the same release.

• CycloneDX — security and VEX workflows.
• SPDX — licence and procurement workflows.

Binding sequence

• 1. Bind the repo or package identity.
• 2. Tie a release reference (name@version) to that identity.
• 3. Record the SBOM hash for the chosen format.
• 4. Add the container digest where applicable.
• 5. Resolver projects BOUND state when Backend/Core verifies the references.

SBOM reference example

{
  "binding_type": "sbom",
  "operator_ecz_id": "ECZ-GB-XXXXXX",
  "release_reference": "example-service@1.4.0",
  "repo_url": "https://github.com/example/example-service",
  "sbom_format": "CycloneDX",
  "sbom_url": "https://example.com/sboms/example-service-1.4.0.cdx.json",
  "sbom_hash": "sha256:<hash>",
  "container_digest": "sha256:<container-digest>",
  "assured_posture": {
    "vex_url": null,
    "provenance_url": null,
    "sigstore_bundle_url": null
  }
}

Safe Resolver projection

• Resolver may show the hash and reference state for the bound release.
• Resolver does not publish raw vulnerability findings, compliance scores, or percentages.
• Resolver does not endorse the security posture of the release.

Assured evidence (optional)

VEX, provenance, and Sigstore artifacts are optional Assured-tier evidence. They are required only where the operator package or tier policy specifies them.