Ergibt eine CRA-SBOM-Checkliste schon eine Lizenzseite?

Produktteams sollten die Jahre 2026 bis 2027 nutzen, um einen Komponentenbestand, die SBOM-Erzeugung, Prozesse für Schwachstellen und getrennte Arbeitsabläufe für die Lizenzoffenlegung aufzubauen. Wer erst bei der Konformitätsbewertung feststellt, dass ein geprüfter Nachweis zu Drittanbieterlizenzen fehlt, gerät doppelt unter Zeitdruck.

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, Aktualisierungen und sichere Entwicklung. Produktsicherheit, PSIRT und Rechtsabteilung verantworten diese Arbeit. Die Lizenzkonformität umfasst Pflichten des geistigen Eigentums bei Drittanbietersoftware: Lizenzhinweise, Namensnennungen und Copyleft-Bedingungen. Dafür braucht es einen eigenen Arbeitsablauf mit menschlichen Prüfschritten.

Beides zu vermischen schafft trügerische Sicherheit. Ein Team kann eine interne CRA-Bereitschaftsprüfung mit SBOMs und Fristen für Sicherheitskorrekturen bestehen und trotzdem an der Anfrage eines Käufers nach Lizenzkonformität 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 verlangt, dass die Dokumentation während des gesamten Supportzeitraums aktualisiert wird, wenn sich Schwachstellen und Komponenten ändern. Dieselben Änderungen an Abhängigkeiten machen Lizenzaussagen falsch, wenn niemand erneut prüft, was ausgeliefert wurde.

In Teams arbeiten mehrere Personen laufend Paketaktualisierungen ein. Ohne erneuten Import und erneute Veröffentlichung bei jeder Version beschreiben sowohl Ihr CRA-SBOM als auch Ihre Lizenzoffenlegung das Produkt von gestern. Regulatorische Dokumentation und Nachweise für Käufer müssen mit der Codebasis Schritt halten.

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, Rechtsabteilung und Entwicklung: Bestand der Drittanbieterlizenzen, Prüfung, Publish-Gates, Offenlegungsexporte und 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.