False Positives vs. echte Risiken: Wie du KI-Security-Scanner sinnvoll einsetzt

90 Prozent der Findings sind Rauschen. Die restlichen 10 Prozent können das Unternehmen kosten. Die Kunst liegt im Unterscheiden – und das ist schwieriger, als es klingt.

In Teil 5 dieser Serie ging es um die strategische Frage: Wie organisieren sich Teams, wenn KI-Scanner täglich hunderte Findings liefern? Dieser Artikel geht eine Ebene tiefer: Wie sehen False Positives konkret aus, warum erzeugen Scanner so viel Rauschen, und was kann man dagegen tun – als Entwickler, nicht als Security-Architekt.

Warum Scanner so viel Rauschen erzeugen

Ein Security-Scanner arbeitet mit Regeln und Mustern. Er versteht Code syntaktisch, aber nicht semantisch. Er sieht, dass eine Funktion Benutzereingaben verarbeitet, aber nicht, dass drei Zeilen vorher eine Validierung stattfindet. Er findet eine veraltete Dependency, aber nicht, ob der betroffene Code-Pfad in der eigenen Anwendung überhaupt erreichbar ist.

Das führt zu einer systematischen Überempfindlichkeit. Scanner sind darauf optimiert, nichts zu übersehen – auf Kosten der Präzision. Lieber hundert falsche Alarme als ein echter Treffer, der durchrutscht. Das ist nachvollziehbar. Aber es erzeugt ein Problem, das mindestens so gefährlich ist wie die Schwachstellen selbst: Alarmmüdigkeit.

Alert Fatigue ist ein Sicherheitsrisiko

Wenn ein Entwickler morgens die Pipeline öffnet und 47 Findings sieht, passiert etwas Vorhersehbares: Er scannt die Liste, sieht bekannte Muster, die er schon dreimal als irrelevant eingestuft hat, und schließt den Tab. Irgendwo in der Liste steckt vielleicht ein echtes Problem – aber die Motivation, es zu finden, sinkt mit jeder falschen Warnung.

Studien zeigen, dass die Reaktionszeit auf echte Findings signifikant steigt, wenn die False-Positive-Rate über 30 Prozent liegt. Bei über 60 Prozent – was bei unkonfigurierten Scannern üblich ist – werden Findings routinemäßig ignoriert. Das ist kein Entwicklerproblem. Das ist ein Tooling-Problem.

Typische False Positives – und wie man sie erkennt

SAST: Statische Analyse und ihre Grenzen

Statische Scanner analysieren Quellcode, ohne ihn auszuführen. Sie finden Muster, die auf Schwachstellen hindeuten könnten. Das Problem: Ohne Laufzeitkontext fehlt ihnen die Hälfte der Information.

Beispiel: SQL-Injection-Warnung bei einem ORM

Der Scanner sieht eine Datenbankabfrage mit einer Variablen und meldet SQL-Injection. In der Praxis nutzt die Anwendung ein ORM mit parametrisierten Queries – die Variable wird nie direkt in SQL eingebettet. Der Scanner kann das nicht erkennen, weil er die ORM-Abstraktion nicht versteht.

Beispiel: XSS-Warnung bei serverseitigem Rendering

Der Scanner findet eine Template-Variable, die Benutzereingaben enthält, und meldet Cross-Site Scripting. Aber das Template-System escaped alle Ausgaben standardmäßig – Astro, React, Svelte machen das automatisch. Die Warnung wäre nur relevant, wenn explizit unescaped gerendert wird (dangerouslySetInnerHTML, {@html}).

Erkennungsmuster: Wenn ein Finding ein Problem meldet, das vom verwendeten Framework oder der Bibliothek bereits abgefangen wird, ist es fast immer ein False Positive. Voraussetzung: Man muss wissen, welche Sicherheitsgarantien das eigene Tooling bietet.

SCA: Dependency-Scanner und das CVE-Problem

