Gibt Ihnen eine CRA-SBOM-Checkliste eine Lizenzseite?

Produktteams sollten 2026 bis 2027 als Zeitfenster nutzen, um Komponentenbestand, SBOM-Erzeugung, Schwachstellenprozesse und, getrennt davon, Workflows zur Lizenz-Offenlegung aufzubauen. Wer erst bei der Konformitätsbewertung feststellt, keinen geprüften Drittanbieter-Lizenznachweis zu haben, produziert doppelten Krisenmodus.

Zeitpläne variieren je nach Produktklasse und Durchführungsrechtsakten, und die Dokumentation muss über den gesamten Support-Zeitraum aktuell bleiben. Bestätigen Sie alle Termine mit Ihrem Rechtsbeistand; diese Seite ist keine Rechtsberatung.

Der Geltungsbereich richtet sich nach der Produkteinstufung, nicht nach der Unternehmensgröße: Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden, fallen in den Geltungsbereich, während Produkte, die bereits sektorspezifischen EU-Regeln unterliegen (Medizinprodukte, Kraftfahrzeuge, zivile Luftfahrt), sowie reine Cloud-Dienste ohne Produktbezug in der Regel ausgenommen sind. Installierbare Software, Firmware, vernetzte Geräte und viele kommerzielle Open-Source-Vertriebsmodelle können in den Geltungsbereich fallen, wenn sie in der EU verkauft werden.

Reine SaaS-Ausnahmen bestehen im allgemeinen Marktverständnis, erfordern aber eine produktspezifische rechtliche Prüfung.

Der CRA verlangt ein SBOM, deckt damit aber keine Lizenz-Offenlegung ab. Anhang I, Teil II verpflichtet Hersteller, Komponenten zu identifizieren und zu dokumentieren, einschließlich eines SBOM in einem gängigen, maschinenlesbaren Format, das mindestens die Abhängigkeiten oberster Ebene abdeckt. Das sind Komponentenidentitätsdaten, kein geprüfter Lizenztext.

Diese Pflicht beschleunigt die SBOM-Einführung bei allen in der EU verkaufenden Anbietern. Teams erzeugen CycloneDX oder SPDX aus der CI, oft zum ersten Mal, und übergeben die Dateien an Security oder Compliance. Das SBOM erfüllt die CRA-Komponentendokumentation. Es erzeugt nicht automatisch Hinweis, Namensnennung oder vollständigen Lizenztext für jede Komponente.

Die CRA-Cybersicherheitsdokumentation umfasst Risikobewertung, Schwachstellen, Updates und sichere Entwicklung. Produktsicherheit, PSIRT und Recht verantworten diese Arbeit. Lizenz-Compliance umfasst Pflichten des geistigen Eigentums bei Drittanbieter-Software: Hinweis, Namensnennung, Copyleft-Bedingungen. Ein anderer Workflow mit menschlichen Prüf-Gates.

Beides zu vermischen erzeugt trügerische Sicherheit. Ein Team kann eine interne CRA-Bereitschaftsprüfung mit SBOMs und Patch-SLAs bestehen und trotzdem an der Anfrage eines Käufers nach Lizenz-Compliance scheitern, weil niemand den Lizenztext geprüft hat.

• CRA-SBOM: Komponentenidentität für Sicherheits- und regulatorische Dokumentation.
• Lizenz-Offenlegung: Vollständiger Text und Namensnennung für Recht und Beschaffung.
• CRA: Meldung von Schwachstellen an Behörden unter festgelegten Bedingungen.
• Lizenz: Urheberrechts- und Verbreitungsbedingungen in OSS-Lizenzen.
• Derselbe Lockfile-Input, unterschiedliche Ergebnisse und unterschiedliche Verantwortliche.

Der CRA erwartet, dass die Dokumentation über den Support-Zeitraum aktualisiert wird, wenn sich Schwachstellen und Komponenten ändern. Dieselbe Abhängigkeits-Drift bricht Lizenzaussagen, wenn niemand erneut prüft, was ausgeliefert wurde.

Mehrköpfige Teams mergen fortlaufend Paket-Updates. Ohne erneuten Import und erneute Veröffentlichung bei jedem Release beschreiben sowohl Ihr CRA-SBOM als auch Ihre Lizenz-Offenlegung das Produkt von gestern. Regulatorische Dokumentation und käuferseitige Nachweise müssen sich mit der Codebasis mitbewegen.

Große Kunden ordnen die CRA-Position von Anbietern in ihre Lieferketten-Programme ein und fügen weiterhin Lizenzabschnitte aus Ausschreibungsvorlagen ein, die vor dem CRA entstanden. Sie verlangen SBOM plus Open-Source-Lizenzseite plus Attestierung, dass die Liste gepflegt wird.

CRA-geschulte Beschaffung wird dauerhaften Zugang zu Compliance-Artefakten erwarten. Das ersetzt nicht den Inhalt der Lizenz-Offenlegung. Es hebt die Messlatte dafür, wie aktuell und zugänglich Ihre Nachweise sein müssen.

Security-Organisation: SBOM-Erzeugung, Schwachstellenmanagement, Vorfallsmeldung, CRA-Konformitätsdaten, sichere Update-Auslieferung.

Compliance / Recht / Engineering-Ops: Drittanbieter-Lizenzbestand, Prüfung, Publish-Gates, Offenlegungs-Exporte, Antworten auf Käuferfragebögen.

Gemeinsamer Input: Lockfiles und SBOMs aus der CI. Unterschiedlicher Output: Security nutzt das SBOM für CVEs; Compliance nutzt denselben Import für geprüfte Lizenznachweise.