OCI images can carry signatures, SBOMs, and provenance in the registry. Use this 2026 cheat sheet to harden builds, scans, and policy. Read now.
Treat the Registry as the Source of Truth
OCI images are more than a filesystem tarball and a config blob. A hardened pipeline treats the registry as the place where integrity evidence lives with the artifact: cryptographic signatures that attest who built or promoted the image, software bills of materials (SBOMs) that list packages and dependencies, and provenance records that describe how the image was produced. When those artifacts travel with the image reference, scanners, admission controllers, and human reviewers all inspect the same object instead of relying on chat logs or build dashboards that go stale.
Store and reference evidence by digest, not by mutable tags alone. Tags are useful for humans; digests bind policy to an immutable content identity. Sign after the final layer set is fixed. Attach or push SBOMs and provenance for that same digest so a consumer never has to guess which build output matches which claim.
Harden the Build Before You Scan
Scanning cannot fix a weak base image or a noisy build context. Start from a minimal, maintained base, drop packages you do not need, run as a non-root user when the workload allows, and keep secrets out of layers (use build secrets or runtime injection instead of baking credentials into the image). Multi-stage builds keep compilers and test tooling out of the runtime image. Pin base images and language dependencies by digest or lockfile so rebuilds are reproducible enough for provenance to mean something.
Prefer deterministic, auditable build systems over ad hoc scripts on developer laptops when the image will run in production. The provenance record is only as trustworthy as the environment that produced it: isolated runners, least-privilege credentials for registry push, and a clear separation between “build” and “promote” steps reduce the chance that an unreviewed intermediate image becomes the one you ship.
Scan for Risk, Then Gate on Policy
Use scanners for known vulnerabilities, misconfigurations, and secret leakage, but treat findings as inputs to policy rather than as an automatic fail/pass by severity alone. Severity scores are coarse; exposure depends on whether a package is reachable at runtime, whether a fix is available, and whether the image is internet-facing. Combine vulnerability results with SBOM completeness: if the SBOM is missing major package managers or language ecosystems, the scan is incomplete by design.
- Require a signature from an allowed identity before any cluster or runtime can pull a production tag or digest.
- Require an SBOM in a format your tools can parse, and reject images that only ship a partial or empty bill of materials.
- Require provenance that matches your expected builder and source repository for that service.
- Block promotion when critical unfixed issues affect packages your process has marked as must-patch, even if the image is signed.
Encode these rules in admission or registry policy so enforcement is consistent across environments. Document exceptions with an owner and expiry so temporary waivers do not become permanent shadow policy.
Operate the Cheat Sheet Day to Day
Hardening is a loop: rebuild when bases or dependencies change, re-sign and re-attach evidence on every production build, re-scan on a schedule and on pull, and re-evaluate policy as your stack and threat model shift. Prefer registry-native attachments and well-known OCI referrers so tooling can discover signatures, SBOMs, and provenance without custom side channels. Keep consumer trust roots (keys, identities, policy bundles) rotated and offline-backed the same way you would any other production secret.
For DevSecOps teams, the practical win is a short checklist at each stage—build clean, attach evidence, scan with context, gate on policy—applied to every image that leaves the pipeline. When the registry holds signatures, SBOMs, and provenance for the digests you actually run, security review becomes verification of claims rather than reconstruction of a build story after an incident.