LLMs für die Priorisierung von CVEs und Patches: was die Forschung zeigt

KI kann Schwachstellendaten schnell zusammenfassen, aber Geschwindigkeit ist keine verlässliche Priorisierung. Studien zeigen: LLMs können Teile der CVE Priorisierung unterstützen, ihre Empfehlungen hängen jedoch stark vom Prompt-Design, den verfügbaren Belegen und dem übergebenen Kontext ab. Für Firmware und embedded Produkte ist das eine ernste Einschränkung, denn Quellcode und Laufzeittelemetrie fehlen dort häufig.

EPSS, CISA KEV und CVSS: was die Patch-Reihenfolge bestimmen sollte

Kein einzelner Wert sagt Ihnen, was Sie zuerst patchen sollten. CVSS, EPSS und CISA KEV beantworten unterschiedliche Fragen. Ihr Prozess sollte sie deshalb mit Belegen aus dem Produkt selbst verbinden. Die Debatte EPSS vs. CVSS wird nützlicher, sobald Sie jedes Signal als Eingangsgröße behandeln und nicht als Endergebnis.

Was die einzelnen Rahmenwerke messen

CVSS beschreibt Eigenschaften und Schweregrad einer Schwachstelle. CVSS v4.0 trennt dabei Base-, Threat-, Environmental- und Supplemental-Metriken. EPSS schätzt die Wahrscheinlichkeit, dass ein veröffentlichtes CVE innerhalb der nächsten 30 Tage aktiv ausgenutzt wird, und aktualisiert die Werte täglich. CISA KEV funktioniert anders: Die Aufnahme in den Katalog bedeutet, dass eine Ausnutzung in der Praxis belegt ist.

Die Tabelle zeigt, warum EPSS vs. CVSS keine Entweder-oder-Frage ist. FIRST beschreibt EPSS ausdrücklich als Ausnutzungswahrscheinlichkeit und nicht als vollständigen Risikowert. Nach der aktuellen Empfehlung hat belegte Ausnutzung Vorrang vor Prognosen. Für Produktteams bleibt damit eine weitere Frage offen: ob die betroffene Komponente, Funktion oder Fähigkeit in der ausgelieferten Firmware überhaupt vorhanden und relevant ist. ONEKEY Features entdecken.

Wann Sie welchem Signal folgen sollten

Beginnen Sie mit CISA KEV, wenn eine Ausnutzung belegt ist. Nutzen Sie anschließend EPSS, um Schwachstellen ohne belegte Ausnutzung zu ordnen. CVSS hilft beim technischen Schweregrad und beim Wirkungskontext, der Base Score allein sollte aber keine Patch-Reihenfolge bestimmen. Ihre Entscheidung sollte zusätzlich Erreichbarkeit, Nutzung der Komponente, Einsatzszenario, kompensierende Maßnahmen, Sicherheitsrelevanz und die Machbarkeit des Patches berücksichtigen.

Ein automatisiertes Schwachstellenmanagement bündelt diese Eingangsgrößen in einem wiederholbaren Ablauf, statt Analysten zum manuellen Abgleich zu zwingen. Das zählt bei vernetzten Produkten, in denen dasselbe CVE in einer Firmware-Version relevant und in einer anderen bedeutungslos ist. Gute CVE-Priorisierung verbindet externe Bedrohungssignale mit Nachweisen aus dem Produkt.

Was LLMs in der CVE-Triage leisten und was nicht

LLMs sind stark darin, halbstrukturierte Schwachstelleninformationen zu lesen, zusammenzufassen, zu klassifizieren und zu verknüpfen. Sie verkürzen die Zeit, die das Verstehen von Beschreibungen, Herstellerhinweisen und anderen Texten kostet, sofern die nötigen Fakten dort tatsächlich stehen. Unzuverlässig wird die LLM-gestützte Priorisierung, sobald das Modell fehlende Einsatzinformationen erraten oder aus unvollständigen Belegen eine Handlungsempfehlung ableiten soll.

Übereinstimmung von nur 0,06 bis 0,21

Eine Studie aus dem Jahr 2025 hat ChatGPT, Claude, Gemini und DeepSeek mit 12 Prompting-Techniken an 384 realen Schwachstellen und über 165.000 Abfragen getestet. Die Modelle sollten SSVC-Entscheidungspunkte vorhersagen und wurden mit der Referenz aus Vulnrichment verglichen. Für die Endergebnisse berichtet die Studie ungewichtete Werte von Cohens Kappa von lediglich 0,06 bis 0,10. Nur DeepSeek erreichte unter gewichteter Bewertung eine „faire“ Übereinstimmung. Alle vier Modelle neigten außerdem dazu, das Risiko zu überschätzen, was genau die Alarmflut wiederherstellt, die eine CVE Priorisierung eigentlich auflösen soll.

