Image Scanner wie Trivy oder Grype sind unverzichtbare Werkzeuge zur Erkennung von Schwachstellen in Container-Images. Während 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äzise erkennen. Doch diese Scanner sind dafür anfällig, sowohl False Positives als auch False Negatives zu erzeugen, also Schwachstellen zu melden, die keine sind, oder tatsächliche zu übersehen. Dies führt zu erheblichem Mehraufwand bei der Analyse der Ergebnisse und zu Sicherheitsrisiken.

Dieser Artikel beschreibt, wie die Scanner funktionieren, und liefert eine umfassende Liste möglicher 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ßend werden Lösungsansätze skizziert.

Was macht ein Image sicher (oder angreifbar)

Wirft man bei Docker Hub einen genauen Blick auf beliebte Images (beispielsweise nginx), zeigt das Docker Hub UI selbst bei kürzlich gepushten Tags mehrere Schwachstellen (Vulnerabilities) an. Doch weder Docker Inc. noch die Image-Maintainer würden es dulden, dass selbst die neuesten gepushten Images bekannte Sicherheitslücken aufweisen. Woher kommen also diese vermeintlichen Schwachstellen, und sind sie wirklich ausnutzbar?

Die Images enthalten meistens eine große Anzahl von Softwarekomponenten, etwa Binärdateien und Bibliotheken. Ein PostgreSQL-Image wie postgres:17.1 enthält beispielsweise nicht nur die eine Komponente PostgreSQL, sondern über 200 Komponenten, darunter OpenSSL, die Bash-Shell und verschiedene Systempakete und -bibliotheken. Einige dieser Komponenten können für Exploits anfällig sein. Das ist aber nur dann der Fall, wenn die Komponente während der Container-Laufzeit in den RAM geladen und der angreifbare Codepfad der Komponente tatsächlich ausgeführt wird.

Das Kernproblem ist, dass die Reports von allen Docker-Image-Schwachstellenscannern wie Trivy oder Grype aus verschiedenen technischen Gründen fehleranfällig sind (Details folgen). Konsumenten eines Images würden jedoch Scanner bevorzugen, die nur „True Positives“ und „True Negatives“ erzeugen. In der Realität liefern diese Scanner jedoch auch „False Negatives“ und „False Positives“.

Begriffe wie „False Positive“ stammen aus der Statistik und der Medizin (siehe Wikipedia). „Positive“ bzw. „Negative“ bezieht sich auf die vom Scanner gemeldete Einschätzung, während „True“ bzw. „False“ angibt, ob diese Einschätzung tatsächlich stimmt. Im Kontext des Image-Scanning haben die Begriffe folgende Bedeutung:

• True Positive: Der Scanner meldet eine angreifbare Komponente, und die Einschätzung stimmt, weil diese Komponente während der Container-Ausführung tatsächlich geladen wird und angreifbare Codepfade ausgeführt werden, die ein Angreifer ausnutzen kann. Auf solche Funde muss man reagieren, etwa durch Aktualisieren oder Entfernen der betroffenen Komponente.
• False Positive: Der Scanner meldet eine angreifbare Komponente. Aber sie kann in diesem Image aus verschiedenen Gründen nicht ausgenutzt werden. Der Scanner liegt also falsch. Leider weiß man zu diesem Zeitpunkt noch nicht, ob ein gemeldeter „Positive“-Fund nun ein True Positive oder False Positive ist. Es muss teilweise erheblicher Aufwand investiert werden, um dies (manuell) zu ermitteln. Dies wird auch als Triage bezeichnet.
• True Negative: Der Scanner hat eine Komponente, die Teil des Images ist, zu Recht nicht als angreifbar gemeldet.
• False Negative: Der Scanner hat eine Image-Komponente nicht als angreifbar gemeldet, obwohl er es hätte tun sollen, weil diese Komponente tatsächlich angreifbar ist. Das ist eine gefährliche Situation, da das Image angreifbar ist, ohne dass man es weiß.

Wie Scanner funktionieren

Die folgende Abbildung 1 veranschaulicht den Ablauf, wenn ein Scanner wie Trivy ein Image analysiert:

Schritt 1: Der Scanner analysiert ein Image und erstellt dafür 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:

