Docker Scout oder Trivy: warum dasselbe Image 236 oder 474 CVEs hat

31.07.2026

Thema: alle Beiträge zu Docker

Dasselbe Image, derselbe Tag, zwei Scanner: 236 gegen 474 CVEs. Warum die Zahl vom Werkzeug abhängt und was das für eure Container-Security bedeutet.

Inhaltsverzeichnis

• Der Versuchsaufbau
• Das Ergebnis
• Ursache 1: Scout zählt CVEs, Trivy zählt CVEs mal Pakete
• Ursache 2: Quellpaket gegen Binärpaket
• Ursache 3: Die Schwere kommt aus verschiedenen Quellen
• Ursache 4: Die Datenbanken sind nicht deckungsgleich
• Der eigentliche Punkt: Was misst diese Zahl?
  • Ein CRITICAL, das nicht existiert
• Was das für die Praxis heißt
• Und wem gehört die Messung?
• Fazit

Ich habe nginx:1.29-bookworm an einem Vormittag mit zwei Scannern geprüft. Dasselbe Image, derselbe Digest, keine Filter. Docker Scout meldet 236 Vulnerabilities, Trivy meldet 474. Bei CRITICAL steht es 1 zu 11.

Die Antwort vorweg, denn sie ist die eigentliche Nachricht dieses Beitrags: Die CVE-Zahl ist keine Eigenschaft deines Images. Sie ist eine Eigenschaft deines Scanners. Wer diese Zahl in einen Report schreibt, ohne sie erklären zu können, misst nicht Sicherheit, sondern Werkzeugwahl.

Der Versuchsaufbau

Beide Scans liefen am selben Tag gegen denselben Image-Digest, ohne Filter und ohne --ignore-unfixed:

docker scout cves nginx:1.29-bookworm
trivy image --scanners vuln nginx:1.29-bookworm

Das Image: nginx:1.29-bookworm, Digest sha256:8adbdcb9..., Basis Debian 12.12 Bookworm.

Das Ergebnis

Faktor 2 bei der Gesamtzahl, Faktor 11 bei CRITICAL. Der naheliegende Verdacht wäre: verschiedene Datenbanken, eine davon veraltet. Der Verdacht ist falsch. Beide ziehen dieselbe Quelle. Scouts Links tragen den Parameter s=debian, Trivy meldet DataSource: debian. Es sind die Debian-Advisories, in beiden Fällen.

Der Unterschied entsteht vollständig im Werkzeug. Vier Ursachen, alle nachvollziehbar.

Ursache 1: Scout zählt CVEs, Trivy zählt CVEs mal Pakete

Scout meldet eine Zeile pro CVE und hängt alle betroffenen Pakete als Liste daran. Trivy meldet eine Zeile pro CVE und Binärpaket.

Deshalb hat Trivy 474 Findings, aber nur 302 eindeutige CVE-IDs. CVE-2026-31789 steht bei Trivy zweimal, einmal für libssl3 und einmal für openssl. Bei Scout steht sie einmal. Dieselben Doppelzähler entstehen bei perl und perl-base oder bei util-linux und util-linux-extra.

Damit ist ein Drittel der Differenz schon erklärt, ohne dass ein einziges Sicherheitsproblem dazugekommen oder weggefallen wäre.

Ursache 2: Quellpaket gegen Binärpaket

Scouts „34 betroffene Pakete” sind Quellpakete: tiff, openssl, perl. Trivys „68 Pakete” sind Binärpakete: libtiff6, libssl3 und openssl getrennt, perl-base.

Debian baut aus einem Quellpaket regelmäßig ein halbes Dutzend Binärpakete. Beide Zahlen beschreiben dasselbe Image, nur in unterschiedlicher Auflösung. Für die Frage „was muss ich patchen” ist das Quellpaket sogar die passendere Einheit, denn du aktualisierst am Ende genau eines davon.

Ursache 3: Die Schwere kommt aus verschiedenen Quellen

