SBOM und Cyber Resilience Act: Die Stückliste als Gate für Coding Agents

Der Cyber Resilience Act (CRA) verlangt ab dem 11.12.2027 von Herstellern vernetzter Produkte, im Gesetz Produkte mit digitalen Elementen, eine Stückliste ihrer Software, die SBOM. Coding Agents schreiben inzwischen einen Teil der Pull Requests, die diese Stückliste verändern. Was eine einzige neue Zeile im Manifest anrichten kann, zeigte im Juni 2026 der Fall Mastra.

Eine neue Zeile im Manifest: der Fall Mastra

Laut Microsofts Bericht zur Mastra-Kompromittierung vom 17. Juni 2026 wurden am 16. und 17. Juni 2026 über 140 npm-Pakete des KI-Agent-Frameworks Mastra vergiftet. Die Angreifer kamen über das ruhende Konto eines früheren Mitwirkenden hinein. Geändert haben sie nur eine Stelle: Die Pakete bekamen eine neue Abhängigkeit namens easy-day-js, einen Typosquat der verbreiteten Datumsbibliothek dayjs.

Verraten hat sich der Angriff laut Microsoft durch die Art der Veröffentlichung. Version 1.13.1 wurde von Hand veröffentlicht, alle früheren Versionen über OIDC, also per Trusted Publishing aus der Pipeline. Microsoft schreibt den Angriff der Gruppe Sapphire Sleet zu.

Ein Coding Agent wird für den Vorfall nicht verantwortlich gemacht. Der Vorfall zeigt trotzdem, was ein Governance-Rahmen für KI-Coding-Agents bei der Lieferkette abdecken muss. Eine einzige Zeile im Manifest zieht einen ganzen Teilgraphen nach sich. Sichtbar wird das nur, wenn man zwei Stände vergleicht und prüft, woher ein Paket stammt.

Coding Agents können das Tempo erhöhen, in dem solche Zeilen entstehen. Deshalb gehört die SBOM in den Pull Request: aus dem Lockfile erzeugt, mit dem Stand des Zielbranches verglichen und nach Regeln zu Lizenz, Mindestalter und Provenance geprüft. Etwas Bösartiges erkennt auch eine solche SBOM nicht von selbst.

Was ist eine SBOM?

Eine SBOM (Software Bill of Materials, auf Deutsch Software-Stückliste) hält in maschinenlesbarer Form fest, aus welchen Komponenten ein Softwareprodukt besteht. Der Cyber Resilience Act definiert sie in Art. 3 Nr. 39 der Verordnung (EU) 2024/2847 als formale Aufzeichnung der Komponenten eines Produkts mit ihren Details und Lieferkettenbeziehungen.

Das folgende Beispiel im Format CycloneDX zeigt die SBOM-Felder für chardet 7.0.0. Die Lizenz stammt aus den PyPI-Metadaten dieser Version. Eine vollständige SBOM nach BSI TR-03183-2 ist das nicht:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "type": "library",
      "name": "chardet",
      "version": "7.0.0",
      "licenses": [{ "license": { "id": "MIT" } }],
      "purl": "pkg:pypi/chardet@7.0.0"
    }
  ]
}

Der purl (Package URL) fasst Ökosystem, Name und Version in einer Kennung zusammen, hier pkg:pypi/chardet@7.0.0. Die BSI-TR führt ihn als zusätzliche Kennung, sofern vorhanden. Auf Name, Version und Lizenz schaut später das Gate: Der Diff zeigt neue und geänderte Komponenten, die Lizenzregel prüft deren Lizenz gegen die Freigabeliste.

SBOM und AI-BOM sind nicht dasselbe. Eine AI-BOM beschreibt vor allem Modelle und Trainingsdaten. Hier geht es um Pakete, die ein Coding Agent als Abhängigkeit einträgt.

Drei Dateien werden gern verwechselt. Das Manifest (package.json, pyproject.toml) nennt die direkten Abhängigkeiten, meist mit Versionsbereichen. Das Lockfile (package-lock.json, uv.lock) hält fest, welche Versionen der Paketmanager tatsächlich aufgelöst hat, einschließlich der transitiven Abhängigkeiten, die eine direkte Abhängigkeit selbst mitbringt. Die SBOM beschreibt dieses Ergebnis in einem standardisierten Format mit Lizenz und Identifikator.