• Metadaten des Linux-Paketmanagers: Jeder Scanner identifiziert zuerst die Linux-Distribution des Images (z. B. Alpine oder Ubuntu) und analysiert dann die Metadaten des Paketmanagers. Die Metadaten beinhalten, welche Pakete via Paketmanager installiert wurden (z. B. die Datei /var/lib/dpkg/status für apt). Die konkret unterstützten Linux-Distributionen variieren je nach Scanner.
• Metadaten von Programmiersprachen-Paketmanagern: Die meisten Scanner können die Dependency-Manifeste verschiedener Programmiersprachen (z. B. txt für Python oder yarn.lock für Yarn/npm) indizieren, um Dependencies der jeweiligen Sprache/Ökosystem zu erkennen.
• Eingebettete SBOMs: Um es Scannern zu ermöglichen, Komponenten zu erkennen, die nicht via Paketmanager installiert wurden, unterstützen einige Scanner das Auffinden eingebetteter standardisierter SBOMs, die Teil des Dateisystems des Images sind. Dies ist hier für Trivy dokumentiert. Zudem unterstützen sowohl Trivy als auch Grype einige proprietäre eingebettete SBOM-Formate, z. B. für Bitnami-Images.
• Metadaten in Binärdateien: Die Compiler einiger Programmiersprachen (beispielsweise Rust oder Go) können Metadaten in dessen produzierte Binärdateien einbetten. Die Metadaten enthalten Namen und Versionen der Anwendung sowie deren (transitiver) Dependencies. Scanner wie Trivy oder Grype können diese Metadaten aus einer Binärdatei extrahieren und interpretieren.
• Binär-Scanning: Um Komponenten, die beispielsweise mit C/C++ kompiliert wurden (und nicht via Paketmanager installiert wurden), zu identifizieren, besitzt die in Grype integrierte Syft-Library einen Binär-Scanner-Katalogisierer. Dieser verwendet reguläre Ausdrücke auf Dateisystem-Pfade, und kann dadurch ausgewählte Binärdateien identifizieren. Bei Trivy hat lediglich die kommerzielle Aqua Security Edition einen solchen Katalogisierer, bei Trivys Open-Source-Variante fehlt er.

Schritt 2: Das Scanner-CLI lädt eine Schwachstellendatenbank herunter (es sei denn, es liegt bereits eine aktuelle Kopie im lokalen Cache). Die Scanner-Hersteller kompilieren diese Datenbankdatei täglich neu. Ihre Größe beträgt etwa 60 bis 70 MByte bei Trivy und Grype. Die Datei hat ein proprietäres Format und enthält Schwachstellen aus verschiedenen Schwachstellendatenbanken. Die vorkompilierten Datenbanken haben folgende Vorteile:

• Der Scanner kann effizient in ihnen suchen (dank des proprietären Formats).
• Der Scanner muss zur Scan-Zeit nicht jede Schwachstellendatenbank über das Internet abfragen (vielen Datenbanken fehlt ohnehin eine solche Abfrageschnittstelle).
• Der Scanner funktioniert auch in isolierten Offline-Umgebungen.

Schritt 3: Der dritte Schritt ist das Kreuzverweisen (siehe Kasten). Der Scanner gleicht alle Komponenten der intern erstellten SBOM mit den Einträgen seiner Schwachstellendatenbank ab. Er meldet jeden Treffer als positives Ergebnis.

False Negatives

Die folgende Übersicht listet Gründe auf und zeigt anhand von Beispielen, warum Scanner gewisse Schwachstellen nicht melden:

Grund 1: Der Scanner erkennt die Komponente nicht, weil sie nicht via Paketmanager installiert wurde.

Beispiel: Ein Multi-Stage Dockerfile kompiliert ein natives C/C++ Binary in der Build Stage und kopiert es in die Final Stage des Images.

Grund 2: Der Scanner erkennt die Komponente nicht, obwohl sie via Paketmanager installiert wurde, da die zugehörigen Metadaten des Paketmanagers gelöscht wurden.

Beispiel: Tools wie mint löschen solche Metadaten bei der Optimierung des Images, oder die Metadaten wurden absichtlich oder versehentlich von Menschen gelöscht (siehe Vortrag Malicious Compliance auf der KubeCon 2023 sowie diesen Folge-Vortrag auf der KubeCon 2025).

Grund 3: 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.

Beispiel: Das Paket wurde in ein Debian-basiertes Image aus einem Third-Party Debian-Repository oder mithilfe einer .deb-Datei installiert (siehe beispielsweise PostgreSQL).

Grund 4: 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ägt das Kreuzverweisen fehl.

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 – konkrete Beispiele sind Googles Distroless Image SBOMs oder die von Chainguard bereitgestellten SBOMs.