Hier wird es interessant. Von den 224 CVEs, die beide Werkzeuge melden, stufen beide nur 130 gleich ein. Das sind 58 Prozent.

Der Mechanismus dahinter ist eine schlichte Design-Entscheidung, die beide Hersteller unterschiedlich getroffen haben:

• Scout nimmt den CVSS-v3-Wert und fällt nicht zurück. Gibt es keinen, steht UNSPECIFIED. Das passiert 43-mal.
• Trivy nimmt die Einstufung der Distribution, wenn Debian eine vergeben hat, und sonst NVD als Fallback. Deshalb nur 9-mal UNKNOWN.

Von Scouts 43 nicht eingestuften CVEs sind bei Trivy zwei CRITICAL, neun HIGH und dreißig MEDIUM. Und andersherum: Alle 11 Trivy-CRITICALs tragen SeveritySource: nvd. Keine einzige davon stammt aus Debians eigener Bewertung.

Das erklärt die 1 gegen 11. Scout zeigt dir im Kern, wie Debian das Risiko einschätzt. Trivy zeigt dir, wie NVD es einschätzt, wenn Debian schweigt. Beides ist verteidigbar. Nur ist es nicht dasselbe.

Ursache 4: Die Datenbanken sind nicht deckungsgleich

Trotz gemeinsamer Quelle decken sich die Mengen nicht vollständig:

• beide: 224 CVEs
• nur Trivy: 78, darunter CVE-2023-45853 und CVE-2016-2781
• nur Scout: 12, darunter CVE-2023-44487 und CVE-2024-6716

Beide Werkzeuge ergänzen die Distributionsdaten um eigene Quellen und schneiden sie unterschiedlich zu. Es gibt keinen Scanner, der „alle” CVEs kennt.

Der eigentliche Punkt: Was misst diese Zahl?

Bis hierhin ist das ein technisch sauberer Vergleich, und beide Werkzeuge kommen gut weg. Beide zählen korrekt. Sie zählen nur Verschiedenes.

Unangenehm wird es eine Ebene höher. Denn die CVE-Zahl ist in vielen Unternehmen längst eine Kennzahl: Sie steht in Quartalsberichten, in Release-Gates, in Audit-Nachweisen. „Wir scannen jedes Image, kritische Findings blockieren den Build.” Das klingt nach Sicherheit und ist bequem messbar.

Nur misst diese Kennzahl, wie wir gerade gesehen haben, in erster Linie eure Werkzeugwahl. Ein Wechsel des Scanners lässt eure Sicherheitslage über Nacht schlechter aussehen, ohne dass sich an eurer Software ein einziges Byte geändert hätte. Umgekehrt lässt sich jede Zahl senken, indem man das Werkzeug tauscht statt das Image.

Und dann gibt es noch den Fall, der den Unterschied zwischen Messen und Wissen wirklich sichtbar macht.

Ein CRITICAL, das nicht existiert

Trivys prominentester Fund in diesem Image ist CVE-2023-45853 in zlib1g, CVSS 9.8, also CRITICAL. Ein Integer-Overflow in zipOpenNewFileInZip4_6. Scout meldet sie überhaupt nicht.

Wer recht hat, lässt sich prüfen. Die betroffene Funktion gehört zu MiniZip, einer Zusatzkomponente im zlib-Quellbaum. Also holt man sich die Bibliothek aus dem Image und schaut nach, ob sie überhaupt drin ist:

cid=$(docker create nginx:1.29-bookworm)
docker cp $cid:/usr/lib/x86_64-linux-gnu/libz.so.1.2.13 ./libz.so
docker rm -f $cid

nm -D libz.so | grep -c zipOpen    # 0
nm -D libz.so | grep -c inflate    # 21

Null Treffer für MiniZip. Die 21 inflate-Symbole sind die Gegenprobe, nm liest die Datei also korrekt. Der Debian-Tracker sagt genau das, in dürren Worten:

[bookworm] - zlib <ignored> (contrib/minizip not built and src:zlib not producing binary packages)

