A container image is evaluated and multiple critical CVEs are reported by the vulnerability scanner. The vendor asserts the image was rebuilt recently and already contains the fixes, but the package versions remain unchanged.

The scanner cannot validate rebuild-based patching, so the findings persist. As a result, risk decisions are driven by scanner limitations rather than the image's actual security state. In short: rolling distros break assumptions that most commercial scanners are built on.

Most commercial scanners are build around static OS releases that have been around for ages:

  • RHEL / Ubuntu LTS / Debian stable
  • Versioned "OS + errata" lifecycles
  • Long-lived CVE → fixed-in-version mappings

Which works great when fixes are aligned with version bumps like:

libssl 1.1.1a → CVE fixed in 1.1.1b

But rolling distributions don't work like that. Packages are continuously rebuilt, so even if the version stays the same, the content can change.

RUN apk add --no-cache myapp=1:1.2.3-r1

Fixes are applied through these rebuilds rather than by bumping the version.

An epoch (-r1) is a number that overrides the normal version, forcing the package manager to treat a package as newer than any previous version, even if the upstream version looks like the "older" version.

This is useful for CVE fixes or other rebuilds where the version number hasn't changed but the package content has and is foundational for rolling distributions.

Why scanners matter to get a valid result

Rolling distributions deliver security fixes by rebuilding packages continuously, rather than always changing version numbers.

Accurate CVE detection requires aligning three things at the same point in time:

  • the image digest,
  • the package repository state,
  • and the security advisories.

Grype and Trivy handle this alignment automatically, detecting that rebuilt packages are safe even if the version hasn't changed. Most commercial scanners rely on static version-to-CVE mappings, which can trigger false positives for patched, rebuilt packages.

Detecting CVEs in rolling distributions isn't just about versions — it's about when a package was built.

An easy summary would be: Trivy and Grype answer "what known CVEs exist in this artifact?" while Sysdig, Aqua, etc. answer "is this workload actually risky in my environment right now?"

Grype and Trivy inspecting a given artifact at rest, like container images, package version, SBOMs etc. and identify OS packages and language dependencies to match them with the CVE database. This process is: Deterministic, Reproducible, Fast, CI/CD-friendly and doesn't need a runtime context. If the image or package has a CVE, it gets reported — reachable or not.

Let's break this down into areas that are covered by scanner and how this depends on the image type being used.

a) Runtime Awareness

Commercial scanners track what's running — processes, libraries, ports, and capabilities — but in rolling distributions, package versions change constantly, making runtime context quickly outdated. Trivy and Grype scan the exact image or SBOM at build time, giving accurate, reproducible CVE results even on rapidly changing systems.

b) Reachability & Exploitability

Commercial tools attempt to prioritize vulnerabilities by reachability and known exploits. On rolling distributions, the risk scoring can lag behind updated packages, leading to stale or misleading assessments. Trivy and Grype instead detect CVEs in the actual current versions, ensuring no vulnerability is missed regardless of upstream changes.

c) Policy, Posture & Guardrails

Commercial scanners layer policy enforcement, compliance checks, and security guardrails. However, in rolling distributions, constant package updates can trigger false positives or unnecessary blocks, and policies can quickly become misaligned. Trivy and Grype focus on transparent CVE visibility, letting teams respond in CI/CD pipelines without being slowed by constantly shifting baselines.

How CVE fixes become available in the reporting

Let's have a closer look on how scanners "learn" about CVEs and get their data:

Trivy DB Lifecycle

  1. Upstream feeds (NVD, GitHub, distro advisories) are aggregated.
  2. A pipeline rebuilds the Trivy DB every ~6 hours on GitHub.
  3. The Trivy DB is published as an OCI artifact on GHCR.
  4. Trivy CLI pulls the latest DB if running with auto‑update enabled.

Grype DB Lifecycle

  1. Vulnerability data sources are downloaded with vunnel.
  2. The data is normalized and pulled into a local build.
  3. Grype‑DB builds an SQLite DB and packages it.
  4. A daily CI pipeline publishes the latest DB to grype.anchore.io or mirrors.
  5. The Grype client (CLI) auto‑updates its local DB during scans.

Commercial Scanner Update Lifecycle

  1. Internal research team ingests CVE announcements, vendor advisories, exploit feeds.
  2. Analysts validate and enrich the data (backports, exploitability info, contextual metadata).
  3. Change set is pushed to scanner agents or cloud feeds.
  4. Scanner dashboards/agents ingest updates often within SLA windows.

Why some scanners are better for rolling distributions

Rolling distributions evolve over time, while scanners evaluate images as static snapshots, which creates time-slice skew.

In Rolling distributions like Wolfi, Alpine edge, etc.:

  • Packages are rebuilt constantly
  • The version may not change
  • The content does (patched source, different compile flags, backports)

So the real signal of "fixed" is: this specific build is fixed as of this advisory. Grype and Trivy are designed around this reality. They both:

  • Ingest Chainguard/Wolfi/Alpine security advisories
  • Match package name + version + release/build
  • Understand exact fix states per build

That means that as soon as Chainguard publishes an advisory → scanners know and are not waiting for:

  • NVD enrichment
  • CVE scoring
  • vendor correlation pipelines

Which changes the Update latency to minutes or hours, not days. Commercial scanners usually wait for CVE DB propagation.

The killer feature

Time-slice awareness is the killer feature. Rolling distributions only make sense when the image digest, the package repository, and the security advisories are evaluated in the same moment in time.

Grype and Trivy ask a single, correct question: "At the time this image was built, what did the distro say about this package?"

They don't assume the latest repo, the newest CVE database, or static version ranges. They evaluate the exact time slice the image came from. Most scanners don't — and that's why they misfire on rolling distros.

None

Final summary

In rolling distributions, CVEs are often a lagging signal — fixes may ship before a CVE exists, some fixes never get a CVE, and a single rebuild can address multiple CVEs at once.

Grype and Trivy account for this by starting from distro security advisories and treating CVEs as metadata labels rather than the source of truth. Most commercial scanners do the opposite, beginning with CVEs and trying to map them back to packages after the fact, an inversion that inevitably costs both time and accuracy.

Rolling distros don't need smarter scanners. They need scanners that respect time. Grype and Trivy do. Most others don't.