Image Scanner wie Trivy oder Grype sind unverzichtbare Werkzeuge zur Erkennung von Schwachstellen in Container-Images. W\u00e4hrend eines Scans erstellen sie eine Software Bill of Materials (SBOM) und gleichen sie mit verschiedenen Schwachstellendatenbanken ab, um potenziell angreifbare Komponenten zu identifizieren. Viele IT-Teams nutzen diese Scanner unter der Annahme, dass sie alle Schwachstellen pr\u00e4zise erkennen. Doch diese Scanner sind daf\u00fcr anf\u00e4llig, sowohl False Positives als auch False Negatives zu erzeugen, also Schwachstellen zu melden, die keine sind, oder tats\u00e4chliche zu \u00fcbersehen. Dies f\u00fchrt zu erheblichem Mehraufwand bei der Analyse der Ergebnisse und zu Sicherheitsrisiken.<\/p>\n
<\/p>\n
\n Dr. Marius Shekow war \u00fcber 10 Jahre als Forscher und Softwareentwickler bei Fraunhofer t\u00e4tig. Seit 2022 ist er Lead DevOps- & Cloud-Engineer bei SprintEins in Bonn. Dort baut er f\u00fcr Konzerne und KMUs individuelle Cloud-Umgebungen, inkl. CI\/CD-Automatisierung, Observability und Security-Absicherung.\n <\/p>\n
Dieser Artikel beschreibt, wie die Scanner funktionieren, und liefert eine umfassende Liste m\u00f6glicher False Positives und Negatives, mit konkreten Beispielen. Eine Analyse von acht der beliebtesten Docker Hub Images mit Trivy und Grype zeigt offensichtliche False Negatives bei fast allen Images, wodurch IT-Systeme angreifbar werden. Abschlie\u00dfend werden L\u00f6sungsans\u00e4tze skizziert.<\/p>\n
Was macht ein Image sicher (oder angreifbar)<\/p>\n
Wirft man bei Docker Hub einen genauen Blick auf beliebte Images (beispielsweise nginx), zeigt das Docker Hub UI selbst bei k\u00fcrzlich gepushten Tags mehrere Schwachstellen (Vulnerabilities) an. Doch weder Docker Inc. noch die Image-Maintainer w\u00fcrden es dulden, dass selbst die neuesten gepushten Images bekannte Sicherheitsl\u00fccken aufweisen. Woher kommen also diese vermeintlichen Schwachstellen, und sind sie wirklich ausnutzbar?<\/p>\n
Die Images enthalten meistens eine gro\u00dfe Anzahl von Softwarekomponenten, etwa Bin\u00e4rdateien und Bibliotheken. Ein PostgreSQL-Image wie postgres:17.1<\/a> enth\u00e4lt beispielsweise nicht nur die eine Komponente PostgreSQL, sondern \u00fcber 200 Komponenten, darunter OpenSSL, die Bash-Shell und verschiedene Systempakete und -bibliotheken. Einige dieser Komponenten k\u00f6nnen f\u00fcr Exploits anf\u00e4llig sein. Das ist aber nur dann der Fall, wenn die Komponente w\u00e4hrend der Container-Laufzeit in den RAM geladen und der angreifbare Codepfad der Komponente tats\u00e4chlich ausgef\u00fchrt wird.<\/p>\n Das Kernproblem ist, dass die Reports von allen Docker-Image-Schwachstellenscannern wie Trivy oder Grype aus verschiedenen technischen Gr\u00fcnden fehleranf\u00e4llig sind (Details folgen). Konsumenten eines Images w\u00fcrden jedoch Scanner bevorzugen, die nur „True Positives“ und „True Negatives“ erzeugen. In der Realit\u00e4t liefern diese Scanner jedoch auch „False Negatives“ und „False Positives“.<\/p>\n Begriffe wie „False Positive“ stammen aus der Statistik und der Medizin (siehe Wikipedia<\/a>). „Positive“ bzw. „Negative“ bezieht sich auf die vom Scanner gemeldete Einsch\u00e4tzung, w\u00e4hrend „True“ bzw. „False“ angibt, ob diese Einsch\u00e4tzung tats\u00e4chlich stimmt. Im Kontext des Image-Scanning haben die Begriffe folgende Bedeutung:<\/p>\n Wie Scanner funktionieren<\/p>\n Die folgende Abbildung 1 veranschaulicht den Ablauf, wenn ein Scanner wie Trivy ein Image analysiert:<\/p>\n <\/p>\n <\/a><\/p>\n Image-Scan-Ablauf (Abb. 1)<\/p>\n Schritt 1<\/strong>: Der Scanner analysiert ein Image und erstellt daf\u00fcr eine (interne) SBOM, also eine Liste aller Softwarekomponenten des Images. Die Implementierungen der Scanner unterscheiden sich, aber prinzipiell hat jeder Scanner mehrere Katalogisierer, die Softwarepakete identifizieren. Wichtige Katalogisierer sind:<\/p>\n Schritt 2<\/strong>: Das Scanner-CLI l\u00e4dt eine Schwachstellendatenbank herunter (es sei denn, es liegt bereits eine aktuelle Kopie im lokalen Cache). Die Scanner-Hersteller kompilieren diese Datenbankdatei t\u00e4glich neu. Ihre Gr\u00f6\u00dfe betr\u00e4gt etwa 60 bis 70 MByte bei Trivy und Grype. Die Datei hat ein propriet\u00e4res Format und enth\u00e4lt Schwachstellen aus verschiedenen Schwachstellendatenbanken. Die vorkompilierten Datenbanken haben folgende Vorteile:<\/p>\n Schritt 3<\/strong>: Der dritte Schritt ist das Kreuzverweisen (siehe Kasten). Der Scanner gleicht alle Komponenten der intern erstellten SBOM mit den Eintr\u00e4gen seiner Schwachstellendatenbank ab. Er meldet jeden Treffer als positives Ergebnis.<\/p>\n Der Schritt „Kreuzverweisen“ ist f\u00fcr die Scanner technisch anspruchsvoll, weil eine Softwarekomponente in vielen verschiedenen Repositorys unter unterschiedlichen Bezeichnern und Versionen existiert, die jeweils von unterschiedlichen Schwachstellen betroffen sind.<\/p>\n Ein Beispiel: Angenommen, ein Image enth\u00e4lt einen Python-Interpreter. Python wird auf zahlreichen Wegen verteilt. Zum einen durch Download von der python.org-Homepage, deren Bin\u00e4r-Builds direkt aus dem Upstream-Quellcode erstellt werden. Daneben paketieren die meisten Linux-Distributionen \u2013 darunter Red Hat Enterprise Linux, SUSE Linux, Alpine, Debian oder Ubuntu \u2013 Python, indem sie die Bin\u00e4rpakete selbst kompilieren und in den offiziellen Distribution-Repositorys speichern.<\/p>\n Welche Pakete in welcher Version aufgenommen werden, entscheidet sich jeweils beim Zusammenstellen einer neuen Linux-Distribution. Im Fall von Python ist dies beispielsweise Python 3.12.3 f\u00fcr Ubuntu 24.04 („Noble Numbat“)<\/a>. Aus Stabilit\u00e4tsgr\u00fcnden bleibt diese Python-Version f\u00fcr die gesamte Lebensdauer dieser Ubuntu-Version fixiert. Da eine so alte Python-Version schnell angreifbar wird, erstellen die Linux-Distro-Maintainer jeweils Backports von Sicherheitspatches, die distributionsspezifische Suffixe wie 3.12.3-1ubuntu0.5 erhalten. Anhand eines eigenen Security-Trackers halten die Maintainer fest, welche ihrer Builds von welchen Schwachstellen\/CVEs betroffen sind (siehe die \u00dcbersicht in der Trivy-Dokumentation<\/a>).<\/p>\n Ermittelt ein Scanner wie Trivy f\u00fcr ein via Paketmanager installiertes Paket (wie Python) die Kreuzverweise zu den CVEs, beschr\u00e4nkt sich der Kreuzverweis-Algorithmus allein auf die distributionsspezifische Schwachstellendatenbank. Daher erkennt er nur Schwachstellen f\u00fcr Pakete, die aus den offiziellen Repositorys installiert wurden. Die Scanner-Hersteller k\u00f6nnten alternativ auf generische (Distro-unabh\u00e4ngige) Schwachstellendatenbanken wie NVD zur\u00fcckgreifen, die alle (Python-)Schwachstellen enthalten \u2013 etwa \u00fcber CPE-Bezeichner wie „cpe:2.3:a:python:python:3.12.3:::::::*“<\/a>. Nach eigener Aussage verzichten sie jedoch darauf, weil sonst zu viele False Positives gemeldet w\u00fcrden.<\/p>\n Hinweis: Das Kreuzverweisen von Paketen, die in einer einzigen „autoritativen“ Registry gespeichert sind (z. B. Node.js-Pakete, die in npmjs.org gespeichert sind), funktioniert einwandfrei, ist also von dieser Einschr\u00e4nkung nicht betroffen.<\/p>\n False Negatives<\/p>\n Die folgende \u00dcbersicht listet Gr\u00fcnde auf und zeigt anhand von Beispielen, warum Scanner gewisse Schwachstellen nicht melden:<\/p>\n Grund 1<\/strong>: Der Scanner erkennt die Komponente nicht, weil sie nicht via Paketmanager installiert wurde.<\/p>\n Beispiel: Ein Multi-Stage Dockerfile kompiliert ein natives C\/C++ Binary in der Build Stage und kopiert es in die Final Stage des Images.<\/p>\n Grund 2<\/strong>: Der Scanner erkennt die Komponente nicht, obwohl sie via Paketmanager installiert wurde, da die zugeh\u00f6rigen Metadaten des Paketmanagers gel\u00f6scht wurden.<\/p>\n Beispiel: Tools wie mint<\/a> l\u00f6schen solche Metadaten bei der Optimierung des Images, oder die Metadaten wurden absichtlich oder versehentlich von Menschen gel\u00f6scht (siehe Vortrag Malicious Compliance<\/a> auf der KubeCon 2023 sowie diesen Folge-Vortrag<\/a> auf der KubeCon 2025).<\/p>\n Grund 3<\/strong>: Der Scanner erkennt die Komponente zwar, sie ist jedoch nicht in der Schwachstellendatenbank des Scanner-Tools bekannt, die nur Pakete aus dem offiziellen Repository der Linux-Distribution abdeckt.<\/p>\n Beispiel: Das Paket wurde in ein Debian-basiertes Image aus einem Third-Party Debian-Repository oder mithilfe einer .deb-Datei installiert (siehe beispielsweise PostgreSQL<\/a>).<\/p>\n Grund 4<\/strong>: Der Scanner erkennt die Komponente, und (prinzipiell) ist diese Komponente in der Schwachstellendatenbank des Scanners als angreifbar bekannt. Allerdings hat das Scan-Tool die Komponente mit einem anderen Identifier erkannt als dem, der in der Datenbank verwendet wird. Daher schl\u00e4gt das Kreuzverweisen fehl.<\/p>\n Beispiel: Versucht man mit Trivy oder Grype eine SBOM zu scannen, die von einem anderen Tool (wie Bazel oder apko) erstellt wurde, werden keine Schwachstellen gefunden \u2013 konkrete Beispiele sind Googles Distroless Image SBOMs oder die von Chainguard bereitgestellten SBOMs.<\/p>\n Grund 5<\/strong>: Probleme mit der Schwachstellendatenbank des Scanners.<\/p>\n Beispiele: Der Scanner-Hersteller hat seine eingebettete\/propriet\u00e4re Datenbank versehentlich nicht korrekt aktualisiert oder erstellt, beispielsweise k\u00f6nnte einer der zugrunde liegenden Datenbankanbieter (z. B. NVD) vollst\u00e4ndig fehlen.<\/p>\n Das Scanner-Tool hat die lokal gecachte Datenbank seit L\u00e4ngerem nicht aktualisiert, etwa aufgrund von Verbindungsproblemen.<\/p>\n Die Schwachstelle im Code der Komponente wurde bisher nicht gemeldet, oder sie hat noch kein CVSS-Rating erhalten (siehe Bericht \u00fcber den wachsenden R\u00fcckstand der NVD<\/a>).<\/p>\n Gr\u00fcnde f\u00fcr False Positives<\/p>\n Die Ursachen, warum False Positives auftreten, also gemeldete Schwachstellen, die in Wahrheit nicht angreifbar sind, lassen sich in vier Gruppen zusammenfassen.<\/p>\n Grund 1 ist, der Scanner findet eine Komponente im Image, die (prinzipiell) Schwachstellen hat. Diese Komponente wird aber entweder w\u00e4hrend der gesamten Container-Laufzeit nicht geladen oder es werden nur diejenigen Teile verwendet, die nicht angreifbar sind. Zum Beispiel k\u00f6nnte ein Datenbankserver-Image ausgef\u00fchrt werden, das auch einen angreifbaren Perl-Interpreter enth\u00e4lt, Perl wird aber nie verwendet.<\/p>\n Zweitens kann der Scanner glauben, eine Komponente gefunden zu haben, weil sie in den Metadaten des Paketmanagers aufgelistet ist. Die Dateien\/Binaries dieser Komponente wurden jedoch (manuell) gel\u00f6scht, ohne die zugeh\u00f6rigen Metadaten korrekt zu aktualisieren. So k\u00f6nnten im Dockerfile Zeilen stehen wie RUN rm anstelle von RUN apt-get -y remove .<\/p>\n Der dritte m\u00f6gliche Grund k\u00f6nnen Meinungsverschiedenheiten zwischen den Maintainern der Schwachstellendatenbank und den Maintainern der Komponente sein, ob die Komponente wirklich angreifbar ist. Die Software-Maintainer wissen prinzipiell von der Schwachstelle, haben aber aus verschiedenen Gr\u00fcnden nicht vor, diese in n\u00e4chster Zeit zu beheben. So wird zum Beispiel CVE-2005-2541<\/a> von Security-Forschern als High-Severity-Schwachstelle angesehen, aber Debian<\/a> interpretiert sie als „beabsichtigtes Verhalten“, also wie ein Feature. Oder die Software-Maintainer sehen die Schwachstelle als kleines Problem und haben ihr daher eine niedrige Priorit\u00e4t zugewiesen. Sie wird m\u00f6glicherweise erst in einigen Monaten oder Jahren behoben.<\/p>\n Viertens schlie\u00dflich k\u00f6nnte der Scanner die Security-Backports nicht richtig erkennen, die von einigen Linux-Distributionen f\u00fcr bestimmte Komponenten implementiert wurden. CVE-2020-8169<\/a> etwa gibt beispielsweise an, dass die curl-Versionen 7.62.0 bis 7.70.0 eine Schwachstelle aufweisen, die in Version 7.71.0 behoben ist. Das curl-Paket in Debian Buster hat allerdings einen Backport des Security-Fixes in Version 7.64.0-4+deb10u2 (siehe Debian Security-Tracker<\/a> und DSA-4881-1<\/a>), die der Scanner nicht erkennt (der Scanner erkennt Version 7.64.0 und meldet sie als angreifbar).<\/p>\n \n Dieser Link ist leider nicht mehr g\u00fcltig.\n <\/p>\n Links zu verschenkten Artikeln werden ung\u00fcltig, Sie ben\u00f6tigen ein heise+ Paket, um diesen Artikel zu lesen. Jetzt eine Woche unverbindlich testen \u2013 ohne Verpflichtung!<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"Image Scanner wie Trivy oder Grype sind unverzichtbare Werkzeuge zur Erkennung von Schwachstellen in Container-Images. W\u00e4hrend eines Scans…\n","protected":false},"author":2,"featured_media":294874,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[135],"tags":[86334,86335,29,47841,86336,30,86337,196,190,189,1687,194,191,193,192],"class_list":{"0":"post-294873","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-wissenschaft-technik","8":"tag-container-images","9":"tag-containerisierung","10":"tag-deutschland","11":"tag-developer","12":"tag-docker","13":"tag-germany","14":"tag-image-scanner","15":"tag-it","16":"tag-science","17":"tag-science-technology","18":"tag-security","19":"tag-technik","20":"tag-technology","21":"tag-wissenschaft","22":"tag-wissenschaft-technik"},"share_on_mastodon":{"url":"https:\/\/pubeurope.com\/@de\/114918308126115159","error":""},"_links":{"self":[{"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/posts\/294873","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/comments?post=294873"}],"version-history":[{"count":0,"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/posts\/294873\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/media\/294874"}],"wp:attachment":[{"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/media?parent=294873"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/categories?post=294873"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/tags?post=294873"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
<\/p>\n
\n
\n
\n wenn diese \u00e4lter als 7\u00a0Tage sind oder zu oft aufgerufen wurden.\n <\/p>\n