Release and Artifact Management
Published on
A release candidate should be an immutable artifact with enough identity and evidence to decide whether it can move to the next environment.
Artifact contract
- unique version and digest tied to reviewed source;
- build provenance and builder identity;
- dependency and base-image inventory, commonly expressed as an SBOM;
- test and policy results with scope and version;
- signature or attestation when the threat model requires it;
- retention, revocation, and vulnerability-response policy.
Promote the same artifact instead of rebuilding for each environment. Keep configuration separate and versioned. Restrict who can publish or overwrite artifacts and protect the registry as a production control plane.
Software composition analysis identifies included dependencies and known risk, but prioritization still depends on reachability, exposure, exploitability, asset importance, and compensating controls. Re-scan retained artifacts when vulnerability intelligence changes.
Release approval should consume the evidence already produced by delivery rather than request screenshots or duplicate manual checks. Continue with Deployment.