Container Image Security: Why Zero CVEs Doesn’t Prove an Image Is Trustworthy

A container image can pass a vulnerability scan and still carry software nobody intended to ship. That gap matters for platform and security teams: a zero-CVE result describes what a scanner recognized and matched against current vulnerability data. It says little about who produced the image, how it was built or whether its contents are trustworthy.

Scanners such as Trivy and Docker Scout help teams find known issues in software components. Docker Scout, for example, uses a software bill of materials (SBOM) to identify image contents and compare them with vulnerability data. That’s useful evidence for prioritizing remediation. It isn’t a general verdict on an artifact’s integrity.

My read is that teams should treat a clean scan as one input to an image’s security assessment. Trust requires a broader chain of evidence: what the image contains, where it came from, who signed it and how the build produced it.

A clean scan has a narrow scope

A scanner’s result depends on two things: its ability to identify the software inside an image and the vulnerability information available when the scan runs. “No known vulnerabilities found” means no matching known issue was identified in the components the tool could detect. It doesn’t mean the image is free of risk.

That assessment can change while the image stays exactly the same. A newly disclosed vulnerability may affect a package that had no known issue when the image was released. Because the image digest identifies an immutable artifact, teams can reassess that same image as vulnerability databases and advisories change.

Identification also has limits. Unexpected binaries, incomplete metadata or software installed outside familiar package managers can make an image harder to inventory accurately. If a component escapes detection, a scanner can’t match it to an advisory.

There’s a separate blind spot: malicious code doesn’t need a CVE. A compromised dependency can behave as intended by its attacker and still have no vulnerability identifier for a scanner to find. In that case, the scan may work as designed and report no known vulnerabilities. The missing evidence is about intent and origin, not a defect the tool was built to detect.

Supply-chain attacks can use legitimate publishing paths

The 2026 Nx Console compromise illustrates why artifact trust can’t rest on vulnerability counts. As described in the Nx Console incident postmortem, a malicious @tanstack/zod-adapter package was installed on a contributor’s machine during a routine pnpm install. Its payload stole a GitHub CLI OAuth token. An attacker then used that credential to publish a malicious Nx Console release through legitimate channels.

The release could pass through the publishing system because the credential belonged to a legitimate contributor, even though the attacker had taken control of it. A scanner looking for known vulnerabilities in packages isn’t designed to determine whether a publisher’s credential has been stolen or whether a release reflects the project’s intent.

Container images face the same underlying challenge. A familiar name in a public registry doesn’t establish which source code went into an artifact, which dependencies were included or whether the expected publisher created that specific release.

Provenance, signatures and digests answer different questions

Teams need to distinguish several kinds of evidence that are often grouped together under “image security.” A digest identifies the exact artifact being consumed. It helps ensure that deployment refers to a specific image rather than relying only on a mutable name or tag.

A cryptographic signature can show that a particular identity signed that artifact. The signature’s value depends on whether the organization recognizes and trusts that identity. A signature alone doesn’t show that the image was built from the source code or dependencies the organization expected.

Provenance adds information about an artifact’s origin and production: its source, builder and build process. Taken together, these controls give teams a more useful basis for deciding whether an image meets their requirements. Each answers a different question: which artifact is this, who signed it, and how was it produced?

That distinction turns image review into a policy decision teams can make consistently. An organization can require images to come from approved builders, carry provenance and be signed by an expected identity. A scan then contributes information about known exposure, while the other evidence addresses identity and production.

Image contents affect what happens after a breach

Provenance tells teams about production, but the contents still matter. Container images may include shells, package managers, compilers, network utilities and debugging tools inherited from a base image. Some of those tools may be unnecessary for the application’s runtime needs.

Removing extra tools doesn’t automatically eliminate vulnerabilities, and a smaller image isn’t proof of trustworthy origins. But reducing unnecessary software can limit what an attacker can do if they gain execution inside a container. The practical aim is to keep the artifact’s contents intentional and identifiable, and to connect them to a controlled build process.

That calls for a closer look than a single scan score. Teams need to understand which packages and binaries are present, whether they belong in the runtime image and whether they can trace back to declared dependencies and build inputs. An SBOM can support that inventory, while provenance and signatures provide separate evidence about how the artifact reached the registry.

Keep assessing images after release

Passing checks at build time doesn’t settle an image’s security status for its entire lifetime. Dependencies can reach end of life, and new advisories can change how teams should assess software already deployed. The artifact may remain byte-for-byte identical while its risk picture changes.

This is why an image’s identity and its security assessment should be tracked separately. The digest remains a stable reference to the artifact; vulnerability intelligence and policy decisions need to be revisited as conditions change. Teams that monitor images after deployment can connect new information to the exact artifacts in use and decide whether they need remediation or replacement.

Developer workflows also shape whether these checks become routine. Developers shouldn’t have to investigate every image from scratch, and security teams can’t manually review every artifact pulled into a large environment. Platform teams can provide approved images with evidence about their contents, provenance and build process, then make those requirements part of the normal path to deployment.

A zero-CVE report remains valuable: it helps teams understand known exposure at a particular point in time. The operational takeaway is to pair that report with evidence about the image’s origin, composition, signature and production process. That gives teams a clearer basis for deciding what to deploy—and a way to revisit that decision as new information emerges.