The 0 CVE problem: When clean scans lie

Over the past few years, CVE scanning, particularly container image scanning, has become standard practice across organizations.

The logic is simple: when your software contains known vulnerabilities, your product, data, and customers are at risk. That’s why scanners like Trivy and Grype have become the go-to solutions for identifying CVEs in container images.

Teams rely on these scanners to surface all known issues so that they can be tracked and remediated. And while in theory, nothing’s better than getting back a scan with 0 CVEs, in reality, a clean scan doesn’t mean your image is secure.

Debian and the illusion of a clean image

So, I’ve just claimed that a “0 CVEs” result isn’t always trustworthy, but I don’t expect you to just take my word for it. Let’s look at a real-world example to prove it.

We’ll use a Debian image, since it’s one of the most commonly used distributions for containerized applications. Debian organizes its images into three main branches: stable, testing, and unstable.

The stable branch contains official production-ready releases. As of now, the latest stable version is called Bookworm. Here’s what happens when we scan the official debian:bookworm image with Trivy, one of the most popular open source CVE scanners:

As you can see, there are 79 vulnerabilities in the official Debian Bookworm image. These vulnerabilities come from operating system packages – some of them have no fixed versions, and thus can’t be fixed by simply installing a newer package.

Now, let’s scan the testing version of Debian images, called Trixie:

According to Trivy, there are zero vulnerabilities. And at first glance, that might make sense – maybe this newer image version includes the latest packages with all known CVEs fixed.

But we just saw that the latest Debian image, debian:bookworm, still has vulnerabilities – some of which have no available fixes. So how could a more recent Debian-based image report 0 CVEs?

The answer lies in a bug we uncovered while scanning a Debian-based image that we knew couldn’t possibly be vulnerability-free. It turned out to be a parsing issue in Trivy’s handling of Debian’s metadata. You can find the full details in this pull request on the Trivy GitHub repo.

Alpine and the silent gaps in reporting

Think the example above is an exception to the rule? Think again. You might argue that Debian’s unstable version shows 0 CVEs because it’s not an official, stable release. And since it’s rarely used in production environments, the risk might seem negligible.

But what happens when we scan the latest official Alpine image?

Zero again. Don’t get me wrong, it makes sense that Alpine images would have fewer vulnerabilities because they’re designed to be minimal, and fewer packages mean fewer potential issues. But no vulnerabilities whatsoever? That’s suspicious.

The explanation for this lies not with the image itself, but with the Alpine security advisory.

If we look at Debian’s security advisory, we can see a detailed list of all packages in the Debian repository, along with the CVEs associated with them – both fixed and unfixed:

But Alpine’s advisory only lists which CVEs have been fixed – not all the CVEs that affect each package.

As a result, Trivy will only detect vulnerabilities in Alpine that have already been fixed – which means the latest Alpine image will almost always show 0 CVEs.

Why scanners sometimes get it wrong

There are several reasons why a scan might return a 0 CVEs result – and not all of them mean clean images.

CVE scanning involves multiple steps, which can each affect the final outcome:

1. Building a vulnerability database – Each scanner maintains a local database, which holds data on all of the known vulnerabilities
2. Package analysis – The scanner identifies which packages are included in a container image.
3. OS detection – The scanner determines which operating system the image is based on to match in the database.
4. Vulnerability detection – Finally, the scanner matches identified packages against known CVEs in the database.

After scanning thousands of images, I’ve witnessed issues in each of the stages.

In the case of Debian Trixie, for example, the problem was a bug with matching the OS name with the one expected in the database – no CVEs were reported and there was no log indicating that anything was wrong. And with Alpine, the issue was rooted in design: the vulnerability database only includes fixed vulnerabilities with no support for showing unfixed ones – so scanners never report them.

To be clear, a 0 CVE result can be legitimate. But if you scan a random image and get a completely clean result without intentionally reducing its attack surface, you shouldn’t trust the outcome without deeper investigation.

The added risk of 0 CVEs

Security teams work hard to reduce and eliminate known vulnerabilities, but false 0 CVE results can also mean:

• You're missing the low-hanging fruit. Many CVEs are easy to fix, often just a matter of applying routine security updates. For example, Debian maintains a security repository specifically for patched packages. If your scanner incorrectly reports 0 CVEs, these known, fixable vulnerabilities will remain in your image. This is especially risky with critical CVEs, which tend to be patched quickly. So if you're not scanning correctly or frequently, you’ll miss them.
• Your scanner errors will be exposed. If the 0 CVE result is caused by a bug in your scanner, it might go unnoticed for a while, but eventually, it’ll surface – maybe after a scanner update or when a customer scans the image. If that happens in a production environment or on a customer’s side, you’ll be forced to react under pressure, diverting resources and trust to clean up a preventable issue.

What you can do about it

Here are a few steps you can take to ensure your vulnerability data is trustworthy:

1. Use multiple scanners. No single scanner is perfect. Different scanners may have different philosophies about how to show CVEs, so running scans with more than one significantly improves your coverage.
2. When you see ‘0 CVEs,’ investigate. If a scan returns 0 vulnerabilities, don’t assume it’s clean by default. Pause and analyze. Understand why the result is clean, or consult an expert to verify.
3. Use secure-by-design base images. Prioritize images that are built from scratch to be CVE-free and maintained for you. Using these secure-by-design images gives you a clean foundation and drastically minimizes risk over time.