Der Manifest-Diff zeigt nur die neue Zeile. Was sie an transitiven Paketen nachzieht, steht erst im Lockfile und in der daraus erzeugten SBOM.

SBOM-Pflicht nach dem Cyber Resilience Act: was gilt und ab wann

Dieser Abschnitt ist kein Rechtsrat. Er paraphrasiert die Verordnung (EU) 2024/2847, den Cyber Resilience Act (CRA), nach dem Stand vom September 2026. Die Artikelnummer nennt jeweils die Fundstelle.

Wer als Hersteller gilt

Hersteller ist nach Art. 3 Nr. 13, wer ein Produkt mit digitalen Elementen entwickelt oder entwickeln lässt und unter eigenem Namen oder eigener Marke vermarktet, entgeltlich oder unentgeltlich. Ein Maschinenbauer, der eine vernetzte Anlage oder deren Firmware unter eigenem Namen liefert, fällt darunter. Maschinen sind nicht ausgenommen, der CRA gilt neben der Maschinenverordnung (EU) 2023/1230.

Die Ausnahmen in Art. 2 Abs. 2 bis 4 sind eng gefasst. Typgenehmigte Fahrzeuge und Medizinprodukte unter MDR und IVDR sind ausgenommen. Nach den nicht verbindlichen Leitlinien der Kommission C(2026) 5252 ist eine Automotive-Komponente aber nur dann ausgenommen, wenn sie ausschließlich für den Einbau in Fahrzeuge konstruiert ist. Wird sie über offene Kanäle verkauft, fällt sie laut den Leitlinien unabhängig von Zweckangaben unter den CRA. Wie Coding Agents in diese Welt passen, steht im Beitrag zu Coding Agents unter ASPICE und ISO 26262.

Was die SBOM abdecken muss, und wer sie zu sehen bekommt

Anhang I Teil II Nr. 1 verlangt eine SBOM in einem gängigen, maschinenlesbaren Format, die mindestens die Top-Level-Abhängigkeiten erfasst. Eine rekursive Auflösung bis ins Lockfile schreibt der Verordnungstext nicht vor. Die SBOM gehört nach Anhang VII Nr. 2 lit. b zur technischen Dokumentation und ist nach Anhang VII Nr. 8 der Marktüberwachungsbehörde auf deren begründetes Verlangen vorzulegen.

Veröffentlichen muss der Hersteller sie nicht, das stellt Erwägungsgrund 77 klar. Auch ein verbindliches Format fehlt: Art. 13 Abs. 24 erlaubt der Kommission, Format und Elemente per Durchführungsrechtsakt festzulegen. Ein solcher Rechtsakt oder ein veröffentlichter Entwurf war mit Stand September 2026 nicht zu finden.

Rund um die Stückliste gelten weitere Pflichten. Art. 13 Abs. 5 verlangt Sorgfalt beim Einbau fremder Komponenten, ausdrücklich auch bei nicht kommerzieller Open Source. Findet der Hersteller dort eine Schwachstelle, meldet er sie nach Art. 13 Abs. 6 dem Maintainer. Der Supportzeitraum beträgt grundsätzlich mindestens fünf Jahre. Nur bei kürzerer erwarteter Nutzungsdauer darf er kürzer sein (Art. 13 Abs. 8). Technische Dokumentation und Konformitätserklärung sind ab Inverkehrbringen mindestens zehn Jahre aufzubewahren, bei längerem Support für dessen Dauer (Art. 13 Abs. 13).

Verstöße gegen Anhang I oder die Art. 13 und 14 können nach Art. 64 bis zu 15 Mio. Euro oder 2,5 Prozent des weltweiten Jahresumsatzes kosten.

Keine dieser Vorschriften fragt, ob ein Mensch oder ein Coding Agent den Code geschrieben hat. Die Pflicht gilt pro Produkt und Version, nicht pro Pull Request. Ein SBOM-Gate im PR ist deshalb gute Engineering-Praxis und ein belastbarer Weg, die Pflicht zu erfüllen, aber selbst keine Rechtspflicht.

Zwei Fristen, und eine läuft schon

Nach Art. 71 Abs. 2 gilt der CRA im Kern ab dem 11. Dezember 2027, damit auch die SBOM-Pflicht. Die Meldepflichten aus Art. 14 gelten dagegen seit dem 11. September 2026, und zwar auch für Produkte, die vor Dezember 2027 in Verkehr gebracht wurden (Art. 69 Abs. 3). Die übrigen Pflichten, auch die SBOM-Pflicht, greifen erst, wenn diese Altprodukte wesentlich geändert werden (Art. 69 Abs. 2).

