The container registry is the most overlooked supply chain control point in most organizations. A registry compromise or misconfiguration has blast radius across every workload that pulls from it, and the failure modes are rarely subtle. This checklist captures the practices we have seen actually hold up against incidents in 2025 and 2026, organized by what produces real risk reduction rather than what checks a compliance box.
Is your authentication model actually defensible?
Static credentials remain the dominant access pattern for container registries, and they remain the dominant source of incidents. The 2024 compromise of a major fintech's ECR via a leaked CI runner token, and the similar Docker Hub incident in Q3 2025, both followed the same pattern: a long-lived token in a build environment leaked, and the attacker pushed a malicious tag before detection. The defensible posture is short-lived credentials via OIDC, supported by ECR, GAR, GHCR, and most modern registries, with no long-lived tokens issued for push access.
If you cannot eliminate long-lived tokens, scope them aggressively: one token per repository per pipeline, with push permissions only where push is genuinely required, and automated rotation on a schedule shorter than the window an attacker would need to exploit a leak. Read-only tokens for production pull paths are non-negotiable, with push capability isolated to CI identities that cannot be assumed from outside the build environment.
Are your images signed and is signing verified at pull time?
Cosign signing has become the practical default for container images, and the tooling around Sigstore matured substantially in 2025. The question is no longer whether to sign images but whether verification is enforced at the pull side. A signed image with optional verification provides essentially no protection: the attacker who controls the registry can push unsigned malicious tags that pull successfully.
The enforceable pattern is Kyverno or OPA Gatekeeper policies in Kubernetes that require valid Cosign signatures on every image pulled, with the signing key or Fulcio identity allowlist pinned at the cluster level. For non-Kubernetes deployments, the registry-side enforcement options are more limited, and the burden falls on the pull-side toolchain. Sign-and-verify is the control. Sign-and-hope is theater.
How are you handling scan results and image promotion?
Scan-on-push catches CVEs but does nothing about CVEs disclosed after the push. The pattern that works is continuous re-scanning of registry contents on a daily cadence, with policy enforcement at promotion time between registries or repositories. A development registry contains everything, a production registry contains only images that have passed the current policy bar, and promotion is gated on a fresh scan rather than a stale one.
The implementation detail that matters is retention: a CVE that appears today affects every image already in your registry, and the production scan results from yesterday are now out of date. Either re-scan on every pull, expensive and rarely done, or re-scan continuously with admission control checking the freshness of the scan result. The second pattern produces meaningfully better outcomes for marginal operational cost.
What about image retention and tag immutability?
Tag mutability is the silent enabler of supply chain attacks. A registry that allows overwriting a tag means that the image you ran in CI yesterday is not necessarily the image that is pulled today, even by the same tag. ECR, GAR, and GHCR all support tag immutability, and you should enable it. The exceptions, latest tags for development convenience, are usually justified, but everything that lands in production should be pinned by digest.
Retention policies matter for incident response. The investigator who needs to determine what code ran during an incident three months ago needs the actual image bytes, not a tag pointer. Retain at minimum 180 days of production images and the SBOMs that describe them, longer if your regulatory environment requires it. Storage cost on modern registries is a rounding error against the cost of being unable to reconstruct a deployment for forensics.
What does the supply chain perimeter look like?
The registry sits between upstream public registries, Docker Hub, Quay, GHCR, and your runtime. The hardening question is whether your runtime ever pulls directly from public registries or whether everything routes through your own registry with the supply chain controls. The defensible posture is exclusive use of an internal registry, with public images mirrored on ingest after policy evaluation. The 2025 ESLint plugin incident and the 2024 polyfill.io incident both demonstrated the cost of direct upstream consumption, and the registry mirror pattern would have caught both.
The mirror process should be slow on purpose: a 24-hour quarantine on new upstream images before they become available internally, with vulnerability scanning, signature verification, and provenance checks run during the quarantine window. The latency is annoying once. The blast radius savings are large when an upstream incident lands.
How Safeguard Helps
Safeguard sits in front of your registry as a policy gate that enforces signing verification, fresh scan results, and SBOM presence at pull and admission time. Griffin AI continuously re-evaluates registry contents against the latest CVE feed, so a vulnerability disclosed after image build does not silently linger in production. Our zero-CVE base images give you a clean foundation that survives admission policy with minimal exception lists, and reachability analysis on top of the base images means CVEs that do appear get prioritized by actual exposure, not by raw scan count. TPRM and supply chain scoring flag upstream registry incidents so your mirror quarantine workflow has the signal it needs to extend or block specific upstream sources.