Why sign artifacts — the supply chain integrity argument

A registry full of unsigned images is a registry full of tags the verifier cannot trust. The tag resolves to a digest, the digest resolves to bytes, but nothing in the chain of custody says who produced those bytes or from which source. Signing is the operation that adds the chain: the registry stores a signature that names the producer, the verifier checks the signature before the pod is admitted, and the audit trail becomes complete.

The supply chain integrity argument

Supply chain integrity is the property that the artifact running in production is the artifact the build pipeline produced, by the source the team approved, on the runner the team trusts. The property is not free; it is built by staking a signature at the point of production and verifying it at every point of trust.

flowchart LR
    A["Source commit"] --> B["Build pipeline"]
    B --> C["Artifact digest"]
    C --> D["Signature"]
    D --> E["Registry"]
    E --> F["Verifier"]
    F --> G["Production pod"]
    F --> H["Deny"]

The argument has three legs:

• Provenance. The signature names the producer. Without the signature, the bytes have no author; with it, the digest is bound to an identity the verifier can check.
• Tamper-evidence. A signature over a digest cannot be modified without invalidating the signature. The registry can be read, copied, or replicated; the signature survives.
• Audit. Six months later, the auditor can ask “which image was running on 14 March at 09:00?” and the answer is a digest with a signature whose producer is named.

The three legs together turn the registry from a wall of tags into a wall of attested claims. The wall is only as strong as the verifier that admits the pods.

Failure modes of an unsigned registry

An unsigned registry enables specific failures. Each is a class of incident, not a single bug:

• Tag mutation. A team deploys app:v1.4.0. The next day someone (or some compromised pipeline) overwrites app:v1.4.0 with a different image. The deployment rolls forward to the new bytes. Signatures anchor to the digest, not the tag; pinning by digest and verifying the signature prevents the swap.
• Insider push. A developer with push credentials pushes a backdoored image to the team’s registry. The CI has the correct provenance; the registry does not. The only thing that distinguishes the two is the signature, and the only thing that checks the signature is the verifier.
• Mirror compromise. A pull-through mirror serves a different image than the source. The signature on the source does not match the mirror’s bytes; the verifier rejects the mismatch.

Signed versus verified

A signed artifact is one that has a signature in the registry. A verified artifact is one that has passed a check against a policy. The distance between the two is the operational gap that this lesson stresses:

• Signed. The bytes have a signature. The signature may be from any signer, including a developer’s laptop with an arbitrary key.
• Verified. The signature has been checked against a pinned identity (an OIDC subject, a public key, a KMS key) the verifier is configured to trust. The check rejects the signature otherwise.

A team that deploys signatures without a verification policy still admits unsigned or wrongly-signed images. The cost of the gap shows up at the audit; the impact shows up at the incident.

Production discipline

1. Sign every artifact the build pipeline produces. The signature is the chain of custody; absence is the gap.
2. Verify in the admission controller at every pull. The verifier is the deliverable; the signature is the data structure.
3. Pin the signer identity. A signature from any of twenty developers with personal keys is not a chain.
4. Pair signing with SBOM attestation. The provenance (LXVIII-04) and the signature (LXIX) are the two halves of the attestation story.

Cross-course references

• Git, CI/CD & GitOps — Part LIII-06 (Image Signing in CI) introduces the Sigstore stack at the CI level; LXIX deepens the verification side.
• Git, CI/CD & GitOps — Part LXVIII-04 (SBOM Distribution and Attestation) is the attestation half of the supply chain integrity story; LXIX is the signature half.
• Container Security for Production Sysadmins — Part VII (Admission Control) is the verifier side that makes the signature load-bearing.

Quiz