Die Meldepflicht gilt seit dem 11.09.2026, auch für Produkte, die längst im Markt sind. Die SBOM-Pflicht kommt erst im Dezember 2027, bei Altprodukten nur nach einer wesentlichen Änderung.

Für eine aktiv ausgenutzte Schwachstelle im eigenen Produkt heißt das: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden (Art. 14 Abs. 2 lit. a und b). Gemeldet wird über die Single Reporting Platform, die ENISA am 11. September 2026 im Anfangsbetrieb gestartet hat. Koordinierende Stelle für Hersteller mit Hauptniederlassung in Deutschland ist das BSI mit CERT-Bund, und laut BSI sind die Meldungen auf Englisch abzufassen. Wie ein Team die CRA-Meldepflicht praktisch umsetzt, beschreibt der Beitrag zu Incident Response für KI-generierten Code.

NIS2, KI-Verordnung und Produkthaftung

NIS2 setzt woanders an. Der CRA nimmt den Hersteller für sein Produkt in die Pflicht, NIS2 und das BSIG die Einrichtung für ihren Betrieb. Anlage 2 des BSIG nennt Hersteller von Maschinen, Elektronik, Fahrzeugteilen und Medizinprodukten. Für sie können also beide Regelwerke zugleich gelten. Medizinprodukte unter MDR oder IVDR sind vom CRA ausgenommen. Ihr Hersteller kann aber als Einrichtung unter NIS2 fallen. Mehr dazu im Beitrag zu NIS2 und Coding Agents.

Hier geht es um die Herstellerpflichten des CRA. Was die KI-Verordnung für Coding Agents verlangt, steht im Beitrag zu Rollen und Fristen der KI-Verordnung für Coding Agents. Die Produkthaftung für Software und eingebaute Komponenten behandelt der Beitrag Urheberrecht an KI-generiertem Code.

Warum ein Manifest-Diff für den Abhängigkeitsgraphen nicht reicht

Die einzige Messung zur Frage, wie oft Agenten neue Pakete einbauen, spricht gegen die bequeme These. Twist und Zhang haben für die MSR '26 insgesamt 26.760 Pull Requests von Coding Agents ausgewertet. Nur 1,3 Prozent davon fügten eine neue Abhängigkeit hinzu, und in 75 Prozent dieser Fälle nannte der Agent eine Version. Eine menschliche Vergleichsgruppe fehlt. Dass Agenten mehr oder riskantere Abhängigkeiten einbauen als Menschen, lässt sich damit nicht belegen.

Es kommt deshalb auf die Taktung an. Wo Agenten mehr Pull Requests öffnen und die Review-Kapazität des Teams nicht mitwächst, prüft derselbe Reviewer mehr Änderungen (warum hier der eigentliche Engpass liegt, zeigt der Beitrag Engpass Pull Request bei KI-Code-Review). Laut einem Preprint vom Juli 2026 gehört die Pflege von Abhängigkeiten sogar zu den häufigsten Aufgaben in Agent-PRs. Selbst bei kleiner Quote kommen dann regelmäßig neue Pakete in den Graphen, und der Reviewer prüft sie neben vielen anderen Diffs.

Im Manifest-Diff sieht er die Zeile in der package.json. Die transitiven Pakete stehen erst im Lockfile. Welche Lizenz ein Paket hat und seit wann es in der Registry liegt, zeigt der Manifest-Diff nicht. Wer nur den Manifest-Diff liest, muss jedes neue Paket einzeln nachschlagen. GitHubs Dependency Review nimmt ihm einen Teil davon ab und zeigt auch indirekte Pakete aus Lockfiles samt Release-Daten. Eine Regel zum Versionsalter bietet sie aber nicht (Stand: September 2026).

Wie schnell ein falscher Name Kreise zieht, beschreibt Aikido im Februar 2026. Der erfundene npm-Name react-codeshift stand in einem Commit mit 47 von einem Sprachmodell generierten Agent Skills und gelangte über Forks in 237 Repositories. Agenten versuchten täglich, das Paket zu installieren. Charlie Eriksen von Aikido registrierte den Namen vorsorglich selbst. Ein Angriff fand nicht statt.

