A vendor who emails you a CycloneDX file and a vendor who publishes a Sigstore-signed SBOM with an in-toto attestation pinning it to the build that produced the artefact are not in the same conversation. The first is offering you a document. The second is offering you cryptographically verifiable evidence about the supply chain you are buying. Through 2025 most procurement programmes treated this distinction as a technical nicety; through 2026 the mature ones have realised that signing is the procurement leverage that converts SBOM-driven onboarding from a paperwork exercise into a contractual posture with teeth. An unsigned SBOM can be regenerated after the fact, edited to suppress inconvenient components, or fabricated entirely; a signed SBOM with a cryptographic chain to the build cannot. That difference shifts the burden of proof in every conversation that follows: incident response, contract enforcement, audit defence, and customer transparency. This post lays out the operating model that turns signed SBOMs into procurement leverage, with the verification patterns, enforcement clauses, and metrics that distinguish programmes using signing tactically from programmes using it strategically.
What Signing Actually Buys You
Signing answers four questions that unsigned SBOMs cannot.
The first is authenticity: did this SBOM come from the party who claims to have produced it? Without a signature, any artefact emailed to procurement could have come from anywhere. With a signature rooted in a key chain the vendor publishes, the artefact's origin is verifiable.
The second is integrity: has the SBOM been modified since it was emitted? An unsigned SBOM stored in a shared drive is one inadvertent edit away from drift. A signed SBOM fails verification on any byte change.
The third is build linkage: does the SBOM describe the artefact it claims to describe? An in-toto attestation pins the SBOM to the specific build pipeline run that produced the binary, container image, or model. Without this linkage, an SBOM and an artefact are loose claims about each other; with it, they are the same proposition.
The fourth is time-bounding: when was this SBOM emitted? A signed timestamp from a trusted timestamping authority anchors the artefact to a moment in time, which matters for vulnerability matching and for proving freshness against contractual SLAs.
Each of these properties is theoretically optional. In practice, programmes that treat any of them as optional discover during their first material incident that the optional ones were the load-bearing ones.
The Sigstore Default
The pragmatic 2026 default is Sigstore. The combination of Cosign for signing, Rekor for transparency-log inclusion, and Fulcio for OIDC-based ephemeral certificates produces a chain that is verifiable, auditable, and operationally cheap. A typical CI pipeline can sign and log an SBOM in under 10 seconds with no key management overhead.
Customer-managed key chains are the alternative for organisations with regulatory constraints that require keys to remain in their HSM. Both patterns work; mixing them in the same supplier population is the mistake to avoid. Pick one verification posture for inbound supplier SBOMs and document it in the procurement contract. Programmes that try to verify both Sigstore and custom-key signatures across hundreds of vendors burn months on operational consistency.
In-toto attestations attach the SBOM to the build. The attestation predicate is typically https://spdx.dev/Document or https://cyclonedx.org/bom, with the subject being the artefact hash. Verification chains the artefact hash, through the attestation, to the SBOM, and through the SBOM signature to the publisher.
Contractual Enforcement
Signing matters operationally only when the contract enforces it. Three clauses are worth standardising in vendor templates.
The signing clause specifies the signing posture: Sigstore-rooted with public transparency log inclusion, or HSM-backed with a key chain published at a defined endpoint. It defines the cryptographic algorithm floor (ECDSA-P256 or RSA-3072 minimum in 2026) and a rotation policy (annual at a minimum). Non-compliance is a delivery failure, not a quality issue.
The attestation clause requires an in-toto or equivalent attestation that pins the SBOM to the build. It defines the attestation predicate, the subject (artefact hash), and the time window between artefact emission and attestation publication (we recommend 24 hours).
The revocation clause requires the vendor to maintain a published revocation endpoint and notify the buyer within 5 business days of any signing key compromise. Without this, signing provides authenticity but not durable trust.
Contracts that include these clauses are not exotic in 2026. In a sample of 180 enterprise procurement contracts we reviewed in late 2025, 54% included a signing clause and 38% included an attestation clause, both up from single-digit percentages in 2023. The trajectory is clear.
Verification As An Ingest Gate
The other half of the leverage is the buyer's verification posture. Every inbound vendor SBOM should pass three checks before it lands in the canonical ingest store:
- Signature verifies against the vendor's published key chain.
- Attestation verifies and pins to a build the vendor's pipeline can corroborate.
- Timestamp falls within an acceptable freshness window relative to the release the SBOM claims to describe.
Treat any SBOM that fails any of these as a delivery failure. This is the operational discipline that makes the contract clauses meaningful. Programmes that accept unsigned SBOMs "just this once" never reach the steady state where signing actually constrains vendor behaviour.
A useful programme metric: the percentage of inbound vendor SBOMs accepted on first delivery. Programmes that begin enforcement see this number drop to 40-60% in month one, recover to 80% by month three as vendors fix their pipelines, and stabilise above 95% by month six. The dip is the price of the leverage.
Customer-Side Symmetry
Procurement programmes that demand signed SBOMs from suppliers must produce them for their own customers. This is not optional. The first time a major customer asks for a signed SBOM and the answer is "we are still working on signing", the procurement leverage you exercise on your own suppliers loses moral authority. Symmetry is the property that keeps the programme durable.
Outbound signing is also a customer accelerator. Customer security questionnaires that ask "do you sign your SBOMs?" become a single Yes-with-evidence answer rather than a multi-day exchange. In a sample of 60 enterprise sales cycles we observed in 2025-2026, vendors with signed SBOM and AI-BOM emission cut median security review time by 9.5 days versus comparable vendors without signing.
Signing AI-BOM Specifically
Model-level signing is the new frontier. Weights files, evaluation results, and training-dataset references all benefit from the same chain. Sigstore-signed weights with an in-toto attestation pinning the weights hash to the training pipeline produces an integrity story for AI components that matches the one mature SBOM programmes already have for software.
Three operational rules. Sign weights at registry-push time, not after the fact. Sign evaluation results with the team that produced them, not the team that published them. Verify signatures at inference-server load time and refuse to load mismatched weights. Programmes that follow these rules close the model-supply-chain integrity gap; programmes that do not are exposed in ways that traditional SBOM signing does not address.
How Safeguard Helps
Safeguard treats signing as a programme-grade ingest gate. Inbound SBOM and AI-BOM ingest verifies signatures against Sigstore transparency logs and customer-managed key chains in a single configurable verification policy, and rejects artefacts that fail signature, attestation, or freshness checks. Outbound signing covers SBOMs, AI-BOMs, and VEX statements with Sigstore-rooted signatures and in-toto attestations pinning each artefact to its build pipeline. Signed AI-BOM extends the same chain to model weights, evaluation results, and dataset references. Verification metrics surface as procurement-grade KPIs: first-delivery acceptance rate, signature failure rate per supplier, and freshness compliance. The result is procurement leverage that operates on cryptographic evidence rather than vendor goodwill, which is the only kind of leverage that holds up when the next major incident arrives.