A quarantine repository is a holding area where new artifacts land first. Nothing there is visible to production. When scans, signature checks and policy gates pass, promotion copies the same artifact, by digest, into a release repository. Failed items stay quarantined or are deleted, so bad builds never become installable.
The layout
| Stage | Who writes | Who reads | Mutable? |
|---|---|---|---|
| Quarantine | CI build job only | Scanners and test jobs | Items can be removed |
| Staging | Promotion job only | Test environments | Immutable tags |
| Release | Promotion job only | Production and customers | Immutable, retention managed |
The same shape works for container registries, package repositories and generic file stores. Separate repositories give you separate permissions, which is the point.
Steps
- Build once and push to quarantine with a tag that includes the commit SHA. Record the digest.
- Run checks against that digest: vulnerability scan, license check, secrets scan, signature verification, provenance check.
- Evaluate a written policy. For example, block on a known exploited vulnerability with a reachable path, and allow with an expiring exception.
- On pass, copy the artifact to staging and sign it, referencing the digest. Do not rebuild. See scan once and promote the same image digest.
- Run tests and any approvals required for the change.
- Promote to release, again by digest, adding the version tag. Turn on tag immutability where available.
- Store the evidence next to the release: scan report, policy result, approver, timestamps.
Rules that keep it honest
- Only the pipeline identity can write to staging and release. Humans cannot push there directly.
- Deleting from release is a separate, rare permission.
- Quarantine has a short retention, release has the long one. See retention by data class.
- Exceptions are logged with an owner and an end date.
What can go wrong
A scan result goes stale: new advisories appear after promotion, so keep monitoring released artifacts rather than treating the gate as one time. Another risk is a rebuild at promotion time, which breaks the link between what was tested and what shipped. And teams sometimes let a hotfix bypass quarantine, which is when incidents happen.
Safeguard's policy gates evaluate artifacts at the point you choose, and its continuous monitoring keeps checking what has already shipped.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a failing policy stops a change before it moves forward.
Quick check
Why promote by digest rather than rebuild?
A rebuild produces a different artifact. Copying by digest keeps what you tested identical to what you ship.
Can humans push to the release repository?
They should not. Limit writes to the promotion job identity so every release passes the gates.
Last reviewed: 19 October 2026.
