Trustworthy release: the gate combining signature, provenance, and SBOM
A valid signature is not enough. Before promoting an artifact, verify its digest, expected identity, build origin, provenance integrity, declared components, and the policy for the target environment.
- Nature
- Technical guide based on NIST SSDF, Sigstore, OpenSSF, and SLSA
- Scope
- Software artifacts, packages, containers, and supplier deliveries
- Published and verified
- 4 August 2026
- Limit
- Supply-chain proofs do not demonstrate absence of vulnerabilities or malicious behaviour
In brief
A signature answers who or which workload signed and whether the artifact changed. Provenance describes how, where, and from which inputs it was produced. An SBOM inventories components. SSDF organises practices throughout development. The release gate connects these proofs to policy: authorised repository, workflow, builder, branch, review, SLSA level, dependencies, vulnerabilities, exceptions, and destination. Missing proof must not silently turn green; it should block, reduce the permitted destination, or open a temporary owned exception with retest.
- Verify expected identity and digest; a valid signature from an unknown identity is insufficient.
- Provenance connects artifact, source, build, and inputs, but does not claim the code is secure.
- An SBOM improves discovery and response; it can be incomplete, stale, or unrelated to the binary.
- The gate should be versioned policy-as-code with refusal reasons and expiring exceptions.
Each proof closes a different question
NIST SSDF recommends preparation, protection, production, and response practices. Sigstore explains why verification needs expected values — identities, issuers, and artifact — rather than a successful cryptographic operation alone.
SLSA organises increasing source and build guarantees. OpenSSF stresses that provenance creates verifiable links, not automatic trust. The decision belongs to consumer policy and execution context.
Gate before promotion
- 1 · OBTAINFix artifact by digest
Never verify only a mutable tag, filename, or version.
- 2 · VERIFYCompare expected identity
Validate signature, issuer, subject/workload, transparency, and time where applicable.
- 3 · PROVENANCEConfirm origin and build
Compare repository, commit, workflow, builder, parameters, and materials.
- 4 · COMPONENTSValidate SBOM
Connect format, creation, scope, and digest to the delivered artifact.
- 5 · POLICYPromote or block
Apply destination, risk, exceptions, vulnerabilities, and rollback criteria.
Turn metadata into a repeatable decision
Define expected values outside the artifact-producing pipeline. If one process can alter artifact, provenance, and policy, verification loses independence. Separate production, publication authorisation, and production promotion.
Release trust gate
| Proof | Required comparison | Failure | Response |
|---|---|---|---|
| Artifact | Delivered digest = verified digest | Tag moved or digest differs | Block |
| Identity | Allowed issuer and subject/workload | Valid but unauthorised signer | Block and investigate |
| Provenance | Expected source, commit, builder, workflow | Local build or origin differs | Restrict or rebuild |
| SBOM | Coherent artifact, format, scope, and date | Missing/mismatched inventory | Block critical destination |
| Vulnerability | Policy by exploitation, severity, exposure | Unapproved exception | Fix or time-bound acceptance |
| Destination | Authorised environment and permissions | Promotion outside path | Deny and revoke |
Adopt without pretending instant maturity
Start with the most material artifacts and workload identity without long-lived secrets. Fix digest and signature, then add provenance and SBOM. Clearly mark where proof remains self-asserted or incomplete.
For third-party software, retain artifact, signature, bundle/provenance, SBOM, licence, policy result, and decision. Inability to verify is a risk fact, not a reason to manufacture confidence.
- Prevent silent downgrade from a release with provenance to one without it.
- Alert unexpected repository, workflow, issuer, builder, or identity changes.
- Test the gate with wrong signature, altered digest, another artifact's SBOM, and expired exception.
- Retain metadata long enough to investigate and reproduce the decision.
Sources consulted
Consulted on the stated update date.
Opens in a new window.- 01Secure Software Development FrameworkNIST CSRC · CY-NISTCSRC
- 02SSDF publicationsNIST CSRC · CY-NISTCSRC
- 03The importance of verificationSigstore · CY-SIGSTORE
- 04Verifying signatures with CosignSigstore · CY-SIGSTORE
- 05SBOM Everywhere — getting startedOpenSSF · CY-OPENSSF
- 06Build provenance for package registriesOpenSSF · CY-OPENSSF
- 07SLSA specification v1.2SLSA · CY-SLSA
Participate
Share the analysis. Add context.
Distribute the article through your channel or leave an observation connected to the topic.
Comments
Loading the conversation.