Kann man KI-generierten Schwachstellenbefunden trauen? KI-Halluzinationen in der Sicherheitsanalyse vermeiden

KI kann Ihnen helfen, Schwachstellendaten schneller zu prüfen, doch eine selbstsichere Antwort ist noch kein geprüfter Befund. Eine KI-Halluzination kann eine Komponente erfinden, die Ausnutzbarkeit falsch einschätzen, nicht existierende Belege zitieren oder aus unvollständigen Daten eine zu sichere Schlussfolgerung machen. Für PSIRT-, Security- und Compliance-Teams ist der sicherste Weg, jede KI-gestützte Entscheidung auf Firmware-Nachweise, SBOM-Daten, VEX-Status und einen prüfbaren Audit-Trail zurückzuführen.

Warum KI-Halluzinationen im Schwachstellenmanagement ein wachsendes Risiko sind

Sicherheitsteams erhalten immer mehr maschinell erzeugte Zusammenfassungen, Klassifizierungen und Empfehlungen zur Behebung. Das Problem beginnt, wenn ein KI-System Lücken in den vorhandenen Belegen füllt, statt zu zeigen, dass die Belege fehlen. Eine KI-Halluzination im Schwachstellenmanagement kann Entwicklungszeit an einen falschen Befund verschwenden oder, schwerwiegender, ein trügerisches Vertrauen schaffen, dass eine reale Schwachstelle das Produkt nicht betrifft.

KI-Fehlalarme (False Positives) wirken oft überzeugend, weil sie echte CVE-Details mit der falschen Komponentenversion, dem falschen Firmware-Zweig, einer falschen Konfiguration oder einer falschen Einsatzannahme kombinieren. Ein Modell kann eine Schwachstelle korrekt beschreiben, aber fälschlich behaupten, der betroffene Code sei in Ihrem Gerät vorhanden oder erreichbar. Das Schwachstellenmanagement von ONEKEY hält Befunde an Produktnachweise, Bewertung, VEX-Informationen, Assessment-Status und Historie gebunden, statt sich allein auf eine KI-Antwort zu verlassen.

Der Druck wächst, weil die Zahl neuer Schwachstellen die manuelle Prüfung längst überholt hat. Genau deshalb greifen Teams zu KI, um Beschreibungen, Hersteller-Advisories und Klassifizierungen schneller zu sichten. Der Gewinn an Tempo ist real, doch er verschiebt das Risiko: Wo eine Analystin früher „unklar“ notiert hätte, liefert ein Modell eine glatte Antwort, die richtig klingt. Ohne belegte Grundlage wird aus dieser Bequemlichkeit eine Fehlerquelle, die sich durch jede nachgelagerte Entscheidung zieht.

Was einen Befund vertrauenswürdig macht statt halluziniert

Ein vertrauenswürdiger Befund lässt sich von der Aussage bis zu den Belegen im Produkt und bis zum externen Schwachstelleneintrag zurückverfolgen. Sie sollten sehen können, welche Komponente gefunden wurde, welche Version vorliegt, warum das CVE zugeordnet wurde, welcher Produktkontext das Risiko verändert und wie das Assessment zustande kam. Das NIST nennt gültiges und verlässliches, verantwortliches und transparentes sowie erklärbares und interpretierbares Verhalten als zentrale Merkmale vertrauenswürdiger KI.

Ein halluzinierter oder schwacher Befund durchbricht diese Kette. Er behauptet womöglich, verwundbarer Code existiere, ohne zu belegen, dass die Komponente vorhanden ist, unterstellt einen Angriffspfad, der nie beobachtet wurde, oder empfiehlt eine Behebung, ohne zu zeigen, welche Produktbedingung sie ausgelöst hat. KI-Fehlalarme und Halluzinationen sind nicht dasselbe, doch beide werden gefährlich, sobald Ihr Team die Grundlage des Ergebnisses nicht mehr prüfen kann.

In der Praxis heißt vertrauenswürdige KI, dass jeder Befund eine überprüfbare Herkunft hat. Ein Assessment sollte zeigen, welche Datenquelle den Treffer ausgelöst hat, welche Firmware-Version geprüft wurde und welche Annahme das Ergebnis trägt. Fehlt einer dieser Belege, ist der Befund nicht automatisch falsch, aber unbestätigt, und unbestätigte Befunde gehören in die Prüfung und nicht in einen Behebungs-Sprint.

Erklärbarkeit als Gegenmittel gegen Halluzination