Für diesen Mechanismus gibt es inzwischen einen Namen: Slopsquatting. Geprägt hat ihn Seth Larson von der Python Software Foundation, bekannt gemacht hat ihn Andrew Nesbitt im April 2025. Gemeint ist, dass jemand einen Paketnamen registriert, den Modelle erfinden. Beim Typosquatting setzt der Angreifer dagegen auf einen Tippfehler oder eine Verwechslung, wie bei easy-day-js im Fall Mastra.

Zahlen dazu liefern Spracklen et al. in einer Studie für USENIX Security 2025. In 576.000 Code-Beispielen von 16 Modellen erfanden kommerzielle Modelle mindestens 5,2 Prozent der Pakete, Open-Source-Modelle 21,7 Prozent. Getestet wurden aber direkt gepromptete Modelle aus den Jahren 2023 und 2024, ohne Agentenschleife. Auf heutige Coding Agents lassen sich diese Raten nicht übertragen. Ein bestätigter Angriff, der auf einem halluzinierten Paketnamen beruht, war mit Stand September 2026 nicht zu finden.

Was beim Installieren eines solchen Pakets auf dem Rechner ausgeführt wird, ist eine Frage der lokalen Sandbox für Coding Agents. Hier geht es um das, was am Ende im ausgelieferten Artefakt steckt. Genau das muss sichtbar werden, bevor jemand auf „Merge“ klickt.

SBOM erstellen im Pull Request: vom Dokument zum Gate

Technisch ist der erste Schritt überschaubar. Die folgende Strecke ist ein Bauplan, keine fertige Integration. Die CI erzeugt in jedem Pull Request eine SBOM aus dem Lockfile des PR-Stands und eine zweite aus dem Lockfile des Zielbranches, etwa mit syft im Format CycloneDX. cyclonedx-cli vergleicht beide mit cyclonedx diff <from> <to> (Version 0.33.1, Stand: September 2026). Der Diff listet neue, entfernte und in anderer Version aufgelöste Komponenten auf, sowohl transitive Pakete als auch direkte Abhängigkeiten aus dem Manifest.

Damit sieht der Reviewer, was die Änderung im aufgelösten Abhängigkeitsgraphen nachzieht. Ob die SBOM den ganzen Lieferumfang erfasst, belegt der Diff nicht. Ein Diff mit 40 neuen Komponenten ist eine Liste, keine Entscheidung. Zum Gate wird die SBOM erst, wenn Regeln sie auswerten und bei bestimmten Befunden den Merge anhalten.

Eine Stückliste zu erzeugen heißt noch nicht, sie auszuwerten. Im ENISA-Bericht „SBOM Adoption State of Play 2026“ (n = 334) beschreiben 44 Prozent der Befragten die Lücke zwischen Erzeugen und Nutzen von SBOMs als moderat, 23 Prozent als erheblich. Nur 7 Prozent haben sie geschlossen.

SBOM-Tools für die CI: wer erzeugt, wer vergleicht, wer prüft

Keines der geprüften Werkzeuge deckt die ganze Strecke ab. Die folgende Übersicht zeigt, was jedes davon im PR-Kontext leistet (Stand: September 2026):

Drei Regeln, die aus der Liste ein Gate machen

Lizenz. Eine neue Komponente mit einer Lizenz außerhalb der Freigabeliste hält den PR an. Das gilt auch, wenn ein bekanntes Paket bei einem Versionssprung seine Lizenz wechselt. Die Dependency Review Action 5.0.0 und Trivy 0.74.0 können das (Stand: September 2026).

Mindestalter. Ein Mindestalter begrenzt, wie früh das Team eine neu veröffentlichte Paketversion übernimmt. Es ist eine Wartefrist, kein Sicherheitsnachweis. Die Paketmanager bremsen beim Installieren: pnpm mit minimumReleaseAge seit 10.16.0, npm mit min-release-age seit 11.10.0, uv mit exclude-newer samt relativen Zeiträumen seit 0.9.17, pip mit --uploaded-prior-to seit 26.0. Dependabot kennt einen Cooldown für Versionsupdates, Sicherheitsupdates verzögert er nicht.

