Lieferkette und Open-Source unter dem Cyber Resilience Act

Problem in der Praxis

Moderne Produkte mit digitalen Elementen bestehen überwiegend aus zugekauften und quelloffenen Bestandteilen. Eigenentwicklung ist oft die Minderheit im Codebestand. Trotzdem fehlt vielen Organisationen ein belastbares Bild der eigenen Software-Lieferkette: Welche Bibliotheken, Frameworks, Firmware-Bestandteile und Dienste Dritter stecken im Produkt, in welcher Version, mit welcher Schwachstellenlage und mit welchem Pflege- und Lizenzstatus?

In der Praxis zeigt sich die Lücke spätestens, wenn eine ausgenutzte Schwachstelle in einer weit verbreiteten Open-Source-Komponente bekannt wird. Dann beginnt die Suche: Sind wir betroffen? In welchen Produktversionen? Gibt es einen Patch des Upstream-Projekts? Wer pflegt die Komponente überhaupt noch? Ohne durchgängige Komponentenübersicht wird aus einer technischen Frage eine wochenlange Rekonstruktion.

Hinzu kommt eine Erwartungsverwechslung: Viele Teams nehmen an, Open-Source sei vom CRA nicht erfasst oder dessen Sicherheit liege beim Upstream-Projekt. Beides greift zu kurz. Wer eine quelloffene Komponente in ein kommerzielles Produkt integriert, bleibt für dieses Produkt verantwortlich, unabhängig davon, woher der Code stammt.

CISO-Einordnung

Der CRA adressiert Wirtschaftsakteure mit abgestuften Pflichten: Hersteller als Hauptadressat, dazu Bevollmächtigte, Einführer und Händler. Wer ein bereits in Verkehr gebrachtes Produkt wesentlich verändert, kann selbst als Hersteller gelten und damit in die volle Pflichtenstellung rutschen. Für die Lieferkette folgt daraus: Integration und wesentliche Veränderung erzeugen Verantwortung.

Zwei Pflichten aus dem CRA bilden den Kern der Lieferkettensicherheit. Erstens die Due-Diligence-Pflicht des Herstellers für Drittkomponenten: Beim Einsatz fremder oder quelloffener Bestandteile muss der Hersteller sorgfältig prüfen, dass diese die Sicherheit des Gesamtprodukts nicht untergraben. Zweitens die Schwachstellenbehandlung über den gesamten Lebenszyklus nach Anhang I Teil II der Verordnung: das Identifizieren und Dokumentieren von Komponenten und Schwachstellen, einschließlich einer Software Bill of Materials (SBOM), zeitnahes Beheben durch Sicherheitsupdates, regelmäßige Tests und eine Coordinated-Vulnerability-Disclosure-Policy (CVD), verbunden mit einer Kontaktstelle für eingehende Schwachstellenmeldungen.

Für Open-Source führt der CRA eine eigene, gegenüber dem Hersteller deutlich abgeschwächte Rolle ein: den Open-Source-Software-Verwalter (open-source software steward). Nicht-kommerzielle Open-Source-Software außerhalb einer gewerblichen Tätigkeit ist nicht wie ein kommerzielles Produkt erfasst. Sobald quelloffene Software aber kommerziell bereitgestellt oder in ein kommerzielles Produkt integriert wird, greifen die Herstellerpflichten beim integrierenden Akteur. Die genaue Abgrenzung von Steward-Rolle und Herstellerpflicht ergibt sich aus dem Verordnungstext und ist im Einzelfall am Originaltext zu prüfen.

Die Schwachstellenbehandlung verlangt eine dauerhafte organisatorische Funktion. In der Praxis etablieren Hersteller hierfür typischerweise ein Product Security Incident Response Team (PSIRT), das CVD, Kontaktstelle und die Verteilung von Sicherheitsupdates über den Unterstützungszeitraum trägt. Dieser Unterstützungszeitraum (support period) orientiert sich an der erwarteten Nutzungsdauer; als Richtwert nennt der Regelungsrahmen in der Regel mindestens fünf Jahre.

Umsetzungsperspektive

Lieferkettensicherheit nach CRA lässt sich auf eine durchgängige Kette zurückführen: wissen, was drin ist; bewerten, was es bedeutet; reagieren, wenn etwas passiert; nachweisen, dass man gehandelt hat.

