Container security in 2026 looks different than it did three years ago. Distroless and zero-CVE base images are now table stakes, sigstore signing is the default for most internal registries, and runtime tooling has matured past the eBPF-versus-sidecar arguments. What follows is the checklist I hand to teams who want to ship containers without inheriting a vulnerability backlog they cannot service.
This is not a generic list of platitudes. Each item has a concrete threshold and a reason, drawn from incidents I have helped triage over the last two years.
Which base images should you actually use?
Pick a small set of approved base images and treat the list as a hard policy boundary. Most organizations should run on two or three: a distroless image for compiled languages like Go and Rust, a minimal slim variant for Python and Node services, and a hardened Debian or Ubuntu image for the small number of workloads that genuinely need a package manager at runtime. Anything outside that set should require an exception with a documented owner.
Measure your base image freshness in days, not weeks. The target is a median age under 14 days across production, with a hard ceiling of 30 days for any image. The OpenSSL CVE that fanned out across 40 million container images in Q1 2026 was patched in the upstream base images within 48 hours. The organizations that took weeks to roll the fix were the ones running on stale custom base images that no one owned. Centralize the base image pipeline, automate the rebuilds on upstream changes, and pin nothing for longer than a sprint.
How do you handle image signing and provenance?
Cosign with Fulcio keyless signing is the right default for 2026. Sign every image at build time, verify signatures at admission, and store the attestations in a Rekor instance or an OCI-compatible transparency log. If you are not yet signing, the cost to get started is roughly a week of pipeline work and the operational overhead is negligible after that. The payoff is that registry compromises, like the npm-style malicious-publish incidents we have seen migrate into the container ecosystem, become detectable rather than silent.
Pair signing with provenance attestations using SLSA level 3 as a target. The attestation should record the source commit, builder identity, and dependency tree. When an upstream library turns out to be malicious, provenance is the difference between an hour of forensics and a week of guessing which builds were affected.
What runtime controls are worth the operational cost?
Runtime controls have a real cost in engineering attention, so be selective. Three are worth the investment: a read-only root filesystem enforced via the pod security standard, dropped Linux capabilities with the kernel CAP_SYS_ADMIN never granted outside of explicitly-reviewed workloads, and a network policy that defaults to deny and is opened only by named services. These three together eliminate most container escape paths I have seen exploited in the wild.
eBPF-based runtime detection tooling, Falco being the obvious example, is worth running if you have an on-call team that will actually triage the alerts. If you do not, it generates noise that erodes trust in the security signal. A common mistake is deploying Falco with default rules, never tuning them, and then ignoring the resulting alerts. Either commit to ownership or skip the tool and invest in preventive controls instead.
How do you keep the registry clean?
Registries accumulate cruft fast. The discipline I recommend is a quarterly purge of any image not pulled in the last 90 days, an automated quota on tag count per repository, and a hard rule that no image without a signature and SBOM can be promoted to a production-eligible namespace. The Harbor and Artifactory native features handle most of this, but you will need to write a small reaper job for the freshness sweep.
Storage cost is the surface argument for cleanup, but the real reason is that a fat registry hides bad images. A registry with 200,000 tags makes it impossible to tell which images are actually deployed, which are abandoned, and which were pushed by a misconfigured CI pipeline three years ago. Keep it small enough that a human can audit it.
What does a defensible CVE policy look like?
A defensible CVE policy in 2026 is not about counts. It is about reachability and exploitation signal. The rule I use is that any reachable critical CVE with a public exploit blocks the build, any reachable critical without a public exploit blocks promotion to production, and unreachable CVEs go into a backlog with a service level objective of 60 days for criticals and 90 days for highs. The reachability filter typically cuts the active CVE list by 70 to 85 percent, which is the difference between a tractable backlog and a demoralized team.
How Safeguard Helps
Safeguard's container security workflow is built around reachable, exploitable CVEs rather than raw counts. Griffin AI ingests image SBOMs at build time, performs reachability analysis against your actual application code, and correlates findings with CISA KEV and commercial exploit feeds. Policy gates can be configured to enforce the build-blocking rules described above without writing custom OPA policies, and our zero-CVE base image catalog gives teams a maintained starting point with provenance attestations included. The TPRM module extends the same scrutiny to third-party container images you pull from public registries, scoring publishers on patch responsiveness and historical CVE density. Container security stops being a daily firefight.