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

A signature verifies a relationship between a public key and specific message bytes. Under the algorithm and key-security assumptions, it supports possession of the corresponding private key; it does not automatically prove a person's approval intent. 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 transparency log, and why does the current environment trust it?

Keyless Signing Reduces 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 still uses a key: the signing key is generated for short-lived use and the identity is bound via OIDC claims. Evidence can be audited through a transparency log. Verification must constrain applicable OIDC issuer, repository, workflow, and ref/environment attributes through certificate identity and supported authenticated extensions. Do not assume every OIDC claim is copied into the certificate. Checking only that "the certificate is issued by a public CA" would be too permissive.

Private releases or firmware systems that cannot obtain online signing identities may use traditional HSM keys. Keyless signatures can also be verified long after signing using complete offline bundles; certificate expiry does not invalidate every old signature. 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.

Test Signature Validity and Key Trust

This example requires cryptography and generates test keys in memory. The verifier selects trusted_key in advance; accepting a "trusted key" supplied with the download would defeat the final check. signing_message prefixes a fixed purpose and hashes the actual artifact bytes. This is a teaching format, not a Sigstore or in-toto implementation.

import hashlib
from cryptography.exceptions import InvalidSignature
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PrivateKey

def signing_message(artifact):
    return b"atlas-artifact-v1\x00" + hashlib.sha256(artifact).digest()

def verify_artifact(artifact, signature, trusted_key):
    try:
        trusted_key.verify(signature, signing_message(artifact))
        return True
    except InvalidSignature:
        return False

release_key = Ed25519PrivateKey.generate()
trusted_key = release_key.public_key()
artifact = b"release 1.4\n"
signature = release_key.sign(signing_message(artifact))
assert verify_artifact(artifact, signature, trusted_key)
assert not verify_artifact(artifact + b"changed", signature, trusted_key)

untrusted_key = Ed25519PrivateKey.generate()
other_signature = untrusted_key.sign(signing_message(artifact))
assert not verify_artifact(artifact, other_signature, trusted_key)

The correct signature passes; altered artifact bytes and a valid signature from an untrusted key fail. The example does not check provenance, version freshness, certificates, transparency evidence, or deployment approval. The same old artifact and signature can still pass again, showing that signature verification alone does not prevent rollback.

Transparency Logs Provide Visibility, Not Trust

Inclusion/consistency proofs, trusted checkpoints, and independent monitoring make log deletion or inconsistent histories easier to detect. A log's own claim that it is append-only is insufficient. With these checks, the log can help audit which artifacts an identity signed. 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 needs inclusion proofs, certificate chains, and verifiable time evidence, with CA/log trust roots supplied through independent trust configuration. After a short-lived certificate expires, evidence must establish that the signature existed during its validity period; a self-reported signing time is insufficient. Define behavior when the transparency 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 each unmet requirement has a valid, scoped, unexpired exception
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 timestamp metadata with short expiry, persisted trusted versions, and client time checks work together. TUF detects and rejects stale update metadata; it cannot guarantee a new download while the network is blocked. Its initial trust root also needs a trusted bootstrap channel. 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 is compromised:

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 name its version and Build/Source track without mixing in old L1–L4 claims?
• 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

• Cryptography, Ed25519 signing

• Sigstore, Documentation

• The Update Framework, Specification

• in-toto, Framework

• SLSA, Verification