• Komponentenübersicht: Eine maschinenlesbare SBOM ist die Grundlage. Sie sollte aus dem Build-Prozess entstehen, nicht nachträglich gepflegt werden. Als Orientierung für Format und Inhalt dient die BSI TR-03183 Teil 2 mit Bezug auf etablierte Formate wie CycloneDX und SPDX.
• Due Diligence bei Auswahl und Bezug: Komponenten Dritter und Open-Source-Bestandteile werden vor Aufnahme bewertet, nicht erst im Vorfall. Kriterien sind Pflegezustand des Upstream-Projekts, Reaktionsfähigkeit bei Schwachstellen, Update-Mechanismen und Lizenzlage.
• Vertragliche Verankerung in der kommerziellen Lieferkette: Bei zugekauften Komponenten gehören SBOM-Lieferung, Schwachstelleninformation, Patch-Bereitstellung und Support-Zeiträume in die Lieferanten- und Einkaufsanforderungen. Bei reiner Open-Source ohne Vertragspartner ersetzt dies eine eigene Pflege- und Patch-Strategie.
• Schwachstellen- und Update-Prozess: SBOM-Bestände werden kontinuierlich gegen Schwachstellenquellen abgeglichen, betroffene Produktversionen identifiziert und Sicherheitsupdates über den Unterstützungszeitraum bereitgestellt.
• Meldefähigkeit: Der Prozess muss die gesetzlichen Fristen tragen. Bei aktiv ausgenutzten Schwachstellen und schwerwiegenden Sicherheitsvorfällen gelten gestaffelte Meldungen an das zuständige nationale CSIRT und ENISA: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht bei Schwachstellen binnen 14 Tagen, bei schwerwiegenden Vorfällen binnen eines Monats. Die Meldepflichten gelten ab dem 11.09.2026.

Prozessuale Anker liefern die BSI TR-03183 als Orientierungshilfe zum CRA sowie etablierte Frameworks für sichere Softwareentwicklung. Das NIST Secure Software Development Framework (SP 800-218) und die IEC-62443-Reihe (insbesondere 62443-4-1 für den sicheren Entwicklungsprozess und 62443-4-2 für Komponentenanforderungen) lassen sich gut auf die CRA-Anforderungen zur Schwachstellenbehandlung und auf SBOM abbilden. Die IEC-62443-Reihe gilt zugleich als wichtiger Kandidat für harmonisierte Normen mit Vermutungswirkung; deren Stand ist vor verbindlicher Nutzung zu prüfen.

Typische Fehler

1. Open-Source wird pauschal als nicht CRA-relevant eingestuft, obwohl es kommerziell integriert wird.
2. Eine SBOM wird einmalig für ein Audit erzeugt und danach nicht mit jedem Build aktualisiert.
3. Due Diligence beschränkt sich auf Lizenzprüfung und ignoriert Pflegezustand und Schwachstellenhistorie der Komponente.
4. Verantwortung wird auf Upstream-Projekte abgewälzt, die keinerlei vertragliche oder gesetzliche Pflicht gegenüber dem Integrator haben.
5. Lieferantenverträge regeln Funktion und Preis, aber nicht SBOM, Schwachstelleninformation, Patch-Zeiten und Support-Ende.
6. Der Schwachstellenprozess ist nicht so aufgesetzt, dass er die 24/72-Stunden-Meldelogik tatsächlich tragen kann.

Risiken und Trade-offs

Vollständige Transparenz über die Lieferkette ist aufwändig und nie endgültig: Komponenten ändern sich mit jedem Release, transitive Abhängigkeiten vervielfachen die Fläche. Eine SBOM schafft Sichtbarkeit, erzeugt aber auch Pflegeaufwand und legt Schwachstellen offen, auf die dann reagiert werden muss. Das ist gewollt, kostet aber Kapazität.

Bei Open-Source besteht ein struktureller Trade-off zwischen Nutzen und Kontrolle. Quelloffene Komponenten beschleunigen Entwicklung, können aber unterpflegt sein. Der Integrator trägt die Verantwortung, ohne den Upstream steuern zu können. Optionen sind eigene Pflege, Forking, Wechsel der Komponente oder kommerzieller Support, jeweils mit Kosten und Bindung.