Erklärbarkeit bedeutet nicht, jede interne Berechnung eines KI-Modells offenzulegen. Im Schwachstellenmanagement heißt es, genügend Belege zu zeigen, damit eine Sicherheitsfachkraft nachvollziehen kann, warum das System zu einem Ergebnis kam, und es bei Bedarf hinterfragen kann. Das NIST weist darauf hin, dass erklärbare und interpretierbare Systeme leichter zu debuggen, zu überwachen, zu dokumentieren, zu auditieren und zu steuern sind.

Genau hier sollte sich erklärbare KI von einer Chatbot-Antwort unterscheiden. Ein nützliches Ergebnis verweist auf die Komponente, die Version, das Firmware-Artefakt, die relevante Funktion, die Schwachstellenquelle und den nach der Prüfung vergebenen Status. Die automatisierte Folgenabschätzung / VEX von ONEKEY nutzt Firmware-Nachweise, um zu bewerten, ob ein CVE einen bestimmten Build wahrscheinlich betrifft, und unterstützt strukturierte Schwachstellenentscheidungen statt einer unbelegten Ja-oder-Nein-Aussage.

Die drei Bausteine gegen halluzinierte Befunde

Keine einzelne Kontrolle kann jede KI-Ausgabe korrekt machen. Sie brauchen unabhängige Produktnachweise, eine strukturierte Möglichkeit, Ausnutzbarkeit auszudrücken, und Aufzeichnungen, die zeigen, wie die endgültige Entscheidung zustande kam. Diese Kontrollen lassen Sie vertrauenswürdige KI einsetzen, ohne Ihr Team zu zwingen, dem Modell auf Zuruf zu glauben.

SBOM

Eine Software Bill of Materials (SBOM) liefert Ihnen ein strukturiertes Inventar aus Komponenten, Bibliotheken, Versionen und Abhängigkeiten. Sie bildet einen faktischen Ausgangspunkt, um zu prüfen, ob ein CVE für das geprüfte Produkt überhaupt gelten kann. Das SBOM-Management von ONEKEY kann eine SBOM aus Firmware-Binärdateien erzeugen und mit importierten Daten anreichern, was hilft, wenn Quellcode oder Zulieferinformationen unvollständig sind.

VEX

VEX (Vulnerability Exploitability eXchange) hält fest, ob eine bekannte Schwachstelle ein bestimmtes Produkt betrifft, und kann eine Begründung für eine „nicht betroffen“-Entscheidung enthalten. Die CISA definiert Produktstatus wie NOT AFFECTED, AFFECTED, FIXED und UNDER INVESTIGATION, wobei für „nicht betroffen“-Aussagen maschinenlesbare Begründungen verfügbar sind. So erhält Ihr Team einen wiederverwendbaren Entscheidungsnachweis statt einer einmaligen KI-Erklärung.

Auditfähige Nachweise (CRA, RED, IEC 62443)

Auditfähige Nachweise dokumentieren, was erkannt wurde, welche Firmware-Version bewertet wurde, was die Entscheidung stützte, wer sie geprüft hat und wann sich der Status geändert hat. Ab dem 11. Dezember 2027 verpflichtet der Cyber Resilience Act (CRA) Hersteller, Schwachstellen und Komponenten von Produkten zu identifizieren und zu dokumentieren, auch über eine SBOM, während die IEC 62443-4-1 Lebenszyklusprozesse wie Verifizierung, Fehlermanagement und Patch-Management abdeckt. Die Cybersicherheitsanforderungen der RED nach der Delegierten Verordnung 2022/30 bleiben für erfasste Funkanlagen bis zum 10. Dezember 2027 relevant; die Verordnung soll zum 11. Dezember 2027 aufgehoben werden, sobald der CRA vollständig anwendbar wird.

Warum Firmware-Analyse ein anderes Vertrauensmodell braucht als generische LLMs

Generische KI-Sicherheitstools arbeiten oft mit Quell-Repositories, Endpunktdaten, Tickets, Cloud-Logs oder Laufzeittelemetrie. Embedded-Produkte liefern davon möglicherweise nichts, besonders wenn die Firmware von einem Zulieferer stammt oder das Gerät seit Jahren im Einsatz ist. Ein Modell kann eine CVE-Beschreibung erläutern, aber es kann nicht wissen, was in einem Binary steckt, solange Sie ihm keine verlässlichen Produktnachweise geben.

Firmware-Analyse muss deshalb Fakten schaffen, bevor die KI sie interpretiert. Die Binäranalyse kann Komponenten identifizieren und extrahierte Dateien, Funktionen, Merkmale und weitere Artefakte prüfen, die helfen zu bestimmen, ob eine Schwachstelle für einen bestimmten Build relevant ist. Die Pressemitteilung von ONEKEY aus Juni 2026 trifft dieselbe Unterscheidung: KI kann die Sicherheitsanalyse beschleunigen, doch Produktentscheidungen brauchen weiterhin transparente Belege und eine dokumentierte Risikobewertung.