Der verwundbare Code ist in diesem Image nicht vorhanden. Trivy meldet eine CRITICAL für eine Funktion, die in der ausgelieferten Bibliothek fehlt. Das ist kein Fehler von Trivy: Der Scanner vergleicht Paketnamen und Versionen mit einer Advisory-Datenbank, mehr kann er im Standardmodus nicht. Er weiß nicht, was Debian in dieses .so hineinkompiliert hat.

Aber genau hier laufen zwei Auffassungen von Security auseinander.

Die eine sagt: Wir messen CVEs, weil wir wissen wollen, wo wir tatsächlich exponiert sind. Dann ist die Zahl ein Anfang und nicht das Ergebnis. Dann schaut jemand nach, ob der verwundbare Code überhaupt im Image liegt, ob der Pfad erreichbar ist, ob der Container die Komponente je aufruft. Das kostet Zeit und Fachwissen, und es führt zu einer kürzeren, aber ehrlichen Liste.

Die andere sagt: Wir messen CVEs, damit wir im Ernstfall eine Begründung haben. Ein grünes Gate, ein Scan-Bericht mit Datum, eine Kennzahl im Trend nach unten. Wenn dann doch etwas passiert, war der Prozess eingehalten und niemand ist schuld. Das ist Compliance, und Compliance ist nicht wertlos. Sie ist nur etwas anderes als Sicherheit, und sie wird gefährlich, wenn man beides verwechselt.

Der Unterschied fällt im Alltag nicht auf, weil beide Auffassungen exakt dieselbe Aktivität erzeugen: Man lässt einen Scanner laufen. Er fällt erst auf, wenn jemand fragt, warum die Zahl heute 474 ist und letzten Monat 236 war.

Was das für die Praxis heißt

Fünf Konsequenzen, die sich direkt aus den Zahlen oben ergeben:

1. Vergleiche nie absolute Zahlen zwischen Werkzeugen. 236 und 474 sind beide richtig. Sie sind nur nicht dieselbe Größe, so wenig wie Meilen und Kilometer.
2. Legt ein Werkzeug als Referenz fest und bleibt dabei. Wechselt ihr es, ist die Zeitreihe gebrochen. Sagt das dann auch dazu, statt einen Sprung im Bericht unkommentiert zu lassen.
3. Messt das Delta, nicht den Absolutwert. „Fünf neue fixbare HIGH seit dem letzten Build” ist eine Aussage. „474 Vulnerabilities” ist ein Rauschpegel, den niemand abarbeitet.
4. Filtert auf das, was ihr wirklich tun könnt. Von Trivys 474 Findings haben nur 141 überhaupt eine verfügbare korrigierte Version. --ignore-unfixed schneidet zwei Drittel weg, die kein Update der Welt schließt.
5. Erreichbarkeit schlägt Zählung. Der zlib-Fall ist kein Einzelfall. Wer Kapazität hat, prüft, ob der verwundbare Pfad existiert und aufgerufen wird. Genau dafür gibt es VEX-Dokumente, mit denen ein Hersteller festhalten kann, dass ein CVE sein Produkt nicht betrifft. Trivy kann solche Dokumente einlesen.

Der wirksamste Hebel steht in keiner dieser Listen: eine kleinere Angriffsfläche. Ein schlankes Basis-Image hat schlicht weniger Pakete, die ein Scanner überhaupt melden kann. Das senkt die Zahl nicht durch Buchhaltung, sondern durch weniger Software. Wer versteht, was in einem Container eigentlich läuft, trifft diese Entscheidung ohnehin bewusster als jedes Gate im Build.

Und wem gehört die Messung?

Bleibt die Frage, die bei jedem Werkzeug im eigenen Stack dazugehört, und es ist dieselbe wie bei Terraform-Providern oder bei der Wahl der Paketquelle: Was passiert eigentlich, wenn ihr euch darauf verlasst?

