Wo KI-Sicherheitstools an Grenzen stoßen und was deterministische Build-Nachweise abdecken

Das Argument, eng gefasst

Dies ist kein Plädoyer gegen KI in der Sicherheit. Modelle können gut Code lesen, einen Befund erklären und einen Fix vorschlagen, und Teams, die sie gut einsetzen, sind schneller. Das Argument ist enger: Für Aufzeichnungen, die später Bestand haben müssen, ist ein probabilistisches Modell die falsche Primärquelle. Das betrifft die SBOM, die Sie einer Behörde vorlegen, die Provenienz des ausgelieferten Artefakts und die Antwort auf „Waren wir betroffen?“

Drei Eigenschaften entscheiden, ob eine Aufzeichnung Bestand hat. Jeder Abschnitt unten behandelt eine davon, mit Beispielen und Quellen.

1. Reproduzierbarkeit: zweimal fragen, dieselbe Antwort erhalten

Eine Sicherheitsaufzeichnung ist nur nützlich, wenn jemand anderes aus derselben Eingabe dieselbe Antwort erhält. Sprachmodelle versprechen das nicht, und die Anbieter sagen es selbst.

• Die Dokumentation von Anthropic: „Selbst mit einer Temperature von 0 sind die Ergebnisse nicht vollständig deterministisch, und identische Eingaben können über API-Aufrufe hinweg unterschiedliche Ausgaben liefern.“
• GitHub zu Copilot Autofix: „Selbst bei derselben Warnung und demselben Code gelingt möglicherweise kein brauchbarer Vorschlag, oder der Vorschlag unterscheidet sich von Versuch zu Versuch.“
• Die Forschenden hinter dem Framework SecLLMHolmes testeten für die IEEE S&P 2024 acht LLMs an 228 Code-Szenarien. Sie berichten, dass die Modelle „nicht deterministische Antworten liefern“ und dass PaLM2 und GPT-4 „schon durch das bloße Ändern von Funktions- oder Variablennamen oder durch das Hinzufügen von Bibliotheksfunktionen im Quellcode“ in 26 % bzw. 17 % der Fälle falsche Antworten gaben.

Beispiel. Zwei Engineers fragen denselben Assistenten, ob ein Service von einer neuen Sicherheitsmeldung betroffen ist. Einer erhält „nein“, der andere „möglicherweise, prüfen Sie den transitiven Baum“. Keine der beiden Antworten ist eine Aufzeichnung, und keine lässt sich sechs Monate später für einen Auditor reproduzieren.

Ein aufgezeichneter Build hat dieses Problem nicht, weil nichts abgeleitet wird. CRACI beobachtet während des Jobs die Pakete, die er aus Paketquellen lädt, und die SBOM ist eine Aufzeichnung dieser Beobachtung.

2. Prüfbarkeit: zeigen, woher Sie es wissen

In Audits geht es um die Frage „Woher wissen Sie das?“ Ein Modell kann eine flüssige Antwort geben, aber seine Erklärung ist kein Nachweis. Die Evaluierung mit SecLLMHolmes ergab, dass LLMs „falsche und nicht zutreffende Begründungen“ zu den Schwachstellen liefern, die sie bewerten. Ein korrektes Urteil kann also mit einer Erklärung einhergehen, die nicht stimmt.

Die Standards bewegen sich hin zu Aufzeichnungen, die ihre eigene Herkunft erklären. Die SBOM-Mindestelemente von 2026, veröffentlicht von der CISA mit der NSA, dem FBI und internationalen Partnern, ergänzen einen SBOM Tool Name, eine SBOM Tool Version und einen SBOM Generation Context, der angibt, ob die SBOM „vor dem Build“, während des „Builds“ oder „nach dem Build“ erstellt wurde. Dasselbe Dokument warnt, dass „Organisationen Fehler, ob sie aus der Praxis der SBOM-Autoren oder der Auswahl ungeeigneter Tools stammen, in ihre Entscheidungen zum Risikomanagement einbeziehen können“.

Beispiel. Ein Kundenfragebogen fragt, wie Ihre SBOM erstellt wurde. „Ein Assistent hat das Repository gelesen und sie geschrieben“ liefert einen Generation Context, aber keinen, den ein Prüfer nachvollziehen kann. „Sie wurde während des Release-Builds im CI-Runner aufgezeichnet, und der Vollständigkeitsstatus des Jobs ist Complete“ kann der Prüfer am Build verifizieren.

3. Vollständigkeit: Was Sie nie gesehen haben, können Sie nicht melden

Ein Modell urteilt über das, was ihm gezeigt wird. Wenn die gelesenen Dateien die Software nicht beschreiben, tut es die Antwort auch nicht, und nichts in der Ausgabe weist darauf hin. Die Leitlinie der CISA von 2026 setzt die Messlatte bei der Entscheidung des Empfängers an: Er „sollte schließen können, dass eine neu gemeldete Schwachstelle ihn nicht betrifft, wenn die SBOM die Komponente nicht auflistet“. Das funktioniert nur, wenn das Fehlen in der Liste das Fehlen im Build bedeutet.