Das heißt nicht, dass LLMs in der Triage keine Rolle haben. Dieselbe Untersuchung fand bei einzelnen Teilaufgaben deutlich bessere Werte, mit einem besten F1-Wert von 0,79 beim Entscheidungspunkt „Exploitation“, und beispielbasierte Prompts schnitten häufig besser ab. ONEKEYs automatisierte Wirkungsanalyse arbeitet dagegen mit Firmware-Nachweisen wie enthaltenen Komponenten, Binärnutzung, Dateien, Funktionen und Symbolen, um zu bewerten, ob ein CVE für einen konkreten Build relevant ist. Ein LLM kann strukturierte Funde erklären. Die Entscheidung selbst sollte auf Belegen beruhen, die Sie nachprüfen können.

Warum die CVE-Menge die manuelle Triage überholt hat

Der Strom neuer Schwachstellen wächst schneller, als Teams jeden Eintrag von Hand prüfen können. Das NIST berichtete im April 2026, dass die CVE-Einreichungen zwischen 2020 und 2025 um 263 % gestiegen sind und die Einreichungen in den ersten drei Monaten 2026 fast ein Drittel über dem Vorjahreszeitraum lagen. Auch die Anreicherung von knapp 42.000 CVEs im Jahr 2025, 45 % mehr als in jedem Jahr davor, hielt mit den Einreichungen nicht mit. Seit April 2026 arbeitet das NIST mit einem risikobasierten Modell, das ausgewählte CVEs für die Anreicherung priorisiert.

Dieser Druck verändert, was wirksame CVE-Priorisierung bedeutet. Teams müssen belegte Ausnutzung, prognostizierte Ausnutzung, theoretischen Schweregrad, tatsächliche Produktexposition und regulatorische Wirkung trennen, bevor knappe Entwicklungszeit vergeben wird. Ein CRA-Readiness-Assessment hilft Ihnen einzuordnen, wo Schwachstellenbehandlung und die zugehörigen Nachweise in Ihre Pflichten zur Produktcybersicherheit passen. Produktteams brauchen zudem Abläufe, die mit unvollständiger öffentlicher Anreicherung funktionieren, statt auf die fertige Analyse einer Datenbank zu warten.

Firmware und Embedded: kein Quellcode, kein Kontext

Firmware verschärft das Priorisierungsproblem. Sie haben vielleicht ein Binary vom Zulieferer oder ein Gerät im Feld, aber kein Repository, kein Build-Manifest, keinen Agenten auf dem Endpunkt und keine Laufzeittelemetrie, die einem LLM verraten könnte, ob eine anfällige Funktion überhaupt erreichbar ist. Öffentlicher CVE-Text beschreibt eine Schwachstelle, aber nicht die genaue Architektur und den Funktionsumfang jedes Geräts, das die Komponente enthält. Ein Treffer auf den Komponentennamen belegt nicht, dass die Schwachstelle in Ihrem Produkt ausnutzbar ist.

Ein Firmware-Prozess braucht daher zuerst ein Inventar und dann eine Erklärung. ONEKEYs SBOM-Management-Tool erkennt Komponenten direkt aus kompilierten Binaries und liefert Softwarekontext, wenn Quellcode oder Zulieferdaten unvollständig sind. Die Embedded-Umgebung verändert außerdem die Dringlichkeit der Behebung, denn Medizingeräte, Industriesteuerungen, Steuergeräte und IoT-Produkte bleiben oft jahrelang im Einsatz, während Patches Tests oder Abstimmung mit Zulieferern erfordern. Die Priorität muss reale Exposition und die Grenzen der Behebung abbilden, nicht nur das, was ein LLM oder ein externer Wert als „kritisch“ bezeichnet.

Wie ONEKEY Firmware-Schwachstellen ohne Quellcode bewertet

ONEKEY beginnt beim Firmware-Binary, statt ein LLM raten zu lassen, was darin enthalten sein könnte. Die Plattform analysiert die Firmware, erkennt Komponenten, verknüpft sie mit CVEs und wendet die automatisierte Wirkungsanalyse an, um die Relevanz für den konkreten Build zu bestimmen. Die Bewertung nutzt regelbasierte Prüfungen, die Komponentenversion, Architektur, kompilierte Funktionen, Dateinamen, Strings, Funktionsimporte, Binärnutzung, Zuordnung zu Quelldateien und Symbole einbeziehen können. Belege zeigen Ihrem Team, warum eine Schwachstelle als relevant oder als nicht betroffen eingeordnet wurde.

Dieser Ansatz adressiert die zentrale Schwäche rein KI-basierter Triage: den fehlenden Produktkontext. Sie verbinden Firmware-Nachweise mit CVSS Environmental Scoring, SSVC-Bewertungen, VEX-Status, EPSS-Informationen, Analystenentscheidungen und Nachweisketten, statt ein einziges Modell einen Prioritätswert erfinden zu lassen. ONEKEY kann übereinstimmende Schwachstellenbewertungen außerdem zwischen Firmware-Versionen übernehmen und dabei Status, Begründung, Notizen, SSVC-Daten und Environmental Scoring erhalten. Das verkleinert das Backlog, während Ihr Team die Kontrolle über Entscheidungen mit sicherheits-, regulatorischen oder betrieblichen Folgen behält. Sehen Sie die ONEKEY Platform live!