Container adoption keeps outpacing container security. Sysdig's 2024 Cloud-Native Security and Usage Report found that 87% of container images shipped to production contain at least one critical or high-severity vulnerability, and 91% of containers are given more permissions than they actually use. Meanwhile, the average enterprise now runs thousands of images across dozens of registries, rebuilt multiple times per day through CI/CD pipelines that rarely pause to ask whether the base image, the dependencies, or the runtime configuration are actually safe.
Scanners like Trivy have become a default first step — fast, open-source, good at flagging known CVEs in an image layer. But a scanner is not a security program. This checklist walks through the practices that separate teams who catch a handful of CVEs from teams who actually reduce their container attack surface, and where a scan-only approach like Trivy leaves real gaps that Safeguard is built to close.
What does a real container security checklist actually cover?
A real checklist covers five stages, not one: base image selection, build-time scanning, registry hardening, runtime protection, and continuous drift detection. Trivy and similar open-source scanners focus almost entirely on stage two — scanning an image against CVE databases like the National Vulnerability Database (NVD) and vendor advisories. That's necessary but covers maybe 20% of the actual exposure surface. The other 80% includes things like whether a container is running as root (still the default in an estimated 60%+ of public Docker Hub images per multiple 2023-2024 audits), whether secrets are baked into image layers, whether the registry enforces image signing, and whether a workload's behavior at runtime matches what it was authorized to do. Teams that treat "we run Trivy in CI" as their container security program are, in practice, doing vulnerability listing, not risk reduction.
Why isn't scanning base images enough to stop supply chain attacks?
Scanning isn't enough because most supply chain attacks don't rely on a known CVE — they rely on trust. The 2024 XZ Utils backdoor (CVE-2024-3094) sat inside a compressed test file for weeks specifically because it wasn't a pattern any scanner's signature database would flag; it was caught by a Microsoft engineer noticing a 500ms SSH login delay, not by automated tooling. Trivy, like most SCA-style scanners, matches packages against known-vulnerability databases — it cannot tell you that a maintainer account was compromised, that a dependency was typosquatted, or that a base image was rebuilt with a tampered upstream artifact 6 hours ago. Docker Hub alone has hosted tens of thousands of images found to contain cryptominers or backdoors over the past few years, many with clean CVE scans because the malicious payload wasn't a "known vulnerability" — it was intentional. A checklist item that says "scan for CVEs" needs a second line underneath it: "verify provenance and integrity of every layer," which requires SBOM attestation, signature verification (Sigstore/cosign), and build reproducibility checks that most scanning-only tools don't attempt.
How often should container images be rescanned after deployment?
Images should be rescanned continuously, not just at build time, because the vulnerability landscape shifts under a static artifact. NVD published over 40,000 CVEs in 2024, and a base image that was "clean" on Monday can have three new critical CVEs disclosed against its OS packages by Friday — the image hasn't changed, but its risk has. Trivy is typically wired into CI/CD, meaning it scans once, at build time, and then stops. If a container built on March 1 is still running in production on June 1 without a rebuild, a scan-in-CI-only model has zero visibility into the three months of newly disclosed CVEs that now apply to it. Best practice is daily (or event-triggered, on new CVE publication) re-scanning of everything currently deployed, not just everything currently being built, plus automatic prioritization so a critical CVE in an internet-facing payment service gets triaged before a low-severity one in an internal batch job.
What percentage of container vulnerabilities are actually exploitable in production?
Independent research consistently puts the number of "reachable" or exploitable vulnerabilities at under 10% of everything a scanner flags — some vendor studies cite figures as low as 2-5% once runtime context is applied. This is the single biggest operational failure mode teams hit with CVE-only scanning: Trivy will return a list of hundreds of CVEs for a moderately complex image, sorted by CVSS severity, with no indication of whether the vulnerable function is ever called, whether the package is reachable from the network, or whether the container even has the permissions needed for an attacker to exploit it. Security teams then either drown in alert fatigue and start ignoring findings altogether, or burn engineering time patching packages that were never actually at risk. A 2023 study on alert fatigue in DevSecOps teams found that over 70% of security alerts across scanning tools go uninvestigated within 30 days — not because teams don't care, but because the signal-to-noise ratio makes triage infeasible at scale.
Does running containers as non-root actually stop real attacks?
Yes — running as non-root and dropping unnecessary Linux capabilities blocks or significantly limits a large share of real-world container escape techniques, because most documented escapes (including several CVEs in runc and containerd) depend on root-level privileges or specific capabilities like CAP_SYS_ADMIN being present inside the container. CVE-2024-21626, a runc vulnerability disclosed in January 2024, allowed container breakout via a leaked file descriptor and was significantly more exploitable in containers running with elevated privileges. Despite this, default Dockerfiles from official images and countless internal builds still run as UID 0 unless a team explicitly adds a USER directive and tests that the application still functions without root. A checklist that stops at "no critical CVEs" without also enforcing non-root execution, read-only root filesystems, and dropped capabilities (--cap-drop=ALL, adding back only what's needed) is leaving one of the cheapest, highest-leverage mitigations on the table.
How Safeguard Helps
Safeguard was built for exactly the gap described above: the space between "Trivy said the scan is clean" and "this workload is actually safe to run." Where CVE scanners stop at a point-in-time image scan, Safeguard extends coverage across the full container lifecycle:
- Continuous re-scanning with prioritization — every deployed image is automatically re-evaluated as new CVEs publish, and findings are ranked by real exploitability (network reachability, running privileges, exposure) instead of raw CVSS score alone, cutting through the noise that causes alert fatigue.
- Provenance and integrity verification — Safeguard verifies SBOM attestations and image signatures end-to-end, so a supply chain compromise that wouldn't trigger a CVE match (like a tampered base image or a compromised build step) still gets caught before deployment.
- Runtime-aware risk scoring — instead of a static list of hundreds of CVEs, Safeguard correlates scan results with actual runtime behavior and permissions, showing teams the small fraction of findings that represent genuine, reachable risk.
- Configuration and posture checks built in — non-root enforcement, capability drops, read-only filesystems, and secret-in-layer detection are checked automatically as part of the same pipeline, rather than requiring a separate tool or manual review.
- Registry and CI/CD-native enforcement — policies block non-compliant images from being promoted to production registries, closing the loop between detection and actual prevention rather than leaving remediation as a backlog item.
The goal isn't to replace the scanning step teams already trust — it's to make sure that step is the start of a container security program, not the entirety of one.