Beispiel. Das Repository anthropics/claude-code hat bei v2.1.259 weder ein Abhängigkeitsmanifest noch ein Lockfile irgendeiner Art. Das veröffentlichte npm-Paket deklariert null Laufzeitabhängigkeiten und kapselt eine vorkompilierte native Binärdatei. Jedes Tool, das das Repository liest, ob KI oder nicht, hat fast nichts aufzulisten, während das ausgeführte Programm eine kompilierte Binärdatei ist.

Beispiel. KI-Coding-Tools können die Lücke auch selbst verursachen. GitHub warnt, dass Copilot Autofix „möglicherweise erfundene Abhängigkeiten vorschlägt, die unter statistisch wahrscheinlichen Namen veröffentlicht wurden“. Eine Studie auf der USENIX Security 2025 mit 576.000 generierten Codebeispielen aus 16 Modellen fand eine durchschnittliche Rate halluzinierter Pakete von mindestens 5,2 % bei kommerziellen und 21,7 % bei Open-Source-Modellen, mit 205.474 eindeutigen halluzinierten Paketnamen.

Deterministisch ist notwendig, aber nicht hinreichend

Eine ehrliche Fassung dieses Arguments muss auch den nächsten Punkt enthalten. SBOM-Generatoren sind deterministisch, und trotzdem widersprechen sie einander. Auf denselben Commit von expressjs/express angesetzt, können sie unterschiedliche Listen liefern, weil jeder selbst entscheidet, was als Komponente zählt und welchen Dateien er vertraut. Das Repository committet kein Lockfile. Ein Tool, das Abhängigkeiten aus einem Lockfile auflöst, hat also keine einzige der Abhängigkeiten aus package.json zu melden.

Ein deterministischer Scanner reproduziert jedes Mal dieselbe unvollständige Antwort. Wiederholbarkeit ist notwendig, aber die Lücke schließt erst die Beobachtung: aufzeichnen, was der Build tatsächlich geladen hat, und angeben, wenn die Aufzeichnung unvollständig ist. CRACI kennzeichnet jeden Job und jeden Cache als Complete, Complete with connections, Incomplete, Unavailable oder Not recorded.

Ein durchgespieltes Beispiel: eine neue Sicherheitsmeldung eingrenzen

Ein hypothetischer Fall: Für eine Version eines weit verbreiteten npm-Pakets wird eine Sicherheitsmeldung veröffentlicht. Nach dem Cyber Resilience Act haben Hersteller 24 Stunden Zeit, eine aktiv ausgenutzte Schwachstelle an die ENISA zu melden. Die Eingrenzung muss also schnell und richtig sein.

Der Weg mit KI zuerst

Sie bitten einen Assistenten, Ihre Repositories zu prüfen. Er liest Manifeste und Lockfiles, vielleicht ein Dockerfile. Er sieht keine Pakete, die aus einem CI-Cache wiederhergestellt wurden, keine Tools, die ein Build-Schritt heruntergeladen hat, und keine Versionen, die in einem Repository ohne Lockfile bei der Installation aufgelöst wurden. Zweimal gefragt, antwortet er womöglich unterschiedlich. Seine Zusammenfassung ist nützlich, aber Ihre Meldung können Sie nicht darauf stützen.

Der Weg mit der Aufzeichnung zuerst

CRACI führt Schwachstellen über Builds und Repositories hinweg zusammen, bezogen auf den Default-Branch auf Organisationsebene, und bewertet überwachte SBOMs neu, sobald neue Schwachstellen auftauchen. Die API liefert die CycloneDX-SBOM jedes Builds, seinen Netzwerk-Trace und die Provenienz. Ist die Aufzeichnung eines Jobs unvollständig, zeigt Ihnen sein Vollständigkeitsstatus, wo Sie von Hand nachsehen müssen. Sie können ein Modell trotzdem bitten, das Ergebnis zusammenzufassen. Es fasst dann eine Aufzeichnung zusammen, statt eine zu erzeugen.

Mit der Aufzeichnung ist die Frage „Welche Releases haben dieses Paket ausgeliefert?“ eine Abfrage, keine Untersuchung.

Im direkten Vergleich

Jedes Tool dort einsetzen, wo es stark ist

Setzen Sie KI dort ein, wo Urteilsvermögen hilft und ein Mensch das Ergebnis prüft: Code-Review, das Erklären eines Befunds, der Entwurf eines Fixes. Setzen Sie deterministische Build-Aufzeichnungen dort ein, wo das Ergebnis reproduziert, geprüft oder als vollständig vorausgesetzt werden muss: SBOMs, Provenienz und die Eingrenzung von Vorfällen. CRACI automatisiert einen wesentlichen Teil dieser Lieferkettennachweise für einen umfassenderen CRA-Prozess. Konform macht es Sie allein nicht.

Lesen Sie, wie die Aufzeichnung entsteht, unter SBOM-Generierung während des Builds, oder beginnen Sie mit dem, was der CRA verlangt.