Signed release

Governance

A release whose authenticity and integrity can be verified before it is admitted to an environment.

What is a signed release?

A signed release is one whose authenticity and integrity can be verified before it is admitted to an environment. The publisher attests to the artefact with a key, and the receiving environment refuses anything whose signature fails to verify against a trusted identity. The signature establishes who produced the artefact and that nothing has altered it since.

Why admission control belongs at the edge of the environment

The expensive version of this failure involves no malice at all. A container image is promoted from the wrong pipeline, nobody can establish which source produced it, and a hospital's change advisory board suspends deployment until the question is answered. Verification at admission makes that question answerable immediately, because an unverifiable artefact never entered. In a regulated environment the control also supplies the evidence that only approved artefacts reached production.

  • Verification at admission is a control rather than a procedural instruction.
  • A signature names the publisher, which makes provenance a technical fact.
  • An unsigned artefact is refused automatically, so the exception becomes visible.
  • The verification record evidences exactly what reached production and when.

How a signed release works

  • A signing key is issued to the release pipeline and held in a hardware module.
  • Each artefact is signed as it is produced, with its digest recorded alongside.
  • Trusted signer identities are configured in the receiving environment.
  • The admission controller verifies every signature before the artefact is accepted.
  • Refusals are recorded with the artefact digest and the reason for rejection.
  • Keys are rotated on a stated schedule and revocation is exercised.

How a signed release is evaluated

The control is proved by what the environment refuses rather than by what it accepts. Test the following in the receiving environment itself:

  • share of admitted artefacts carrying a verified signature
  • result of presenting a deliberately unsigned artefact
  • key custody arrangement and the rotation interval actually observed
  • coverage across every deployment path into the environment
  • completeness of the refusal log over a stated period

Limitations, risks and common failure modes

  • Verification is enabled in production and omitted on an emergency deployment path.
  • A signing key is held in pipeline configuration where any maintainer reads it.
  • Signatures are verified while the artefact digest goes unrecorded.
  • Third party images enter through a mirror that strips the signature.
  • Revocation has never been exercised, so nobody knows whether it works.

All 315 terms