Grund 5: Probleme mit der Schwachstellendatenbank des Scanners.

Beispiele: Der Scanner-Hersteller hat seine eingebettete/proprietäre Datenbank versehentlich nicht korrekt aktualisiert oder erstellt, beispielsweise könnte einer der zugrunde liegenden Datenbankanbieter (z. B. NVD) vollständig fehlen.

Das Scanner-Tool hat die lokal gecachte Datenbank seit Längerem nicht aktualisiert, etwa aufgrund von Verbindungsproblemen.

Die Schwachstelle im Code der Komponente wurde bisher nicht gemeldet, oder sie hat noch kein CVSS-Rating erhalten (siehe Bericht über den wachsenden Rückstand der NVD).

Gründe für False Positives

Die Ursachen, warum False Positives auftreten, also gemeldete Schwachstellen, die in Wahrheit nicht angreifbar sind, lassen sich in vier Gruppen zusammenfassen.

Grund 1 ist, der Scanner findet eine Komponente im Image, die (prinzipiell) Schwachstellen hat. Diese Komponente wird aber entweder während der gesamten Container-Laufzeit nicht geladen oder es werden nur diejenigen Teile verwendet, die nicht angreifbar sind. Zum Beispiel könnte ein Datenbankserver-Image ausgeführt werden, das auch einen angreifbaren Perl-Interpreter enthält, Perl wird aber nie verwendet.

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öscht, ohne die zugehörigen Metadaten korrekt zu aktualisieren. So könnten im Dockerfile Zeilen stehen wie RUN rm anstelle von RUN apt-get -y remove .

Der dritte mögliche Grund können 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ünden nicht vor, diese in nächster Zeit zu beheben. So wird zum Beispiel CVE-2005-2541 von Security-Forschern als High-Severity-Schwachstelle angesehen, aber Debian 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ät zugewiesen. Sie wird möglicherweise erst in einigen Monaten oder Jahren behoben.

Viertens schließlich könnte der Scanner die Security-Backports nicht richtig erkennen, die von einigen Linux-Distributionen für bestimmte Komponenten implementiert wurden. CVE-2020-8169 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 und DSA-4881-1), die der Scanner nicht erkennt (der Scanner erkennt Version 7.64.0 und meldet sie als angreifbar).

Erst die Software entwickeln und das Ergebnis testen – das funktioniert nicht mehr. Die Qualitätssicherung beginnt heute frühzeitig im Entwicklungsprozess und benötigt gute Testmanagement-Tools. Aber wo trennt sich die Spreu vom Weizen? Wie findet man die Tools, die nicht bremsen, sondern unterstützen? Unser Titelautor Waldemar Klassen erklärt, wie sich der Markt entwickelt hat und worauf es ankommt.

Was sollte ein zeitgemäßes Testmanagement-Tool mitbringen?

Die Grundanforderungen haben sich nicht stark verändert. Testfälle verwalten, Ergebnisse dokumentieren, Anforderungsbezug sicherstellen. Was sich aber verändert hat, ist das Umfeld. Teams arbeiten heute iterativ, oft verteilt und mit vielen Tools parallel. Ein Testmanagement-Tool muss deshalb anschlussfähig sein, quasi ein Integrationshub. Das heißt einerseits technisch über Schnittstellen und andererseits organisatorisch den Prozess abdecken. Denn was ich beobachte, ist, dass die Tool-Landschaft fragmentierter wird. An sich kein Problem, wenn die Testprozesse ebenfalls hybrid werden und das Testmanagement-Tool andockfähig ist.

Wenn ich es jetzt in einem Satz beantworten soll: In DevOps-Umgebungen kommt es auf Echtzeit-Transparenz, offene Schnittstellen und eine stabile API an. Und gute Tools denken den gesamten Dev-Prozess mit, nicht nur das Testen.

Wie haben sich DevSecOps-Ansätze, die Security im Entwicklungsprozess von Anfang an mitdenken, auf Testabläufe und die Tools dafür ausgewirkt?

