The one finding in 21,075 that attackers already use

Draugr is an open-source CLI that runs the security scanners a project needs from one file and ranks their findings by what the project declares, so you know which to fix first. We scanned the 25 most-pulled Docker Official Images, each pinned to the digest its latest tag pointed at on 2026-11-01, with Trivy run through Draugr. Trivy reported 21,075 vulnerabilities across them, one of them a flaw whose CVE is on CISA's catalog of vulnerabilities known to be exploited and whose package has a fixed release. We counted it by matching every finding against a copy of the catalog. Trivy had already rated it critical, the severity a KEV listing raises a finding to, so Draugr's KEV signal had nothing to add. Draugr's fix list turned the 21,075 into 1,545 actions, and 131 upgrades among them clear every finding that has a fix published.

The sample#

The images are Docker Hub's official images in order of pulls on 2026-11-01, taken in rank order until 25 were in. Three of the top 28 were left out, hello-world because it carries no software of its own, and openjdk and centos because Docker Hub marks both deprecated. Each image was scanned as library/<name>:latest for linux/amd64, pinned by digest, and each digest is listed under Images.

A finding is one vulnerability in one package version in one image, counted once when the scanner reports it twice. Of the 25 images, 23 produced at least one finding. 20,515 of the findings are in operating-system packages and 560 in language packages such as Go modules, npm packages and Python wheels.

What KEV and EPSS moved#

Draugr reads two exploitability signals when the descriptor turns them on, and each can raise a finding's severity before the ranking reads it.

The KEV and EPSS counts in this post come from our own match of the findings against copies of both feeds, made after the scans.

By that count one finding is on the KEV catalog, CVE-2026-111497, an out-of-bounds write in the Brotli decoder with a fixed package published. Trivy had already rated it critical at 9.8, the severity KEV raises a finding to, so Draugr's KEV signal changed nothing in that image's report, which reads KEV nothing raised. When a scanner rates a listed CVE below critical and the descriptor turns KEV on, the signal raises the finding straight to critical and marks it ↑ KEV.

One in 21,075 invites the question of what a list that so rarely matches is worth. KEV holds flaws attackers are already using, and one of them in a service that faces the internet is enough to put the business at risk. A KEV check earns its place by naming that one finding when it is there, among twenty thousand that nobody is known to exploit.

Twenty-six findings scored 0.5 or more on the EPSS scores of 2026-10-31, and the KEV finding is one of them. Draugr raised each of the other 25 one band, from low to medium, which moves it from P3 to P2. All 25 come from two CVEs, in packages whose distribution has published no fixed release.

linux-libc-dev is the Linux kernel's headers package. Trivy matches the kernel's CVEs to it, and none of the 929 in each image has a fixed release.

In each of the ten images that carry one of these findings, the actions holding them head the Wait for a release list. A row there reads Replace or accept, and the image's owner decides between moving to a base that ships a fixed version and accepting the finding with a reason, which Draugr keeps in the report beside the finding.

The ranking#

Draugr ranks each finding P1 to P4 from its severity and two facts the descriptor declares about the component, its exposure (who can reach it) and its criticality (what the business loses when it stops). We cannot know how you run these images, so the descriptors declare neither. Draugr then assumes the worst, ranks each image as public and critical, and says so at the top of every report.

No component declares exposure or criticality, so every one is read as public and critical.
These bands rank severity alone. `draugr classify` makes them describe this application.

project: image-noise-nginx
config:
  exploitability:
    kev: cache
    epss: cache
    maxAge: 0s
  controls:
    images:
      enabled: true
components:
  - name: nginx
    images:
      - image: docker.io/library/nginx:latest
        digest: sha256:8e0328743c8e52ead9fac9c198d0893d63cd38e41b1d9ea629e092a8ac229a93

That is the descriptor for the first image in the sample. The other 24 differ only in the name and the digest.

With nothing declared, the bands follow severity and the two signals, and 5,261 findings came out P1, 11,216 P2, 4,598 P3 and none P4. Priority separates findings once a team declares what each component is, and that happens in your own descriptor.

Two lists of work#

Draugr turns findings into actions, one per package version to upgrade or replace, and sorts the actions into lists by the kind of work each one is. Summed across the 25 reports, two lists hold every finding.

The 131 upgrades are the work a team can do today. The largest across the sample is Upgrade stdlib v1.24.6 to v1.26.10, a rebuild with a newer Go toolchain, which clears 236 findings over four images. For an image you pull rather than build, declare it builtBy: upstream and its upgrade rows become a single action, take a newer image.

A plain draugr scan prints the ranked findings. The lists come from draugr scan --view actions, from output.view: actions in draugr.config.yaml, or from the HTML report that -o out/ --report html writes.

Turning the signals on#

Neither signal runs unless it is turned on: in the descriptor, under config.exploitability, or for one run with --kev and --epss. Each of the 25 descriptors carried this block.

config:
  exploitability:
    kev: cache
    epss: cache
    maxAge: 0s

epssThreshold moves the EPSS cut from 0.5. The EPSS and KEV guide covers what each signal measures and how to choose a threshold.

Limits#

• Each image is its latest tag on one day. A later digest of the same tag can read differently, and a team running a pinned older tag sees more.
• A scanner reports what a package's version says, and says nothing about whether the vulnerable code runs in the way the image is used. No reachability is claimed for images.
• A distribution can state that a CVE does not affect its build. Trivy reads those statements, so their findings are already left out of the counts above.

Images#

Rank is the image's place in Docker Hub's pull ranking on 2026-11-01. Ranks 16, 19 and 26 are the three images left out.

Your image#

Save this as my-image.saga.yaml, with your own image in place of nginx. It turns on the images control and both signals.

project: my-image
config:
  exploitability:
    kev: cache
    epss: cache
  controls:
    images:
      enabled: true
components:
  - name: my-image
    images:
      - image: docker.io/library/nginx:latest

Then install Draugr and Trivy, fetch the feeds and scan.

curl -fsSL https://draugr.dev/install.sh | sh
draugr tools install trivy
draugr feeds update
draugr scan my-image.saga.yaml --view actions

A finding KEV raised carries ↑ KEV, one EPSS raised carries ↑ EPSS with its score, and the SIGNALS line of the report counts both.

(Figures from scans on 2026-11-02 with Draugr 0.165.0 and Trivy 0.76.1, the Trivy vulnerability database of 2026-11-01, KEV catalog 2026.10.30 and EPSS scores of 2026-10-31, both feeds fetched 2026-10-31 23:04 UTC, of images pinned to their digests of 2026-11-01. Each descriptor read both feeds with cache, which reads the copies draugr feeds update stored and never fetches during a scan, and maxAge: 0s, which accepts a copy of any age, so every scan read one KEV catalog and one day's EPSS scores. A finding counts as on KEV when any of its CVE IDs is in the catalog, and its EPSS score is the highest among its CVE IDs. Its CVE IDs are any CVE in its rule ID, plus the CVE aliases the Go vulnerability database lists for a GO or GHSA identifier. Images and advisories move every day, so re-run it rather than trusting the numbers.)