Eine KI-Halluzination im Schwachstellenmanagement wird weniger gefährlich, wenn die KI auf geprüften Firmware-Nachweisen aufsetzt, statt sie zu ersetzen. Das Modell kann Befunde klassifizieren, zusammenfassen oder erklären, während Binärnachweise, Schwachstelleneinträge und strukturierte Assessments die Entscheidung verankern. Sie gewinnen Tempo, ohne „das Modell hat es gesagt“ zu Ihrer Sicherheitsbegründung zu machen.

Wo menschliche Prüfung weiterhin entscheidend ist

Automatisierung soll wiederkehrende Arbeit reduzieren, nicht die Verantwortung für folgenreiche Entscheidungen abschaffen. Menschliche Prüfung bleibt wichtig, wenn Belege im Widerspruch stehen, das Produkt Sicherheitsimplikationen hat, die Ausnutzbarkeit von ungewöhnlichen Einsatzbedingungen abhängt, ein Zulieferer einen Befund bestreitet oder eine Behebung ein langlebiges Gerät stören könnte. Das NIST betont ebenfalls, dass die Vertrauenswürdigkeit von KI vom Kontext abhängt und menschliches Urteilsvermögen nötig ist, um passende Metriken und Schwellenwerte festzulegen.

Ein praxistaugliches Prüfmodell ist risikobasiert statt pauschal. Lassen Sie die Automatisierung starke, wiederholbare Belege verarbeiten und leiten Sie unsichere oder folgenreiche Fälle an eine Analystin oder einen Analysten weiter, die die Annahmen und Produktfolgen prüfen können. Teams, die einen solchen belegbasierten Ablauf bewerten möchten, können eine Demo buchen und ihn mit ihrem aktuellen Schwachstellenprozess vergleichen.

Praxisbeispiel: Wenn ein KI-Befund genauer geprüft werden muss

Stellen Sie sich vor, ein KI-Assistent meldet, dass ein kritisches CVE eine Industriesteuerung betrifft, weil eine verwundbare Bibliothek „von der Firmware genutzt wird“. Die Beschreibung des CVE ist korrekt, also wirkt das Ergebnis glaubwürdig, und eine Entwicklerin ist bereit, die Bibliothek auszutauschen. Es fehlt der entscheidende Nachweis, dass die betroffene Funktionalität in genau diesem Firmware-Build vorhanden ist.

Ein belegbasierter Ablauf prüft die Behauptung, bevor ein Behebungs-Sprint eröffnet wird:

1. Inventar prüfen. Bestätigen Sie, ob die genannte Bibliothek und die exakte Version in der aus der Firmware abgeleiteten SBOM vorhanden sind.
2. Binärnachweise sichten. Suchen Sie nach Dateien, Funktionen, Symbolen, Merkmalen oder Nutzungen, die den CVE-Treffer stützen.
3. Betroffene Bedingungen abgleichen. Vergleichen Sie den Hersteller- oder Schwachstelleneintrag mit Produktversion und Konfiguration.
4. Ausnutzbarkeit dokumentieren. Nutzen Sie VEX, um den Status „betroffen“, „nicht betroffen“, „behoben“ oder „in Prüfung“ mit der verfügbaren Begründung festzuhalten.
5. Entscheidung aufbewahren. Bewahren Sie Belege, Prüfende, Firmware-Version und Assessment-Historie für eine spätere Überprüfung auf.

Angenommen, die Komponente ist vorhanden, aber die verwundbare Funktion wurde nicht in die Firmware kompiliert. Der ursprüngliche KI-Befund wird verworfen, weil die Produktnachweise ihn nicht stützen, was einen unnötigen Sprint verhindert und eine dokumentierte Entscheidungsgrundlage schafft. Aktiviert ein späterer Firmware-Build diese Funktion, kann das Team die Belege neu bewerten, statt der alten Schlussfolgerung zu vertrauen.

Das ist die praktische Rolle erklärbarer KI im Schwachstellenmanagement. KI kann Interpretation und Kommunikation beschleunigen, doch SBOM, Binärnachweise, VEX und Audit-Historie bleiben die Quellen, die Ihr Team prüfen und verteidigen kann. Vertrauenswürdige KI entsteht aus einem Ablauf, der die Ausgabe des Modells belegen oder widerlegen kann.