Ein Werkzeug, das einen beliebigen Pull Request, etwa den eines Coding Agents, zugleich auf neue Pakete, Lizenzen und Registry-Alter prüft, war mit Stand September 2026 nicht zu finden. Renovate setzt mit minimumReleaseAge einen Status-Check, aber nur für die Update-PRs, die es selbst öffnet. Die Einstellungen der Paketmanager greifen beim Installieren, Dependency-Track prüft erst auf dem Server, und der Dependency Review Action fehlt dafür ein Parameter. Das Gate lässt sich aus den Bausteinen zusammensetzen: Diff erzeugen, für jede neue oder in anderer Version aufgelöste Komponente das publishedAt dieser Version bei deps.dev abfragen, transitive Pakete eingeschlossen, und unterhalb der Schwelle anhalten. Fehlt das Datum oder scheitert die Abfrage, entscheidet ein Mensch. Als bestanden gilt die Prüfung dann nicht.

Provenance. npm bietet seit dem 31.07.2025 Trusted Publishing per OIDC mit automatischer Provenance an. Im Fall Mastra fiel laut Microsoft auf, dass eine Version anders veröffentlicht wurde als ihre Vorgänger. Die Regel für npm-Pakete: Hat die Basisversion Provenance, die neue Version aber nicht, hält das Gate den PR an. Bei einem neu aufgenommenen Paket gibt es keine Basisversion. Fehlt sie oder lässt sich die Provenance nicht prüfen, entscheidet ein Mensch, wie beim fehlenden Veröffentlichungsdatum.

Anhalten heißt: ein Mensch schaut hin

Das Gate soll nicht kommentarlos blockieren und erst recht nicht kommentarlos durchlassen. Wenn eine Regel anschlägt, erhält ein Mensch den konkreten Befund: Paket, Lizenz, Versionsalter und vorhandene oder fehlende Provenance.

Die Stückliste wird erst durch Regeln zum Gate. Schlägt eine Regel an oder fehlt ein Datum, entscheidet ein Mensch anhand des konkreten Befunds.

Ein schematisches Beispiel: Das Team hat ein Mindestalter von sieben Tagen festgelegt. Ein PR bringt eine Paketversion mit, die vor zwei Tagen erschienen ist. Ihre Lizenz steht auf der Freigabeliste. Das Gate hält den Merge wegen des Alters an. Der Kommentar im PR nennt Paket, Version, Veröffentlichungsdatum, Prüfzeitpunkt und die verletzte Regel. Die Werte sind keine Empfehlung.

Der SBOM-Diff ist damit ein deterministischer Prüfer im Sinne eines Verifier-Harness. Er liefert bei gleichen Eingaben das gleiche Ergebnis, egal ob ein Agent oder ein Mensch die Zeile ins Manifest geschrieben hat. Zu den Eingaben gehören beide Lockfiles, Generatorversion, Konfiguration und das Regelwerk. Alters- und Provenance-Regeln hängen zusätzlich vom Prüfzeitpunkt und von den Registry-Antworten ab. Wer beide erzeugten SBOMs, Prüfzeitpunkt und Registry-Antworten zum Befund ablegt, kann später nachvollziehen, warum das Gate angehalten oder durchgelassen hat.

Was davon in die technische Dokumentation gehört

Die SBOMs aus den Pull Requests sind Arbeitsmaterial. In die technische Dokumentation gehört die SBOM der ausgelieferten Version. Die BSI TR-03183-2 verlangt je Softwareversion eine eigene SBOM mit rekursiv aufgelösten Abhängigkeiten. Verbindlich ist sie nicht. Wer im Release-Job ohnehin eine SBOM aus dem Lockfile erzeugt, legt sie in der technischen Dokumentation ab. Vorher muss das Team prüfen, ob sie den Lieferumfang tatsächlich erfasst: In einer Studie für die DSN 2024 ließen alle vier untersuchten Generatoren Abhängigkeiten aus. Laut einem Preprint vom Juni 2026 übersehen die Werkzeuge Einbindungen im Build und zur Laufzeit fast vollständig, das trifft vor allem C/C++ und direkt übernommenen Fremdcode. Wer sich an der TR orientiert, prüft zusätzlich deren Pflichtfelder, darunter den SHA-512-Hash und die drei Eigenschaften je Komponente (ausführbar, Archiv, strukturiert).

CycloneDX vs. SPDX: welches SBOM-Format sich für die CI eignet

