10.3 Artifact Signing and Release Verification: From Identity to Admission Policies

A digital signature proves that a private key holder authorized a specific set of bytes. Beyond that, supply chain systems must answer: who does this key represent, what digest was signed, was the identity valid at the time of signing, was the declaration recorded in a transparent log, and why does the current environment trust it?

Keyless Signature Shortens Long-Term Key Exposure

The Sigstore-style workflow simplifies to:

CI workload OIDC identity
  → CA issues short-lived signing certificate
  → sign artifact digest / attestation
  → record evidence in transparency log

Keyless does not mean no keys are used, it means the signing key is generated briefly and the identity is bound via OIDC claims. Evidence can be audited through a transparency log. Verification policies must restrict claims such as issuer, repository, workflow, and ref/environment; otherwise, checking only that "the certificate is issued by a public CA" would be too permissive.

Private offline deployments, firmware updates, and long-term validation may still require traditional HSM keys. The decision should be based on online identity, validation duration, revocation mechanisms, and disaster recovery needs, not on a universal pursuit of keyless solutions.

Tags, Digests, and Signed Objects Must Align

A mutable tag can be reassigned:

registry/app:1.4 → sha256:AAA today
registry/app:1.4 → sha256:BBB tomorrow

Signatures, SBOMs, provenance, and deployments must all be tied to the same digest. While user interfaces can display semver or tags, policy decisions must rely on immutable digests and verify that all evidence subjects are consistent.

Transparent Logs Provide Visibility, Not Trust

An append-only log makes it harder for signed events to be silently deleted or retrofitted, enabling audits of which identities have signed which artifacts. The presence of a valid record in the log does not imply that the signer has been authorized by your organization, nor does it indicate that the artifact is secure.

Offline verification must preserve the necessary inclusion proof, certificate chain, and timestamp evidence, and clearly define what actions to take when the transparent log is unavailable, such as using cached evidence, delaying publication, or activating a break-glass procedure.

Admission Validation at Every Trust Boundary

Developer registry → Publish registry: validate build and source provenance
Publish registry → Staging: validate signature, SBOM, and policy compliance
Staging → Production: validate identical digest and environmental approval
Cluster admission: reject unverified digests and disallowed configurations
Runtime: detect runtime digest divergence from approved records

Allowing CI-only signing while permitting administrators to directly deploy arbitrary images creates a gap in the control chain. The admission controller itself must be highly available, versioned, and monitored; fail-open should only be a deliberate and narrowly scoped availability decision.

Policies are not simply "the image must be signed":

Trusted identity signed this exact digest
AND approved builder issued SLSA-provenance attestations
AND source revision satisfies branch and review policies
AND no expired exception blocks release
AND artifact configuration meets environment-specific policies

TUF-Protected Update Distribution

Beyond signed artifacts, an update system must also defend against rollback, freeze, mix-and-match, and signing key compromise. The Update Framework (TUF) achieves this by separating roles (such as root, targets, snapshot, and timestamp) into distinct components and enforcing threshold signatures, which limits the impact of a single key compromise.

Offline root keys, online short-lived timestamp signatures, monotonic versioning, and client-side expiration checks work together to provide robust security. A custom approach of "downloaded file + a long-term signing key" typically lacks proper key rotation and rollback protection.

Supply Chain Incident Response Begins with Graph Query

When a builder, dependency, or signing identity fails:

1. Query affected source revision, build run, artifact digest, and deployment records;
2. Pause new releases for the corresponding identity or builder;
3. Preserve logs, provenance, SBOM, and runner evidence;
4. Rebuild and compare from a clean platform using a trusted revision;
5. Rotate credentials, repair the platform, re-sign, and gradually replace components;
6. Publish VEX/advisories and customer-facing scope;
7. Update verification policies to prevent re-entry of compromised artifacts.

Without a unified query capability for assets, SBOMs, and provenance, incident response teams are left guessing about the scope of impact based solely on labels.

Scope Checklist for This Volume

• Are dependencies sourced from fixed, verifiable origins with defined versions and integrity, and are they capable of continuous updates?
• Is a final artifact produced and validated with a high-quality Software Bill of Materials (SBOM)?
• Is provenance generated by a trusted platform and immune to forgery by job-level actors?
• Does the SLSA declaration reference the current 1.2 track, rather than outdated L1–L4 levels?
• Are signatures, SBOMs, provenance, and deployment tied together using the same digest?
• Is identity, builder, source, and environment validated at every release boundary?
• In the event of compromise on signing or build platforms, can provenance be traced, revoked, rebuilt, and rollback prevented?

References

• Sigstore, Documentation
• The Update Framework, Specification
• in-toto, Framework
• SLSA, Verification