A Container Image Can Be Vulnerability-Free and Still Not Be Trustworthy
Zero is a powerful number in container security. Run a container image through a tool such as Trivy or Docker Scout and imagine the result comes back with no known vulnerabilities. It is tempting to treat that number as if the image is clean and safe to deploy, but what did the scan actually prove?
It proved only that the scanner found no known vulnerabilities in the components it could identify. That is useful information, but it’s not evidence that the artifact itself is trustworthy. The distinction matters because an image can have zero known CVEs while its origin, build process, dependency selection and software composition remain largely unknown.
Recent supply-chain incidents show why. In the 2026 Nx Console compromise, an attacker used a stolen GitHub credential to publish a malicious version of the extension through legitimate publishing channels. The publishing system accepted the release because the attacker was operating with a compromised legitimate contributor credential.
Container images face the same fundamental problem, because a vulnerability scan doesn’t tell us everything we need to know before trusting an artifact in production.
Zero CVEs Only Tells You What Is Known Today
Vulnerability scanners generally identify packages and other software components in an image and correlate their versions against vulnerability databases and security advisories. Docker Scout, for example, analyzes image contents using an SBOM and evaluates the components against vulnerability data. Trivy can similarly scan image and SBOM contents for known vulnerabilities.
So when the result says no known vulnerabilities, the useful interpretation is: “No known vulnerabilities were identified in the components the scanner could identify.” But that’s different from saying the software is safe.
New vulnerabilities are disclosed continuously, so a package that produces a clean result today may have a vulnerability disclosed tomorrow. In fact, the image itself doesn’t have to change for its vulnerability assessment to change. A scanner can reassess an image as new vulnerability data becomes available, using the metadata associated with the artifact.
Scanner results also depend on accurately identifying the software present in the image. Unexpected binaries, incomplete metadata or software installed outside standard package management mechanisms can make that harder.
There is another, more important limitation: malicious software doesn’t need a CVE.
A compromised dependency can contain malicious code without having a vulnerability identifier at all. The scanner may correctly report zero known CVEs because it’s looking for known vulnerabilities, not malicious intent.
That is what makes supply-chain compromises particularly difficult. In the Nx Console incident, 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, which was later used to publish a malicious Nx Console release. The eventual release was accepted through the legitimate publishing process and distributed through marketplaces.
The scanner isn’t wrong in this situation, because we’re asking it to answer a question it was never designed to answer.
Trust Starts With Knowing Where the Image Came From
Suppose an image passes the scan.
The next question should be: Who built it, and how?
Public registries make image consumption easy, but a familiar image name doesn’t establish who produced an artifact, what source code was used, what dependencies were incorporated or whether the publisher intended to release it.
There are several different pieces of evidence here, and they are easy to conflate.
An image digest identifies the exact artifact being consumed. A cryptographic signature can establish that a particular identity signed a specific artifact. Whether that identity is one an organization trusts is a separate policy decision.
Provenance provides evidence about the source, builder and process used to produce the artifact.
These are complementary controls.
A signature can establish that an image was signed by an expected identity. It doesn’t, by itself, prove that the image was built from the source code or dependencies you expected. For container images, we need evidence about both the artifact and the process that produced it.
What Is Inside the Image Matters Beyond Vulnerabilities
Now look at the image itself.
A typical container image can contain considerably more software than the application actually requires: shells, package managers, compilers, network utilities, debugging tools and other operating system packages inherited from a base image.
Removing a shell, compiler or package manager doesn’t necessarily remove a vulnerability. If an attacker does gain execution inside a container, having fewer tools available can constrain what they can do next.
The objective should be to produce an artifact where the software that remains is intentional, identifiable and tied back to a controlled build process.
Trust Has to Continue After Deployment
Even a well-built image doesn’t remain permanently secure.
A new vulnerability can be disclosed tomorrow. A dependency can reach end of life. A security advisory can change the assessment of software that passed every check when the image was released.
This is why artifact trust has to continue beyond the initial build.
An important distinction is that the artifact and its security assessment have different lifecycles. An image digest identifies an immutable artifact, but the vulnerability information used to assess that artifact changes over time. A new advisory can change the risk assessment without changing a single byte of the image.
Give Developers a Better Default
A developer should not need to become a software-supply-chain investigator every time they need a container image. Security teams cannot manually investigate every image pulled into an enterprise environment either.
Give developers access to images that already carry evidence about their provenance, composition and build process. Make those requirements part of the platform rather than another checklist developers have to navigate.
Vulnerability scanning remains an important part of that process. A low or zero known-CVE count can help teams assess known exposure and prioritize remediation. But it should be one piece of evidence, not the entire trust model.
A clean vulnerability report is valuable, but it only answers one question. Trust also depends on evidence about where the image came from, what it contains and how it was built.
