Was die Verordnung verlangt
Anhang I Teil II Nummer 1 der Verordnung (EU) 2024/2847: Die Hersteller müssen „Schwachstellen und Komponenten der Produkte mit digitalen Elementen ermitteln und dokumentieren, u. a. durch Erstellung einer Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen“. Das gilt ab dem 11. Dezember 2027 (Artikel 71).
- Die Software-Stückliste gehört zur technischen Dokumentation, mit den Verfahren zur Behandlung von Schwachstellen (Anhang VII Nummer 2 Buchstabe b).
- Sie geben sie einer Marktüberwachungsbehörde auf deren begründetes Verlangen (Anhang VII Nummer 8). Veröffentlichen müssen Sie sie nicht (Erwägungsgrund 77).
- Wenn Sie sie den Nutzern zugänglich machen, steht in den Informationen für Nutzer, wo (Anhang II Nummer 9).
- Die Kommission kann Format und Elemente durch einen Durchführungsrechtsakt festlegen (Artikel 13 Absatz 24). CycloneDX und SPDX sind gängige Formate.
Was diese Seite erstellt
Eine CycloneDX-1.6-JSON-Datei mit Ihrem Produkt als Hauptkomponente, jedem Paket mit seiner exakten Version und Paket-URL (purl) und den obersten Abhängigkeiten des Produkts, soweit die Lock-Datei sie angibt. Gelesen werden:
- npm package-lock.json (lockfileVersion 2 oder 3), Yarn yarn.lock (Yarn 1, 2 und neuer) und pnpm-lock.yaml (lockfileVersion 9.0); Pakete nur für die Entwicklung bleiben außen vor, wo die Datei sie angibt;
- Python requirements.txt mit fest gepinnter Version jedes Pakets (name==version), wie pip freeze oder pip-compile sie schreiben;
- Rust Cargo.lock, Version 3 oder 4, und Go go.mod, mit den indirekten Modulen;
- der Maven-Abhängigkeitsbaum, den mvn dependency:tree -DoutputFile schreibt, und Gradle gradle.lockfile; Pakete im Scope test bleiben außen vor;
- PHP Composer composer.lock, ohne packages-dev, und NuGet packages.lock.json.
Eine Datei, die ihrem Format nicht folgt, wird mit Zeile und Grund abgelehnt statt erraten. Ein Paket aus einer anderen Quelle als der öffentlichen Registry wird ohne Paket-URL aufgeführt, damit die Datei nie auf ein Paket verweist, das Sie nicht verwendet haben.
Sie haben schon eine Software-Stückliste aus einem anderen Werkzeug? Öffnen Sie sie als CycloneDX-JSON-Datei oder als SPDX-JSON-Datei, etwa die, die der Abhängigkeitsgraph von GitHub exportiert (Export SBOM), um ihre Komponenten auf OSV.dev und gegen den KEV-Katalog zu prüfen. Sie wird nur für die Prüfung gelesen: Für eine neue Stückliste öffnen Sie die Lock-Dateien. Wo keine Lock-Datei eine Version festlegt, nennt die Datei von GitHub einen Bereich wie ^4.17.0: Diese Komponenten werden als nicht geprüft aufgeführt; öffnen Sie die Lock-Datei, um sie zu prüfen.
Bekannte ausgenutzte Schwachstellen
Die Prüfung markiert jede auf OSV.dev gefundene Schwachstelle, deren CVE-Nummer im Katalog bekannter ausgenutzter Schwachstellen (KEV) der US-Behörde für Cybersicherheit und Infrastruktursicherheit (CISA) steht, mit dem Datum der Aufnahme. Die CISA nimmt eine Schwachstelle auf, sobald es zuverlässige Belege gibt, dass sie ausgenutzt wurde. Ab dem 11. September 2026 verlangt Artikel 14 der Cyberresilienz-Verordnung, eine aktiv ausgenutzte Schwachstelle in Ihrem Produkt (Artikel 3 Nummer 42) innerhalb von 24 Stunden zu melden, nachdem Sie davon Kenntnis erlangt haben. Ein KEV-Eintrag entscheidet das nicht für Ihr Produkt, zeigt aber, wo Sie zuerst hinsehen sollten; die Seite zu den Meldefristen zählt die Stunden.
Was sie nicht abdeckt
Die Software-Stückliste führt auf, was die Lock-Dateien aufführen. In das Produkt kopierter Code, Betriebssystempakete, Firmware und Bibliotheken in anderen Sprachen stehen nicht darin: Ergänzen Sie diese selbst. Die Schwachstellenprüfung nutzt OSV.dev, das nur veröffentlichte Schwachstellen führt; sie ersetzt nicht die Bewertung der Schwachstellen, die Anhang I Teil II verlangt.
Für die übrigen CRA-Unterlagen erstellt das CRA-Dokumentenpaket die technische Dokumentation und die EU-Konformitätserklärung. Auf der Seite zur Cyberresilienz-Verordnung prüfen Sie die Klasse Ihres Produkts.