Cyber Resilience Act: Warum Software‑Stückliste und Open‑Source‑Compliance zusammengehören

Mit dem Cyber Resilience Act (CRA) schafft die EU erstmals ein einheitliches, verbindliches Sicherheitsregime für Produkte mit digitalen Elementen. Was auf den ersten Blick wie ein klassisches Cybersecurity‑Thema wirkt, entpuppt sich in der Praxis als Zusammenspiel aus Technik, Organisation und Recht. Besonders deutlich wird das an zwei Kernelementen:der Software‑Stückliste (SBOM) und der Open‑Source‑Compliance.

Dieser Beitrag zeigt, warum beide Themen untrennbar miteinander verbunden sind – und weshalb Unternehmen sie künftig gemeinsam denken müssen.

1. Der CRA denkt Software als Lieferkette – nicht als Blackbox

Der CRA verpflichtet Hersteller dazu, Produkte mit digitalen Elementen über ihren gesamten Lebenszyklus hinweg sicher zu gestalten, Schwachstellen zu managen und Transparenz gegenüber Marktaufsicht und Kunden zu schaffen. Software wird dabei nicht isoliert betrachtet, sondern als Zusammensetzung vieler Komponenten, Bibliotheken und Abhängigkeiten .

Gerade moderne Software besteht zu einem erheblichen Teil aus Open‑Source‑Komponenten. Diese sind rechtlich erlaubt, aber weder „frei von Pflichten“ noch unsichtbar. Der CRA macht genau diese Abhängigkeiten sichtbar – und relevant.

2. Die Software‑Stückliste (SBOM) als zentrales Compliance‑Instrument

Die Software Bill of Materials (SBOM) ist das technische Herzstück dieser Transparenz. Sie beschreibt strukturiert, welche Software‑Bausteine in einem Produkt enthalten sind – inklusive Versionen, Herkunft und Abhängigkeiten.

Die Bedeutung der SBOM ergibt sich aus mehreren CRA‑Pflichten:

• Nachweis der Sorgfaltspflicht bei Entwicklung und Auswahl von Komponenten
• Unterstützung des Vulnerability‑Managements
• Ermöglichung von Marktüberwachung und Incident‑Reaktion
• Grundlage für Lizenz‑ und Rechtskonformität

Die BSI‑Technische Richtlinie TR‑03183 konkretisiert, wie eine SBOM aussehen muss, welche Mindestinhalte erforderlich sind und welche Formate (z. B. CycloneDX) akzeptiert werden .

Wichtig: Eine SBOM ist kein „Nice‑to‑have“, sondern faktisch der Beweis, dass ein Hersteller seine Software kennt.

3. Open Source im CRA: erlaubt – aber nicht folgenlos

Der CRA ist ausdrücklich Open‑Source‑freundlich. Reine Open‑Source‑Software, die nicht im Rahmen einer kommerziellen Tätigkeit bereitgestellt wird, fällt grundsätzlich nicht unter den Anwendungsbereich. Anders sieht es aus, wenn Open Source Bestandteil eines kommerziellen Produkts ist.

Dann gilt:

• Die CRA‑Pflichten treffen den Hersteller des Gesamtprodukts
• Open‑Source‑Komponenten gelten als integrierte Softwarebestandteile
• Sicherheitsmängel und Lizenzverstöße wirken durch auf das Produkt

Damit wird Open Source rechtlich nicht gefährlich – aber sichtbar und prüfbar.

4. Warum SBOM und Open‑Source‑Compliance zusammengehören

In der Praxis zeigt sich schnell:Ohne SBOM keine Open‑Source‑Compliance.

Denn Open‑Source‑Compliance bedeutet unter anderem:

• Kenntnis aller eingesetzten Open‑Source‑Komponenten
• Prüfung der jeweiligen Lizenzpflichten (z. B. Copyleft, Notices, Source‑Code‑Bereitstellung)
• Sicherstellung, dass diese Pflichten im Produkt erfüllt werden

Genau diese Informationen liefert die SBOM. Sie wird damit zur Schnittstelle zwischen Technik und Recht.

Die CRA‑Logik ist dabei klar:

Wer seine Software sicher beherrschen will, muss wissen, was drin ist – technisch wie rechtlich.

5. Praktisches Beispiel: Sicherheitslücke trifft Lizenzpflicht

Ein typisches Szenario aus der Praxis:

• Eine kritische Schwachstelle wird in einer Open‑Source‑Bibliothek bekannt
• Die Bibliothek ist Teil eines CE‑kennzeichnungspflichtigen Produkts
• Der Hersteller muss:
  • prüfen, ob sein Produkt betroffen ist
  • ein Update bereitstellen
  • die Marktaufsicht ggf. informieren

Ohne SBOM ist diese Prüfung kaum möglich.Ohne Open‑Source‑Compliance droht zusätzlich ein Lizenzverstoß, etwa wenn beim Update Lizenzhinweise fehlen oder Pflichten verletzt werden .

6. Governance statt Einzelmaßnahmen

Der CRA zwingt Unternehmen dazu, SBOM und Open‑Source‑Compliance nicht isoliert, sondern als Teil einer ganzheitlichen Governance zu etablieren:

• Development: Erfassung von Abhängigkeiten „by design“
• Security: Nutzung der SBOM für Vulnerability‑Management
• Legal/Compliance: Lizenzprüfung auf Basis derselben Daten
• Management: Nachweis der organisatorischen Sorgfalt

Die europäische Leitlinie zur Anwendung des CRA macht deutlich, dass genau diese Prozess‑ und Organisationssicht erwartet wird – nicht bloß formale Dokumente .

7. Fazit: Die SBOM ist der gemeinsame Nenner

Der Cyber Resilience Act verändert nicht nur Sicherheitsanforderungen, sondern auch die Art, wie Software rechtlich bewertet wird.

• Die SBOM schafft Transparenz
• Open‑Source‑Compliance nutzt diese Transparenz
• Der CRA verbindet beides zu einer einheitlichen Pflicht zur Beherrschung der Software‑Lieferkette

Unternehmen, die SBOM und Open‑Source‑Compliance frühzeitig verzahnen, schaffen nicht nur Rechtssicherheit, sondern auch einen echten Wettbewerbsvorteil im europäischen Markt.

‍