Trivy steht unter Apache 2.0, wird von Aqua Security entwickelt, und die Schwachstellen-Datenbank kommt als OCI-Image aus einer Registry. Der Abgleich läuft auf eurer Maschine. Ihr könnt die DB in eure eigene Registry spiegeln und in einer abgeschotteten Umgebung scannen. Kein Konto, kein Login, keine Verbindung nach außen.

Docker Scout ist proprietär. Der Client ist ein Docker-CLI-Plugin, das SBOM entsteht lokal und wird lokal zwischengespeichert, unter ~/.docker/scout/sbom. Der eigentliche Abgleich passiert aber nicht bei euch. Die Data-Handling-Dokumentation formuliert es so:

For images analyzed locally on a developer’s machine, Docker Scout only transmits PURLs and layer digests. This data isn’t persistently stored on the Docker Scout platform; it’s only used to run the analysis.

Das ist deutlich weniger, als der Begriff „SBOM-Upload” befürchten ließe, und es ist fair dokumentiert. Trotzdem verlässt die vollständige Paketliste eures Images als PURLs die Maschine und wird auf Dockers Plattform verarbeitet, laut derselben Doku auf AWS und GCP in US East. Ein Betrieb ohne Netz ist nicht vorgesehen. Für alles über die lokale Analyse hinaus, also fortlaufende Überwachung von Repositories, greifen zudem die Grenzen des Abos: ein Repository bei Docker Personal, zwei bei Pro, unbegrenzt erst bei Team und Business.

Damit ist Scout kein schlechtes Werkzeug, im Gegenteil, die Integration in Docker Desktop und die Basis-Image-Empfehlungen sind erstklassig. Es ist nur eines, dessen Bewertungslogik ihr weder einsehen noch nachbauen könnt. Wenn Scout morgen eine CVE anders einstuft, ändert sich eure Kennzahl, und ihr könnt nicht nachlesen, warum. Wenn Trivy es tut, steht die Änderung in einem Commit.

Für eine Kennzahl, die im Audit landet, ist das der Unterschied zwischen einer Messung, die ihr verantworten könnt, und einer, die ihr nur weiterreicht.

Fazit

1. Dasselbe Image, derselbe Tag, dieselbe Datenquelle: Scout meldet 236 Vulnerabilities, Trivy 474. Bei CRITICAL steht es 1 zu 11.
2. Die Differenz entsteht durch die Zähleinheit (CVE gegen CVE mal Binärpaket), die Paket-Granularität (Quellpaket gegen Binärpaket), das Severity-Mapping (kein Fallback gegen NVD-Fallback) und leicht abweichende Datenbanken.
3. Von 224 gemeinsamen CVEs stufen beide nur 58 Prozent gleich ein. Eine tool-übergreifend vergleichbare CVE-Zahl gibt es nicht.
4. CVE-2023-45853 zeigt, wohin das führt: Trivy meldet CRITICAL mit CVSS 9.8 für Code, den Debian gar nicht mitbaut und der im Image nachweislich fehlt.
5. Eine CVE-Zahl ohne die Frage „sind wir dadurch tatsächlich exponiert” ist ein Compliance-Artefakt. Sie beweist, dass gescannt wurde, nicht dass etwas sicher ist.

Der Scanner ist ein Messgerät, kein Urteil. Wer versteht, wie er zählt, kann seine Ausgabe verantworten und im Ernstfall entscheiden. Wer die Zahl nur weitermeldet, hat einen Prozess eingehalten und trotzdem nichts über sein System gelernt. Und genau darum geht es, bei Scannern wie bei jedem anderen Baustein: die eigene Plattform verstehen, statt ihr zu vertrauen, weil ein grünes Häkchen erschienen ist.

Newsletter

Erhalte praxisnahe Tutorials, Best Practices und echte Lösungen für die häufigsten DevOps-Probleme direkt in Dein Postfach.

Datenschutz: Deine E-Mail-Adresse wird DSGVO-konform in Deutschland gespeichert. Keine Spam, nur relevante Inhalte. Eine E-Mail alle 1 bis 2 Wochen.