What is a release registry?
A release registry stores the packaged software releases a vendor publishes, each carrying a cryptographic signature and a software bill of materials. A client environment pulls updates from the registry through its controlled egress, verifies the signature against a trusted key and admits the release only if verification succeeds. The registry is therefore the controlled channel through which new software enters a regulated environment.
Also called: Artifact registry, Container registry
Why updates are the supply chain risk that is easiest to overlook
An environment can be locked down at every boundary and still be compromised through the software it is asked to install. If updates arrive from an unverified source, an attacker who tampers with a release reaches the inside of the environment by invitation. A release registry combined with signature verification closes that route. Every release that enters can be traced to a signed release, and its components can be checked against known vulnerabilities before it is deployed.
- Updates are the one channel a locked-down environment must still accept.
- Signatures prove a release came from the publisher and was not altered.
- A bill of materials shows exactly which components a release contains.
- Version history allows a known-good release to be restored quickly.
How a release registry works
- Each release is packaged with a version and a software bill of materials.
- The release is signed with a key held under the publisher's control.
- Signed releases are published to the registry and never overwritten.
- The client environment pulls releases through its allow-listed egress.
- Signatures are verified against a trusted key before admission.
- Admitted releases are recorded with their version and verification result.
How a release registry is evaluated
A release registry is evaluated by attempting to admit releases that should be refused. Test the following before relying on it:
- unsigned releases refused at admission
- releases signed with an untrusted key refused
- releases whose content was altered after signing refused
- share of admitted releases with a complete bill of materials
- time to restore the previous release after a faulty update
Limitations, risks and common failure modes
- Verification is disabled during an urgent fix and never restored.
- Signing keys are stored alongside the release pipeline they are meant to protect.
- Existing tags are overwritten so a version no longer means one release.
- Bills of materials are generated but never checked against vulnerabilities.