Software Composition Analysis prüft Dependencies gegen bekannte Schwachstellen – sogenannte CVEs (Common Vulnerabilities and Exposures), öffentlich dokumentierte Sicherheitslücken mit eindeutiger Kennung. Das klingt einfach, erzeugt aber die meisten False Positives – aus mehreren Gründen.

Beispiel: Kritische CVE in einer unbenutzten Funktion

Eine Bild-Bibliothek hat eine CVE mit CVSS 9.8 – Remote Code Execution im CLI-Tool. Die eigene Anwendung nutzt ausschließlich die Resize-API. Der betroffene Code-Pfad wird nie aufgerufen. Trotzdem meldet der Scanner: kritisch, sofort patchen.

Beispiel: Transitive Dependency mit bekannter CVE

Das eigene Projekt nutzt Library A, die Library B als Dependency hat, die Library C einbindet. Library C hat eine CVE. Aber Library B nutzt nur zwei Funktionen von Library C, und keine davon ist betroffen. Drei Ebenen tief, kein reales Risiko – aber der Scanner kennt den Kontext nicht.

Beispiel: CVE ist gepatcht, aber der Scanner hinkt hinterher

Die Dependency wurde auf eine Version aktualisiert, die den Fix enthält, aber die CVE-Datenbank ist noch nicht aktualisiert. Der Scanner meldet weiterhin die alte CVE. Das passiert häufiger, als man denkt – CVE-Datenbanken haben Verzögerungen von Tagen bis Wochen.

Verschärft wird das Problem durch das schiere Volumen: KI-gestützte Scanner finden Schwachstellen schneller, als Open-Source-Maintainer sie beheben können. Viele Projekte werden ehrenamtlich gepflegt – die Patches kommen oft Wochen oder Monate nach der CVE-Veröffentlichung. Wer verstehen will, warum das so ist und welche strukturellen Probleme dahinterstecken, findet in CVE-Flut: Warum Open-Source-Maintainer überrannt werden eine ausführliche Analyse.

Erkennungsmuster: Bei SCA-Findings immer prüfen: Ist der betroffene Code-Pfad erreichbar? Nutzt die eigene Anwendung die betroffene Funktion? Reachability-Analyse-Tools wie Snyk, Endor Labs oder Socket können das automatisieren.

Container-Scanning: Das OS-Layer-Problem

Container-Scanner prüfen jede Schicht eines Images. Das Basis-Image (Alpine, Debian, Ubuntu) enthält hunderte Pakete – und viele davon haben bekannte CVEs, die im Kontext eines Containers irrelevant sind.

Beispiel: OpenSSH-CVE in einem Container ohne SSH

Der Scanner meldet eine kritische Schwachstelle in OpenSSH. Der Container hat keinen SSH-Daemon, kein exponiertes SSH-Port, SSH wird ausschließlich als Build-Dependency für Git-Operationen genutzt. Kein Angriffsvektor – aber ein kritisches Finding.

Erkennungsmuster: Bei Container-Findings prüfen: Welche Pakete sind zur Laufzeit relevant? Minimal-Images (distroless, scratch-basiert) reduzieren die Angriffsfläche und die Anzahl der Findings drastisch.

Scanner konfigurieren statt ignorieren

Die Antwort auf zu viel Rauschen ist nicht, Findings zu ignorieren. Es ist, den Scanner so zu konfigurieren, dass er weniger Rauschen erzeugt.

Suppressions und Ausnahmen richtig einsetzen

Jeder Scanner bietet die Möglichkeit, Findings zu unterdrücken. Das ist kein Sicherheitsrisiko – solange es dokumentiert und nachvollziehbar passiert.

Gute Praxis:

Suppression direkt im Code mit Begründung: // nosec: ORM handles parameterization
Zentrale Suppression-Datei im Repository, versioniert und reviewbar
Regelmäßige Überprüfung: Sind die Gründe für die Unterdrückung noch gültig?

Schlechte Praxis:

Globale Regeldeaktivierung ohne Dokumentation
--ignore-all-warnings als Standard in der CI
Suppressions, die nie überprüft werden

Regelsets an das eigene Stack anpassen

Die meisten Scanner kommen mit generischen Regelsets, die alles abdecken sollen – PHP, Java, Python, JavaScript, Go. Wer nur TypeScript und Astro nutzt, braucht keine PHP-Regeln. Die Reduktion auf das eigene Stack eliminiert sofort einen relevanten Anteil irrelevanter Findings.

Semgrep erlaubt eigene Regeln und das gezielte Aktivieren von Regelsets pro Sprache und Framework. ESLint Security Plugin ist spezifisch für JavaScript/TypeScript. Trivy lässt sich auf bestimmte Schweregrade und Pakettypen einschränken.

Schwellenwerte definieren

Nicht jedes Finding muss den Build brechen. Eine sinnvolle Abstufung:

Build bricht: Kritische und hohe Findings mit bekanntem Exploit
Warning in der Pipeline: Mittlere Findings, die im nächsten Sprint bearbeitet werden
Report-only: Niedrige Findings und informationelle Hinweise, die gesammelt und periodisch geprüft werden

Wer alles gleichbehandelt, wird entweder nie deployen oder alles ignorieren. Beides ist schlecht.

CI/CD-Integration: Scanner als Qualitätsgate

Wo im Pipeline-Flow

Scanner gehören an verschiedene Stellen der Pipeline – nicht nur an eine:

Pre-Commit (lokal):

Secret-Scanner wie nosecrets verhindern, dass Credentials ins Repository gelangen
Schnelle Linting-Checks, die in Sekunden laufen

Pull Request (CI):

SAST-Scan auf geänderte Dateien (nicht das gesamte Repository – das spart Zeit und reduziert Noise)
SCA-Check auf neue oder geänderte Dependencies
Delta-Reporting: Nur neue Findings anzeigen, nicht den gesamten Bestand

Scheduled (nightly/weekly):

Vollständiger Scan des gesamten Codebase
Container-Image-Scan aller produktiven Images
SBOM-Generierung und Abgleich mit aktuellen CVE-Datenbanken

Delta-Reporting statt Vollreport

Der wichtigste Trick für weniger Noise in der täglichen Arbeit: Nur neue Findings anzeigen. Wenn der Codebase 200 bekannte Low-Priority-Findings hat, will kein Entwickler die bei jedem PR sehen. Delta-Reporting zeigt nur, was sich seit dem letzten Scan geändert hat.

Die meisten Tools unterstützen das: Snyk mit --new-only, Semgrep mit Baseline-Scans, Trivy mit --ignore-unfixed. Wer das nicht konfiguriert, ertrinkt in historischen Findings.

KI-gestützte Scanner: Was sie besser machen

Klassische Scanner arbeiten regelbasiert. KI-gestützte Scanner versuchen, den Kontext zu verstehen – mit unterschiedlichem Erfolg.

Wo KI hilft

Reachability-Analyse: KI kann Code-Pfade verfolgen und einschätzen, ob eine verwundbare Funktion tatsächlich aufgerufen wird. Das reduziert SCA-False-Positives um 40 bis 60 Prozent.
Clustering: 50 Findings, die denselben Root Cause haben, werden zu einem gruppiert. Das reduziert die Arbeitslast, ohne Information zu verlieren.
Kontextuelle Bewertung: Eine XSS-Warnung in einem öffentlichen Webshop wird höher priorisiert als dieselbe Warnung in einem internen Admin-Tool.
Zusammenfassungen: Statt roher CVE-Daten bekommt der Entwickler eine lesbare Zusammenfassung: Was ist betroffen, warum ist es relevant, was ist die empfohlene Maßnahme.

Wo KI neue Probleme schafft