Ein weiterer Trade-off liegt zwischen vertraglicher Absicherung und Marktrealität. Nicht jeder Lieferant akzeptiert CRA-orientierte Sicherheitsanforderungen, und nicht jede strategisch nötige Komponente hat einen Vertragspartner. Der CISO muss entscheiden, wo vertragliche Absicherung möglich ist und wo Eigenleistung die einzige Option bleibt.

Entscheidungspunkte

• Welche Produkte und welche Komponenten Dritter bzw. Open-Source-Bestandteile fallen voraussichtlich in den Anwendungsbereich, und wo entsteht durch Integration oder wesentliche Veränderung Herstellerverantwortung?
• Wie und ab wann wird die SBOM verbindlich aus dem Build-Prozess erzeugt und gepflegt?
• Nach welchen Kriterien werden Komponenten Dritter und Open-Source ausgewählt, zugelassen und regelmäßig neu bewertet?
• Welche Sicherheitsanforderungen werden vertraglich gegenüber kommerziellen Lieferanten durchgesetzt, und wie wird der nicht vertraglich gebundene Open-Source-Anteil abgesichert?
• Ist der Schwachstellen- und Meldeprozess so aufgestellt, dass die gesetzlichen Fristen ab dem 11.09.2026 eingehalten werden können?
• Wie werden CRA-Produktpflichten und NIS2-Lieferkettenpflichten organisatorisch verzahnt, ohne doppelte Strukturen zu schaffen?

Praktische Empfehlungen

1. Bauen Sie die SBOM in die Build-Pipeline ein, sodass jede Produktversion eine aktuelle, maschinenlesbare Stückliste hat. Orientieren Sie sich an BSI TR-03183 Teil 2.
2. Richten Sie eine Komponenten-Governance ein: Auswahlkriterien, Freigabe, periodische Neubewertung und einen klaren Umgang mit unterpflegten Open-Source-Bestandteilen.
3. Verankern Sie SBOM-Lieferung, Schwachstelleninformation, Patch-Bereitstellung und Support-Ende verbindlich in Lieferanten- und Einkaufsanforderungen.
4. Etablieren Sie eine dauerhafte Schwachstellenfunktion (typischerweise PSIRT) mit Kontaktstelle, CVD-Policy und Update-Verteilung über den Unterstützungszeitraum.
5. Testen Sie den Meldeprozess gegen die 24/72-Stunden-Logik, bevor er real gebraucht wird, und definieren Sie Schnittstellen zu CSIRT und ENISA.
6. Verbinden Sie CRA-Produktverantwortung und NIS2-Lieferkettensicherheit über gemeinsame Komponenten- und Lieferantendaten, halten Sie die getrennten Meldewege aber sauber auseinander.

Relevante Normreferenzen

• Cyber Resilience Act, Verordnung (EU) 2024/2847: maßgeblicher Rechtsakt für Produkte mit digitalen Elementen; unmittelbar in allen Mitgliedstaaten geltend, Vollanwendung ab 11.12.2027, Meldepflichten ab 11.09.2026. Für verbindliche Pflichten und Fristen ist der Verordnungstext einschließlich Anhänge maßgeblich.
• BSI TR-03183 (Cyber-Resilienz-Anforderungen an Hersteller und Produkte): frei zugängliche Orientierungs- und Umsetzungshilfe zum CRA, nicht rechtsverbindlich und ohne Vermutungswirkung; Teil 2 behandelt SBOM. Versionsstand vor Nutzung prüfen.
• IEC 62443 (insbesondere 62443-4-1 und 62443-4-2): Referenz für sicheren Produktentwicklungsprozess und Komponentenanforderungen; wichtiger Kandidat für harmonisierte Normen, Stand zu prüfen.
• NIST SP 800-218 (Secure Software Development Framework, SSDF): prozessuale Referenz für sichere Softwareentwicklung und SBOM (Public Domain).
• ISO/IEC 27001 und 27002: organisatorischer Bezugsrahmen für sicheren Entwicklungslebenszyklus und Schwachstellenbehandlung (Referenz, keine Wiedergabe von Inhalten oder Nummerierungen).
• NIS2, Richtlinie (EU) 2022/2555: organisationsbezogene Lieferkettensicherheit (Art. 21); komplementär zum produktbezogenen CRA, getrennte Meldewege.