Wer die SBOM mit syft erzeugt, fährt mit CycloneDX am einfachsten: Die Standardausgabe CycloneDX 1.6 liegt genau auf der Untergrenze der BSI TR-03183-2, SPDX 3 gibt syft nicht aus. Der GitHub-SBOM-Export liefert nur SPDX 2.3. Für die Formatvorgabe der TR reicht er allein nicht, dafür braucht es einen anderen Generator (Stand: September 2026). SPDX ist dabei nicht das schlechtere Format.

In Deutschland setzt die BSI TR-03183-2 den Maßstab, aktuell in Version 2.1.0 vom 20.08.2025. Sie akzeptiert CycloneDX ab 1.6 und SPDX ab 3.0.1, jeweils als JSON oder XML. Eine Konformitätsvermutung begründet sie nicht, in der Praxis gilt sie trotzdem als Referenz.

Auf dem Papier erfüllen beide Formate diese Vorgabe. Die Werkzeuge unterstützen sie allerdings unterschiedlich gut (Stand: September 2026):

Bei SPDX bleiben GitHub-Export und syft damit unter der Mindestversion der TR. Die Standardausgabe von syft, CycloneDX 1.6, liegt dagegen genau auf der Untergrenze. Wer SPDX 3.0.1 braucht, muss einen Generator wie cdxgen einsetzen, der es laut README exportiert.

Für beide Formate gilt dieselbe Grenze: Schwachstellen gehören laut TR nicht in die SBOM. Ob eine bekannte Lücke in einem Produkt ausnutzbar ist, steht in einem eigenen Dokument: VEX. Das BSI regelt es als CSAF-Profil in TR-03183-3. Die SBOM hält nur fest, welche Komponenten im Produkt stecken.

Was die SBOM nicht zeigt, und was bis Dezember 2027 zu tun bleibt

Am 04.03.2026 erschien chardet 7.0.0. Im PyPI-Eintrag wechselte das Lizenzfeld von LGPL-2.1-or-later auf MIT. Laut Release-Notes ist 7.0.0 eine Neuimplementierung, rund 600 Commits im Repository tragen den Trailer „Co-Authored-By: Claude“. Eine SBOM bildet den Sprung sauber ab: derselbe Paketname im purl (pkg:pypi/chardet), neue Version, neue Hashes, neues Lizenzfeld. Dass diese Commits einen Claude-Trailer tragen, zeigt sie nicht.

Den Lizenzstreit bildet die SBOM nicht ab. Am selben Tag bestritt Issue #327 das Recht zur Neulizenzierung. Die Release-Notes zu 7.3.0 vom 24.03.2026 erklären zudem alle früheren 7.x-Versionen rückwirkend zu 0BSD, die PyPI-Metadaten von 7.0.0 nennen weiter MIT. Eine SBOM gibt solche Lizenzangaben wieder. Ob 7.x ein abgeleitetes Werk ist, entscheidet kein Lizenzfeld. Die rechtliche Seite behandelt der Beitrag Urheberrecht an KI-generiertem Code.

Ein Lizenz-Gate erkennt den Wechsel, lässt ihn aber meist zu, weil MIT freizügiger ist als LGPL. Die SBOM meldet die Änderung. Die Bewertung bleibt beim Menschen.

Bei Schadcode ist die Grenze noch enger. Laut NVD steckte der Code, der die xz-Hintertür (CVE-2024-3094) aktivierte, nur in den Release-Tarballs, nicht im Git-Repository. Eine SBOM hätte „xz 5.6.1“ korrekt gelistet. Mit gestohlenen Tokens veröffentlichte Shai-Hulud laut CISA vergiftete Versionen legitimer Pakete. Im SBOM-Diff erscheint das als gewöhnliches Versions-Update. Geschützt haben dort Lockfiles, Pinning und Wartefristen, also die Mindestalter-Regel, nicht die Stückliste.

Die dritte Lücke betrifft die Agent-Konfiguration selbst. Der keyv-Wurm vom 04.08.2026 committete laut Wiz mit gestohlenen GitHub-Tokens Claude-Code-Hooks und .vscode/tasks.json in Repo-Branches. Die Payload läuft beim Öffnen des Repos, ein npm install ist nicht nötig. Kein Agent hat hier ein Paket eingebaut. Der Schadcode steckt in der Konfiguration, die Agent und Editor beim Öffnen des Repos ausführen. Ein Diff der Paketabhängigkeiten erfasst Änderungen an .claude/settings.json oder .vscode/tasks.json nicht. Für diese Dateien braucht es eigene Review-Regeln.