Halluzinierte Bewertungen: Ein LLM, das ein Finding als „nicht relevant” einstuft, weil es den Kontext falsch interpretiert, erzeugt ein falsches Sicherheitsgefühl – schlimmer als ein False Positive.
Intransparenz: Wenn der Scanner sagt „dieses Finding wurde von der KI als Low eingestuft”, aber nicht erklärt warum, fehlt die Grundlage für eine menschliche Überprüfung.
Overfitting auf bekannte Muster: KI-Modelle sind gut darin, bekannte Schwachstellenmuster zu erkennen. Neuartige Angriffsvektoren fallen durch das Raster – genau die, die am gefährlichsten sind.

Die Regel bleibt: KI kann die Triage beschleunigen, aber nicht ersetzen. Kritische Findings brauchen menschliche Bewertung.

Tooling-Vergleich: Was aktuell funktioniert

Tool	Typ	Stärke	Schwäche
Semgrep	SAST	Eigene Regeln, schnell, gutes Delta-Reporting	Kein Deep-Data-Flow
Snyk	SCA + SAST	Gute Reachability-Analyse, Developer-UX	Kosten bei größeren Teams
Trivy	SCA + Container	Open Source, schnell, breite Abdeckung	Wenig kontextuelle Bewertung
CodeQL	SAST	Tiefe Analyse, GitHub-integriert	Langsam, steile Lernkurve
Socket	SCA	Supply-Chain-Fokus, Verhaltensanalyse	Noch junges Ökosystem
ESLint Security	SAST (JS/TS)	Schnell, niedrige Einstiegshürde	Nur JavaScript/TypeScript

Kein einzelnes Tool deckt alles ab. In der Praxis hat sich eine Kombination bewährt: Semgrep oder ESLint Security für schnelle SAST-Checks im PR, Trivy oder Snyk für SCA und Container-Scanning, und ein scheduled Full-Scan mit einem tieferen Tool wie CodeQL für die wöchentliche Analyse.

Checkliste: Scanner sinnvoll einsetzen

Regelsets auf das eigene Stack einschränken – keine PHP-Regeln in TypeScript-Projekten
Delta-Reporting aktivieren – nur neue Findings im PR anzeigen
Schwellenwerte definieren – nicht alles bricht den Build
Suppressions dokumentieren und versionieren
Reachability-Analyse nutzen, wo verfügbar
Scanner-Ergebnisse regelmäßig reviewen – sinkt die False-Positive-Rate?
KI-Bewertungen bei kritischen Findings manuell prüfen
Secret-Scanner als Pre-Commit-Hook, nicht erst in der CI

Die richtige Balance

Scanner sind Werkzeuge, keine Orakel. Wer sie unkonfiguriert laufen lässt, ertrinkt in Rauschen. Wer sie zu aggressiv unterdrückt, übersieht echte Risiken. Die Kunst liegt dazwischen: genug Empfindlichkeit, um nichts Relevantes zu verpassen, und genug Filterung, um die Findings bearbeitbar zu halten.

Das bedeutet Arbeit – nicht einmalig, sondern kontinuierlich. Regelsets anpassen, wenn sich der Stack ändert. Suppressions überprüfen, wenn Dependencies aktualisiert werden. Die False-Positive-Rate messen und als Metrik behandeln, nicht als unvermeidliches Schicksal.

Wer das tut, verwandelt den Scanner von einem Störfaktor in ein Werkzeug, dem das Team vertraut. Und Vertrauen in die eigenen Sicherheitstools ist die Voraussetzung dafür, dass Findings ernst genommen werden – die wenigen, die es verdienen.

Quellen und weiterführende Links

Security wird Continuous – Teil 5 der Serie: Strategie und Teamorganisation.
nosecrets: Secrets aus Git-Commits fernhalten – Pre-Commit Secret-Scanning.
Semgrep – Schneller, konfigurierbarer SAST-Scanner.
Trivy – Open-Source-Scanner für Dependencies und Container.
Snyk – Developer-Security-Plattform mit Reachability-Analyse.
Socket – Supply-Chain-Security mit Verhaltensanalyse.