In March 2024, a Microsoft engineer named Andres Freund noticed that SSH logins on a Debian testing box were taking roughly 500 milliseconds longer than they should. That anomaly led him to CVE-2024-3094, a multi-year backdoor planted inside the xz-utils compression library — a dependency baked into countless Linux base images used to build containers. The bug sat two steps removed from any application manifest, invisible to tools that only check declared dependencies. It's a useful reminder that container security scanning isn't a checkbox; it's the difference between catching a backdoor in a build pipeline and shipping it to production. Containers now run the majority of production workloads, and each image bundles an OS layer, a language runtime, and dozens of transitive open-source packages that no developer reads line by line. Vendors like Sonatype built their name scanning open-source components for license and vulnerability risk. Container images demand a wider lens: OS packages, layer history, secrets, misconfigurations, and runtime behavior all need coverage too. If you're evaluating container security software for the first time, that SCA-versus-container distinction is the first thing worth understanding — it's the gap most tooling gets wrong.
What Is Container Security Scanning, and Why Does It Matter Right Now?
Container security scanning is the automated inspection of a container image's layers, packages, configuration, and metadata to find known vulnerabilities, exposed secrets, and risky settings before that image reaches production. It matters now because the numbers are not improving on their own: Sysdig's 2023 Cloud-Native Security and Usage Report found that 87% of container images contained at least one high- or critical-severity vulnerability, and most of those images shipped with far more installed packages than the application actually used. A typical Node.js or Python base image can carry 200-500 OS-level packages, most unrelated to the app itself, each one a potential entry in the next CVE feed. Scanning has to happen at three points — at build time in CI, at rest in the registry, and continuously against running workloads — because a clean image today can become vulnerable tomorrow when a new CVE is published against a package that's already sitting in your registry.
How Do Vulnerabilities Actually Get Into Container Images?
Vulnerabilities enter containers primarily through inherited base images and copy-pasted Dockerfiles, not through code the team wrote itself. When Log4Shell (CVE-2021-44228) was disclosed on December 9, 2021, the vulnerable log4j-core JAR wasn't sitting in most teams' direct dependency lists — it was three or four layers deep, pulled in transitively by a logging framework, itself pulled in by an application framework, itself baked into a shared internal base image used by dozens of services. Docker Hub alone hosts more than 8 million public repositories, and a huge share of internal engineering images start from a FROM line pointing at one of them, often pinned to latest rather than a scanned, immutable digest. Add unpatched OS packages, forgotten debug tools left in production images, hardcoded credentials committed during a rushed deploy, and Dockerfiles that run as root by default, and you get an attack surface that grows every time someone runs docker build without a gate in front of it.
Why Isn't Traditional SCA Enough for Containers?
Traditional software composition analysis isn't enough for containers because it was built to read manifests — package.json, pom.xml, requirements.txt — not to inspect what actually gets installed inside a filesystem layer. Sonatype's Nexus Lifecycle and Nexus IQ Server made their name doing exactly that: parsing declared dependencies and matching them against a vulnerability database, an approach that works well for a single application's direct and transitive open-source packages. Sonatype's own 2024 State of the Software Supply Chain report found more than 512,000 malicious open-source packages published that year, underscoring how much of this risk now originates upstream, before a manifest is even written. But a container image is not a manifest — it's a compiled filesystem. It includes OS packages installed via apt or apk that never appear in any package.json, binaries copied in during multi-stage builds, and layers inherited from a base image maintained by a completely different team or vendor. SCA-first tools that bolted on container scanning later tend to treat the image as one more artifact to parse for known manifests, which means OS-layer CVEs, layer provenance, and Dockerfile misconfigurations often get shallower coverage than they would from a scanner built container-first.
What Should a Container Security Scanning Tool Actually Check?
A container security scanning tool should check at least five layers, and skipping any one of them leaves a real gap. First, OS packages and libraries in every layer, matched against a continuously updated vulnerability feed rather than a database refreshed weekly. Second, application-level dependencies bundled into the image, whether that's a Python virtualenv, a Java JAR, or a Go binary compiled statically. Third, configuration — is the container running as root, is a Kubernetes securityContext missing, is a port exposed that shouldn't be? Fourth, embedded secrets: API keys, private keys, and cloud credentials that end up baked into an image layer because someone ran COPY .env . and forgot to remove it before the final build stage. Fifth, provenance and integrity — does the image match a signed, attested build, or could it have been tampered with between CI and the registry? The 2020 SolarWinds compromise and the 2024 xz-utils backdoor both succeeded, in part, because build and distribution pipelines lacked verifiable provenance, not because a CVE database was out of date.
How Does Container Scanning Fit into a Broader Supply Chain Security Program?
Container scanning fits in as one control among several, and treating it as the whole program is how gaps reappear. Executive Order 14028, signed in May 2021, pushed federal agencies and their vendors toward software bills of materials (SBOMs) and provenance attestation, and frameworks like SLSA (Supply-chain Levels for Software Artifacts) formalized what "verified provenance" should look like for a build. A mature program pairs image scanning with SBOM generation at build time, cryptographic signing of images (commonly via Sigstore/cosign), admission control in the cluster that blocks unsigned or unscanned images from running, and drift detection that flags when a running container no longer matches what was scanned. Scanning without policy enforcement just produces a report nobody reads; enforcement without accurate scanning just blocks builds on stale data. The two have to move together, which is exactly where point solutions focused on one stage of the pipeline start to show seams.
How Safeguard Helps
Safeguard was built to close the gap between "we scanned it" and "we know it's safe to run," treating container security software as one connected control rather than a bolt-on to an existing SCA product. Where legacy SCA tools parse manifests and extend outward to containers as an afterthought, Safeguard scans the actual image: every OS package, every application dependency, every layer, matched continuously against updated vulnerability intelligence rather than a periodic batch job — so a CVE published against a package already sitting in your registry gets flagged the same day, not at the next scheduled scan.
Safeguard generates and tracks SBOMs automatically at build time, verifies image signatures and build provenance so a compromised CI step or a tampered registry push gets caught before deployment, and enforces policy at the point that matters — blocking unsigned, unscanned, or policy-violating images from ever reaching a cluster, instead of just filing a ticket after the fact. Findings are prioritized by real exploitability and reachability, not raw CVE count, so teams triaging hundreds of "critical" findings across dozens of images can tell which handful actually sit on a code path that's reachable from the outside.
For teams that already run Sonatype for open-source component governance, Safeguard is built to sit alongside it and close the container-specific gaps: OS-layer vulnerability coverage, Dockerfile and runtime misconfiguration checks, secrets detection inside image layers, and provenance verification from build to deploy. The goal isn't a bigger dashboard — it's fewer surprises like a two-year-old backdoor sitting three layers deep in a base image nobody re-scanned since the day it was pulled.