Stand September 2026: Der Meldeweg muss schon stehen. Die SBOM-Pflicht folgt am 11.12.2027. PR-Gate und Konfigurations-Review sind Engineering-Praxis, keine Rechtspflicht:

• Meldeweg prüfen. Wer die 24-Stunden-Frühwarnung über die ENISA-Meldeplattform abgibt, sollte feststehen.
• Herstellerrolle klären. Welche Produkte, auch Firmware, bringen Sie nach Art. 3 Nr. 13 unter eigenem Namen in Verkehr?
• SBOM je Produktversion ablegen. Maschinenlesbar, mindestens Top-Level, in der technischen Dokumentation, vorlegbar auf Verlangen.
• PR-Gate mit Regeln betreiben. Den Diff gegen die Basis mit den drei Regeln aus diesem Artikel prüfen.
• Agent-Konfiguration reviewen wie Code. Änderungen an .claude/ und .vscode/ gehören in denselben Review wie ein neues Paket.

Die SBOM in der technischen Dokumentation und das Gate im Pull Request haben unterschiedliche Aufgaben. Die eine hält den Komponentenstand des ausgelieferten Produkts fest. Das andere macht Änderungen vor dem Merge prüfbar. Wer die Zeile geschrieben hat, ändert an dieser Prüfung nichts.

Was ist eine SBOM?

Eine SBOM (Software Bill of Materials) ist eine maschinenlesbare Software-Stückliste mit Namen, Version, Lizenz und eindeutiger Kennung je Komponente (z. B. purl). Gängige Formate sind CycloneDX und SPDX.

Ist eine SBOM nach dem Cyber Resilience Act Pflicht?

Ja, für Hersteller von Produkten mit digitalen Elementen im Geltungsbereich des CRA ab dem 11.12.2027 (Art. 71 Abs. 2, Ausnahmen in Art. 2 Abs. 2 bis 4). Anhang I Teil II Nr. 1 verlangt mindestens die Top-Level-Abhängigkeiten in einem gängigen, maschinenlesbaren Format. Für Produkte, die vorher in Verkehr gebracht wurden, greift die Pflicht nur nach einer wesentlichen Änderung (Art. 69 Abs. 2). Eine SBOM pro Pull Request verlangt der CRA nicht, die Pflicht gilt pro Produkt und Version.

Muss die SBOM veröffentlicht werden?

Nein. Die SBOM gehört zur technischen Dokumentation (Anhang VII Nr. 2 lit. b) und ist der Marktüberwachung auf begründetes Verlangen vorzulegen. Eine Veröffentlichungspflicht besteht nicht (Erwägungsgrund 77).

CycloneDX oder SPDX: Welches Format passt?

CycloneDX ab 1.6 und SPDX ab 3.0.1 entsprechen der Formatvorgabe der BSI TR-03183-2 (v2.1.0). Das richtige Format allein erfüllt die TR noch nicht. Auch Pflichtfelder und Erfassungstiefe müssen stimmen. Die TR ist eine Empfehlung, nicht verbindlich. Mit syft ist CycloneDX 1.6 der naheliegende Weg, weil syft kein SPDX 3 liefert. Der GitHub-SBOM-Export liefert nur SPDX 2.3 und reicht für die TR allein nicht (Stand: September 2026).

Ab wann gilt der Cyber Resilience Act?

Im Kern ab dem 11.12.2027, damit auch die SBOM-Pflicht. Die Meldepflichten nach Art. 14 gelten schon seit dem 11.09.2026: Aktiv ausgenutzte Schwachstellen im eigenen Produkt erfordern binnen 24 Stunden eine Frühwarnung und binnen 72 Stunden eine Meldung über die ENISA-Plattform. Die Regeln zu Konformitätsbewertungsstellen (Kapitel IV) gelten seit dem 11.06.2026.

Was ist Slopsquatting?

Angreifer registrieren Paketnamen, die Sprachmodelle halluzinieren, und hoffen, dass generierter Code diese Pakete installiert. Seth Larson prägte den Begriff. Die bekannten Halluzinationsraten stammen aus Tests mit direkt geprompteten Modellen der Jahre 2023/24. Ein bestätigter Angriff war mit Stand September 2026 nicht zu finden.