Wenn eine CVE nur überzeugend aussieht

Eine erfundene CVE sieht auf den ersten Blick erstaunlich echt aus.

Ich hatte ein Modell gebeten, bekannte Schwachstellen für ein bestimmtes Softwareprodukt zusammenzufassen. Die Antwort kam sauber formatiert, mit CVE-Nummern, CVSS-Werten und kurzen Beschreibungen. Drei von fünf Einträgen stimmten. Zwei CVE-Nummern existierten nicht.

Dieser Fall hat meine Arbeitsweise stärker verändert als viele gute Modellantworten.

Eine überzeugende Liste mit zwei erfundenen Einträgen

Das Modell markierte keinen Zweifel. Die erfundenen Schwachstellen sahen genauso belastbar aus wie die echten. Wer nur auf Sprache und Format schaut, erkennt den Unterschied nicht.

Seitdem behandle ich KI-Ausgaben bei CVE-Recherchen als Hinweise, nicht als Nachweis. Eine Schwachstelle kommt erst in einen Bericht, wenn sie sich in einer belastbaren Quelle bestätigen lässt, etwa beim CVE Program oder beim Hersteller. Fehlt der Beleg, bleibt der Eintrag draußen.

Das ist kein Urteil gegen Sprachmodelle. Sie können eine Recherche beschleunigen. Sie verschieben aber nicht die Verantwortung für die Aussage.

Warum der Fehler im Security-Kontext teuer wird

Eine erfundene CVE kann Prioritäten verzerren. Ein Team prüft eine Schwachstelle, die es nicht gibt, während ein reales Finding liegen bleibt. Im schlechtesten Fall landet die Behauptung in einer Entscheidungsvorlage oder in einem Kundenbericht.

Dasselbe Grundproblem taucht bei sensiblen Eingaben auf. Mir ist aus einem anderen Kontext ein Fall bekannt, bei dem Forensik-Artefakte in einen öffentlichen KI-Dienst eingegeben wurden. Das war kein eigener Incident-Response-Einsatz von mir. Der Fall bleibt trotzdem ein brauchbares Warnsignal. Hostnamen, interne IP-Adressen oder Malware-Konfigurationen gehören nicht ungeprüft in einen externen Dienst.

Ob daraus im Einzelfall eine Datenschutzverletzung, eine Meldepflicht oder eine Vertragsverletzung folgt, hängt vom konkreten Sachverhalt ab. Diese Bewertung ersetzt der Blog nicht.

Meine Konsequenz daraus

Ich trenne seitdem klar zwischen Generierung und Verifikation. Das Modell darf suchen, ordnen und Hypothesen formulieren. Die belastbare Aussage braucht eine Quelle oder einen technischen Nachweis.

Für sensible Daten kommt eine zweite Grenze hinzu. Vor dem Einsatz muss feststehen, welche Daten das System verlassen dürfen. Lokale Verarbeitung kann dabei helfen. Sie löst aber nicht automatisch jedes Risiko, etwa fehlerhafte Berechtigungen oder unzureichendes Logging.

Auch Prompt Injection, Halluzinationen und zu weit reichende Agentenrechte lassen sich mindern, aber nicht pauschal beseitigen. Kontrollen senken Risiken. Sie machen ein probabilistisches System nicht fehlerfrei.

Die Regel, die geblieben ist

Die zwei erfundenen CVEs waren kein kurioser Modellfehler. Sie zeigten mir, wie leicht gutes Format mit guter Evidenz verwechselt wird. Seitdem gilt für mich: erst belegen, dann berichten.