Eine KI-generierte SBOM ist eine Vermutung über Ihren Build. Behörden verlangen eine Aufzeichnung.

Warum Teams es versuchen

Der Reiz ist echt. Sie fügen ein Repository oder ein Lockfile in einen Coding-Assistenten ein, bitten um CycloneDX, und in Sekunden kommt ein wohlgeformtes Dokument zurück. Es kann sogar Felder füllen, die Scanner regelmäßig leer lassen. Das übliche Beispiel ist das Lieferantenfeld: Die meisten Generatoren haben dafür keine Quelle, also bleibt es leer. Ein Modell, das um ein vollständiges Dokument gebeten wird, kann in jedes Feld etwas schreiben.

Dieser letzte Punkt ist das Problem im Kleinen. Ein Scanner, der den Lieferanten nicht kennt, lässt das Feld leer. Ein Modell, das ihn nicht kennt, liefert womöglich trotzdem eine plausible Antwort. Das Dokument wirkt vollständiger und ist weniger verlässlich.

Was das Modell tatsächlich sieht

Ein Modell, das eine SBOM erzeugt, arbeitet mit dem Text, der ihm vorliegt: Manifeste, Lockfiles, vielleicht ein Dockerfile. Den Build beobachtet es nicht. Es kann also nicht sehen:

• welche Versionen der Paketmanager aufgelöst hat, wenn ein Repository kein Lockfile committet,
• Pakete, die aus einem CI-Cache wiederhergestellt wurden,
• Tools, OS-Pakete und Binärdateien, die ein Build-Schritt direkt herunterlädt,
• was in eine kompilierte Binärdatei eingeflossen ist, die neben einem fast leeren Manifest ausgeliefert wird.

Zwei Repositories zeigen, wie dürftig die Dateien sein können. expressjs/express 5.2.1 committet kein Lockfile, daher listet seine package.json Abhängigkeiten als Versionsbereiche auf, und die tatsächlichen Versionen werden erst bei der Installation festgelegt. Das Repository anthropics/claude-code hat bei v2.1.259 weder ein Abhängigkeitsmanifest noch ein Lockfile irgendeiner Art, und sein veröffentlichtes npm-Paket deklariert null Laufzeitabhängigkeiten und kapselt eine vorkompilierte native Binärdatei. Ein deterministischer Scanner, der auf dieses Repository angesetzt wird, findet nichts, was die Binärdatei beschreibt. Ein Modell mit denselben Dateien hat denselben Mangel an Informationen und mehr Freiheit, die Lücke zu füllen.

Halluzinationen sind ein dokumentiertes Fehlerbild

Sprachmodelle nennen Pakete, die es nicht gibt. Am besten belegt ist das bei der Codegenerierung und nicht beim Schreiben von SBOMs, aber der gezeigte Fehler gilt für eine Liste von Komponenten genauso. Eine Studie auf der USENIX Security 2025 erzeugte mit 16 Modellen 576.000 Codebeispiele und fand einen durchschnittlichen Anteil halluzinierter Pakete von mindestens 5,2 % bei kommerziellen und 21,7 % bei Open-Source-Modellen, mit 205.474 eindeutigen halluzinierten Paketnamen. Die eigene Dokumentation von GitHub zu Copilot Autofix warnt, dass es „may suggest fabricated dependencies published under statistically probable names“.

Modelle geben außerdem nicht zweimal dieselbe Antwort. In der Dokumentation von Anthropic heißt es: „even with temperature set to 0, the results will not be fully deterministic and identical inputs may produce different outputs across API calls.“ Zwei SBOMs aus demselben Commit können sich unterscheiden, und keine sagt, welche richtig ist.

In einer SBOM ist ein halluzinierter Eintrag kein harmloser Tippfehler. Ein Paket, das es nicht gibt, oder die falsche Version eines existierenden Pakets schickt eine Schwachstellenabfrage an die falsche Stelle, und das Ergebnis kommt selbstsicher und falsch zurück.

Was die Standards von einer SBOM erwarten

NTIA-Mindestelemente (2021)

Die NTIA-Basislinie definierte sieben Datenfelder: Lieferantenname, Komponentenname, Version der Komponente, andere eindeutige Kennungen, Abhängigkeitsbeziehung, Autor der SBOM-Daten und Zeitstempel. Dazu kamen Automatisierungsunterstützung und eine Reihe von Praktiken und Prozessen. Jedes Feld beschreibt eine Tatsache über die Software, keine Meinung.