Security ist vom Rand in den Kern gerückt. Tests für Sicherheitsanforderungen, Compliance-Vorgaben oder Audits sind keine nachgelagerten Aktivitäten mehr, sondern integraler Bestandteil von Release-Zyklen. Testmanagement-Tools müssen also in der Lage sein, auch Security-Scans, statische Codeanalysen oder Schwachstellenprüfungen zu erfassen und nachvollziehbar zu dokumentieren. Wer heute DevSecOps ernst meint, braucht auch ein Testmanagement, das klassische Funktionstests mit Security-Anforderungen zusammenbringt. Einige Anbieter gehen inzwischen weiter und verknüpfen Findings aus SAST- oder DAST-Tools direkt mit dem Teststatus. Das funktioniert technisch aber nur wenn der Integrationsgedanke gelebt wird und kein Reibungskampf zwischen den Security- und Dev-Tools vorherrscht.

Gefühlt wird künstliche Intelligenz derzeit in so ziemlich jede Software integriert – welche Rolle spielt sie in diesem Bereich?

Noch eine zu starke Nebenrolle, wie ich finde, aber mit viel Potenzial. Testfälle automatisch vorzuschlagen, Logs zu analysieren oder Priorisierungen vorzunehmen – das erleichtert die Arbeit und steigert die Effizienz. Das funktioniert auch in vielen Pilotprojekten bereits, skaliert aber noch nicht flächendeckend. Die Anbieter sind da unterschiedlich weit. Viele arbeiten an KI-Funktionen, aber eher im Hintergrund. Die Dev-Teams sind zwar offen dafür, haben jedoch auch immer Sorgen, dass sie nicht mehr benötigt werden.

Ich finde, KI ohne Mensch dahinter funktioniert nicht und ist ein Werkzeug zur Unterstützung. „Nicht ersetzen, sondern entlasten“, ist meine Einstellung dazu, wie in der Marktübersicht auch gezeigt. Dazu zählt etwa das Auffinden redundanter Tests oder die Auswertung von Ergebnissen. Die Umsetzung und das Qualitätsmanagement bleiben beim Entwickler.

Herr Klassen, vielen Dank für die Antworten! Interessierte Leser finden im Titel der neuen iX alles zum Testmanagement: Wir beleuchten, was gutes Testmanagement ausmacht, zeigen in einer umfangreichen Marktübersicht, welche Software fürs Testmanagement es gibt, und erklären anhand des Open-Source-Tools TestLink, wie modernes Testmanagement funktioniert. Das August-Heft ist ab sofort im heise shop und am Kiosk erhältlich.

In der Serie „Drei Fragen und Antworten“ will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.

(fo)

Wer den Sourcecode-Editor Zed verwendet, kann künftig mit einer Einstellung alle KI-Funktionen ausschalten. Damit reagieren die Projektverantwortlichen auf Wünsche aus der Community.

Das Team hinter dem Open-Source-Editor hatte im Mai 2025 in einem Blogbeitrag Zed zum schnellsten KI-Code-Editor erklärt. Zed ist von Grund auf in Rust geschrieben und seit Januar 2024 als Open-Source-Projekt unter GPL-Lizenz verfügbar. Seine Anfänge lagen auf macOS, im Juli 2024 folgte Linux und eine offizielle Windows-Version ist ebenfalls in Planung.

KI-Editor ohne KI

Auch wenn die oft nützlichen KI-Hilfen inzwischen für viele zum Alltag der Softwareentwicklung gehören, gibt es berechtigte Bedenken bezüglich der Codequalität und potenziell generierter Schwachstellen oder wegen der Daten und des Sourcecodes, die beim Einsatz der KI-Tools das Unternehmen verlassen.

Im GitHub-Repository des Editors finden sich bereits seit 2024 Diskussionen und Issues, die einen Ausschalter für KI-Funktionen wünschen.

Nun haben die Projektverantwortlichen reagiert und in der aktuellen Preview eine Einstellung in der settings.json-Datei eingeführt, die sämtliche KI-Funktionen deaktiviert:

{
  "disable_ai": true
}

In Kürze ist zusätzlich ein Switch in den KI-Einstellungen innerhalb der UI des Editors geplant, der ebenfalls alle KI-Funktionen abschaltet.

Datenschutz trotz KI

Der Blogbeitrag zum Deaktivieren der KI-Funktionen betont, dass diejenigen, die vor allem Bedenken bezüglich des Datenschutzes haben, die KI-Funktionen nicht unbedingt deaktivieren müssen.

Zed lässt bei der Auswahl des KI-Anbieters freie Wahl und ermöglicht auch den Einsatz lokaler KI-Modelle mittels Ollama, damit der Code und die Daten den Rechner nicht verlassen.

Weitere Details zu den Hintergründen lassen sich dem Zed-Blog entnehmen.

(rme)