CISA-Mindestelemente 2026

Am 29. Juli 2026 veröffentlichten die CISA, die NSA, das FBI und internationale Partner aktualisierte Mindestelemente, die die Basislinie von 2021 ersetzen. Mehrere Ergänzungen lassen sich ohne Beobachtung des Builds kaum erfüllen:

• SBOM Generation Context: die relative Phase im Software-Lebenszyklus und die Daten, die dem SBOM-Autor bei der Erstellung der SBOM zur Verfügung standen, mit „before build“, „build“ und „after build“ als Beispielen. Ein Modell, das ein Repository liest, befindet sich bestenfalls vor dem Build.
• Component Hash Value: der Wert, der entsteht, wenn ein kryptografischer Hash-Algorithmus auf ein ausführbares Komponentenartefakt angewendet wird. Hat der Autor das Artefakt nicht, soll er angeben, dass der Wert unbekannt ist. Ein Modell, das das Artefakt nie berührt hat, kann keinen Hash erzeugen, nur Text, der wie einer aussieht.
• SBOM Tool Name and Version: Das Tool, mit dem die SBOM erzeugt wurde, muss genannt werden.
• Coverage: Eine SBOM soll Angaben zu allen Komponenten der Zielsoftware enthalten, einschließlich transitiver Abhängigkeiten; eine Mindesttiefe gibt es nicht.
• Ausdrückliche Kennzeichnung unbekannter Informationen: Der Autor soll ausdrücklich angeben, ob die Information unbekannt ist. Ein erfundener Wert ist das Gegenteil davon.

Der EU Cyber Resilience Act

Der CRA macht die SBOM für Hersteller von Produkten mit digitalen Elementen zur gesetzlichen Pflicht. Anhang I Teil II verlangt von ihnen, Schwachstellen und Komponenten ihrer Produkte mit digitalen Elementen zu ermitteln und zu dokumentieren, unter anderem durch eine Software-Stückliste in einem gängigen, maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten der Produkte erfasst. Anhang VII verortet die SBOM in der technischen Dokumentation, und eine Marktüberwachungsbehörde kann sie anfordern, um die Einhaltung der grundlegenden Anforderungen zu prüfen.

Keiner dieser Texte verbietet KI-Tools. Sie verlangen Daten, die das tatsächliche Produkt beschreiben, und ehrliche Angaben darüber, was unbekannt ist. Eine SBOM, die auf Schlussfolgerungen beruht, tut sich mit beidem schwer.

Wie CRACI die SBOM erzeugt

CRACI führt Ihre GitHub-Actions-Jobs auf eigenen Runnern aus. Sie ändern runs-on auf craci, und die Läufe erscheinen weiterhin in GitHub. Während der Job läuft, beobachtet ein paketbewusster Proxy den Datenverkehr zu den Paketquellen, sodass die SBOM aufzeichnet, was der Build tatsächlich geladen hat, einschließlich transitiver Abhängigkeiten. Die Abhängigkeitsnachweise reisen mit CI-Caches mit, sodass ein aus einem Cache wiederhergestelltes Paket in der Aufzeichnung bleibt.

• Ökosysteme: npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk und Git-Quellen, dazu Download-Presets.
• Vollständigkeit: Jeder Job und jeder Cache wird als Complete, Complete with connections, Incomplete, Unavailable oder Not recorded gekennzeichnet, sodass Unbekanntes ausgewiesen statt aufgefüllt wird.
• Formate: CycloneDX und SPDX, mit deklarierten Lizenzmetadaten im Export.
• Provenienz: Die API liefert SBOMs, Netzwerk-Traces und Provenienz.

CRACI automatisiert einen wesentlichen Teil der Transparenz und Nachweise zur Lieferkette, die ein umfassenderer CRA-Compliance-Prozess braucht. Allein macht es ein Produkt nicht konform. SBOM-Generierung während des Builds behandelt die Details, unser CRA-Überblick den Zeitplan.

Wo KI bei SBOMs hilft

Sobald Sie eine aufgezeichnete SBOM haben, kann ein Modell gut damit arbeiten: zusammenfassen, welche Komponenten Risiken tragen, ein Advisory verständlich erklären oder die Dokumentation dazu für die Prüfung durch einen Menschen entwerfen. Die Regel ist einfach: Lassen Sie den Build die Aufzeichnung erzeugen, und lassen Sie das Modell sie lesen.