CRA und Lieferketten: Pflichten mit Zulieferern

Die unterschätzte Haftungsfrage

Die meisten Hersteller unterschätzen, wie tief ihre Verantwortung in die Lieferkette reicht — und wie wenig ihre Zulieferer davon wissen.

Das ist keine Vermutung. In vielen Branchen sieht die Realität so aus: Lieferanten von Softwaremodulen, Embedded-Stacks oder IoT-Plattformkomponenten haben die CRA-Anforderungen bisher kaum im Blick. Sie liefern Komponenten, deren Sicherheitsarchitektur und Dokumentation weit unter dem CRA-Standard liegt — an Hersteller, die am Ende die Konformitätserklärung unterzeichnen und das CE-Zeichen anbringen. Das Risiko bleibt beim Hersteller hängen. Vollständig.

Dieser Abschnitt erklärt die rechtliche Grundlage, die praktischen Konsequenzen und was Hersteller heute konkret tun müssen, um ihre Lieferketten-Pflichten nach CRA zu erfüllen.

Rechtsgrundlage: Artikel 13 Absatz 5 CRA

Artikel 13 Absatz 5 des Cyber Resilience Act ist die entscheidende Norm für die Lieferkette:

„Hersteller, die wissen oder wissen müssten, dass die in ihre Produkte mit digitalen Elementen integrierten Komponenten oder Prozesse nicht konform mit den in dieser Verordnung festgelegten grundlegenden Cybersicherheitsanforderungen sind, dürfen diese Produkte nicht in Verkehr bringen oder bereitstellen.”¹

Die Aussage ist klar: Erfüllt eine Zuliefererkomponente die CRA-Anforderungen nicht, darf der Hersteller das fertige Produkt nicht vermarkten — es sei denn, er hat die Nichtkonformität behoben oder das Produkt entsprechend abgesichert.

Das ist der Punkt, den viele übersehen: Herausreden mit „ich hab’s nicht gewusst” funktioniert nicht. Hätte der Hersteller es durch angemessene Zulieferer-Audits oder Vertragspflichten wissen müssen, haftet er dennoch.

Ergänzend legt Anhang I, Teil I, Nr. 2 fest, dass Hersteller Prozesse einrichten müssen, um Schwachstellen in Drittkomponenten kontinuierlich zu überwachen. Das betrifft nicht nur Open-Source-Bibliotheken, sondern ausdrücklich auch kommerzielle Zuliefererkomponenten.¹

Was bedeutet „Lieferkette” im CRA-Kontext?

Der CRA verwendet den Begriff „Lieferkette” nicht im Sinne einer physischen Logistikkette, sondern im Sinne einer Software-Lieferkette: alle Komponenten, Bibliotheken, Module, Dienste und Prozesse, die zur Erstellung des Endprodukts beitragen.

Das umfasst konkret:

Kommerzielle Drittkomponenten:

• Zugekaufte Softwaremodule (z. B. Kommunikationsstacks, Protokoll-Bibliotheken, Kryptographie-Module)
• OEM-Software-Blöcke (z. B. ein Embedded-Betriebssystem eines anderen Herstellers)
• Cloud-Dienste, die in das Produkt integriert sind und vom Endkunden über das Produkt genutzt werden

Open-Source-Abhängigkeiten:

• Alle direkt genutzten Open-Source-Bibliotheken
• Transitive Abhängigkeiten (Bibliotheken, die von den direkt genutzten Bibliotheken abhängen)
• Open-Source-Betriebssystemkomponenten

Entwicklungs- und Build-Prozess-Abhängigkeiten:

• Compiler, Build-Tools, Toolchains
• CI/CD-Infrastruktur (in dem Maß, wie sie das fertige Produkt beeinflusst)

Was viele Maschinenbau-Unternehmen und Industrie-4.0-Anbieter massiv unterschätzen: wie viele transitive Abhängigkeiten in ihrer embedded Software stecken. Ein Hersteller von industriellen MQTT-Gateways baut vielleicht auf drei direkte Bibliotheken — dahinter liegen oft 40 bis 80 transitive Abhängigkeiten, von denen niemand weiß, wer sie pflegt. Das ist kein Randfall. Das ist der Normalzustand.

SBOM: Der Nachweis über die gesamte Lieferkette

Die Software Bill of Materials (SBOM) ist das zentrale Instrument, mit dem Hersteller nachweisen, dass sie ihre Lieferkette kennen und überwachen. Ohne vollständige SBOM ist eine CRA-konforme Lieferkettenkontrolle praktisch nicht möglich.

Was die SBOM für die Lieferkette leisten muss:

1. Vollständigkeit: Alle Drittkomponenten müssen erfasst sein — nicht nur die direkten, sondern auch transitive Abhängigkeiten. Eine SBOM, die nur die Top-Level-Pakete listet, ist nicht CRA-konform.
2. Maschinenlesbarkeit: Die SBOM muss in einem standardisierten Format vorliegen (CycloneDX oder SPDX).
3. Versionspräzision: Für jede Komponente müssen die exakten Versionsnummern angegeben sein — nicht nur Versionsbereiche.
4. Aktualität: Die SBOM muss bei jedem Release aktualisiert werden. Eine veraltete SBOM schützt nicht vor CVE-Risiken.
5. Schwachstellen-Matching: Auf Basis der SBOM müssen bekannte CVEs kontinuierlich abgeglichen werden.

Praktisches Vorgehen:

Für die automatisierte SBOM-Erstellung stehen quelloffene Tools zur Verfügung:

• Syft (OWASP): Analysiert Container-Images, Dateisysteme und Pakete; gibt CycloneDX und SPDX aus
• Trivy (Aqua Security): Kombiniert SBOM-Erstellung mit direktem CVE-Scan
• cdxgen: Spezialisiert auf Programmiersprachen-Ökosysteme (Java, Python, JavaScript, Go, Rust u. a.)

Für das laufende Schwachstellen-Tracking ist Dependency-Track (OWASP) ein etabliertes Open-Source-Werkzeug, das SBOM-Importe verwaltet und automatisch auf neue CVEs prüft.

Die SBOM-Pflicht nach CRA ist in Anhang I Teil I Nr. 2 und Anhang VII festgelegt. Eine ausführliche Anleitung zur SBOM-Erstellung finden Sie unter SBOM erstellen: Anleitung für CRA-Pflicht.

Vertragsgestaltung mit Zulieferern

Den Hersteller verpflichtet der CRA — nicht den Zulieferer. Aber der Hersteller muss sicherstellen, dass die eingesetzten Komponenten die Anforderungen des CRA erfüllen. Ohne vertragliche Absicherung gegenüber dem Zulieferer ist das ein erhebliches Risiko.

Was Hersteller von Zulieferern vertraglich einfordern sollten:

1. CRA-Konformitätszusicherung: Der Zulieferer erklärt, dass die gelieferte Komponente die grundlegenden Cybersicherheitsanforderungen aus Anhang I des CRA erfüllt und für den vorgesehenen Einsatzzweck geeignet ist.

2. SBOM-Bereitstellung: Der Zulieferer stellt für jede gelieferte Komponente eine vollständige SBOM im CycloneDX- oder SPDX-Format bereit und aktualisiert diese bei jeder neuen Version.

3. Schwachstellenkommunikation: Der Zulieferer teilt dem Hersteller unverzüglich mit, wenn in der gelieferten Komponente eine bekannte Schwachstelle entdeckt wird — mit Angabe des CVE, des Schweregrads und des Zeitplans für einen Patch.

4. Update- und Patch-Verpflichtung: Der Zulieferer stellt Sicherheits-Updates für mindestens 5 Jahre (oder für die Laufzeit des Produkts des Herstellers) kostenlos bereit — entsprechend den CRA-Vorgaben für Hersteller selbst.

5. Technische Dokumentation auf Anfrage: Der Zulieferer räumt dem Hersteller das Recht ein, Teile der technischen Dokumentation einzusehen oder an Marktaufsichtsbehörden weiterzuleiten, soweit dies zur CRA-Konformität des Endprodukts erforderlich ist.

Konkret bedeutet das: Ein IoT-Startup, das eine zugekaufte Bluetooth-Stack-Bibliothek für seine Sensorplattform verwendet, braucht vom Komponentenanbieter eine SBOM und eine schriftliche Schwachstellenmeldepflicht — sonst hat es beim nächsten kritischen CVE ein regulatorisches Problem, bevor es überhaupt einen Patch beantragen kann.

Praxis-Tipp: Viele Zulieferer werden diese Anforderungen zunächst ablehnen oder als unverhältnismäßig betrachten — insbesondere kleinere Anbieter. Hier hilft eine sachliche Erklärung: Diese Anforderungen entsprechen dem, was der CRA dem Hersteller selbst auferlegt. Ein Zulieferer, der keine SBOM oder Schwachstellenbenachrichtigungen bereitstellen will, ist ein regulatorisches Risiko. Kein Argument, das man gern hört. Aber es stimmt.

Open-Source-Abhängigkeiten in der Lieferkette

Open-Source-Komponenten sind ein Sonderfall in der CRA-Lieferkette. Sie stecken in den meisten Produkten mit digitalen Elementen — oft hunderte von Bibliotheken in einer einzigen Anwendung. Gleichzeitig tragen Open-Source-Maintainer keine Pflichten nach dem CRA (es sei denn, sie betreiben das Projekt kommerziell als „Open-Source-Steward”).¹

Was viele CRA-Berater nicht sagen: Das verschiebt die gesamte Verantwortung auf den Hersteller. Es gibt keinen Zulieferer, den man in die Pflicht nehmen kann. Wer eine ungepflegte Bibliothek einsetzt, sitzt allein auf dem Risiko.

Was das für Hersteller bedeutet:

Hersteller, die Open-Source-Komponenten verwenden, müssen selbst sicherstellen:

• Dass die genutzten Bibliotheken keine bekannten kritischen Schwachstellen enthalten (CVE-Monitoring)
• Dass veraltete, nicht mehr gepflegte Bibliotheken durch gepflegte Alternativen ersetzt werden
• Dass transitive Abhängigkeiten ebenso überwacht werden wie direkte
• Dass bei Entdeckung einer kritischen CVE in einer Open-Source-Komponente die CRA-Meldepflicht (Art. 14) ausgelöst werden kann — wenn die Schwachstelle aktiv ausgenutzt wird

Besondere Vorsicht bei:

• Langfristig ungepflegten Projekten (letzter Commit > 12 Monate, keine aktiven Maintainer)
• Komponenten mit bekannten, noch ungepatchten CVEs
• Sehr alten Versionen von Bibliotheken, für die keine Sicherheitsupdates mehr erscheinen

Der CRA schafft hier einen klaren Anreiz: Hersteller, die von Open-Source-Projekten abhängen, sollten diese entweder aktiv unterstützen (finanziell, durch Beiträge) oder aktiv nach Alternativen suchen. Ein Hersteller von embedded Software für Heizungssteuerungen, der eine bekannte, ungepflegte Bibliothek mit offenen CVEs in seiner SBOM führt und dieses Risiko nicht adressiert hat, steht gegenüber der Marktaufsicht vor einem ernsten Dokumentationsproblem. Kein theoretisches Szenario — das wird passieren.

Marktaufsicht und Lieferkette: Was Behörden prüfen werden

Prüft die Marktaufsichtsbehörde ein Produkt, fordert sie vollständige Einsicht in die technische Dokumentation — einschließlich SBOM und der Belege für das Schwachstellenmanagement. Konkret kann das bedeuten:

• Vorlage der aktuellen SBOM
• Nachweise, dass Hersteller die SBOM bei jedem Release aktualisiert haben
• Dokumentation, wie Hersteller CVE-Benachrichtigungen empfangen und bewertet haben
• Belege dafür, dass Hersteller Zulieferer auf Konformität geprüft haben (Verträge, Auditergebnisse, Konformitätszusicherungen)

Wer keine strukturierte Lieferkettenkontrolle nachweisen kann, hat auch dann ein Problem, wenn das fertige Produkt selbst gut abgesichert ist. Der CRA bewertet den Prozess, nicht nur das Ergebnis. Das klingt bürokratisch. Ist es auch. Aber es ist die Realität, auf die sich Hersteller heute vorbereiten müssen.

Checkliste: Lieferketten-Pflichten nach CRA

Die SBOM-Erstellung ist der erste und wichtigste Schritt — ohne vollständige SBOM ist keine der anderen Maßnahmen vollständig umsetzbar.

Starten Sie jetzt den kostenlosen CRA-Check, um zu prüfen, welche Lieferkettenpflichten konkret für Ihr Produkt gelten.

Quellen

1. EU-Verordnung 2024/2847 (Cyber Resilience Act), Artikel 13 Absatz 5, Artikel 14, Anhang I Teil I Nr. 2, Anhang VII: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402847
2. BSI — Software-Lieferkettensicherheit und CRA: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Cyber_Resilience_Act/
3. ENISA — Supply Chain Security Guidelines: https://www.enisa.europa.eu/topics/cyber-resilience-act
4. OWASP — CycloneDX Standard für SBOM: https://cyclonedx.org/
5. OWASP — Dependency-Track (SBOM-Verwaltung und CVE-Monitoring): https://dependencytrack.org/
6. Linux Foundation — SPDX Standard (ISO/IEC 5962:2021): https://spdx.dev/
7. OpenSSF — Securing the Software Supply Chain: https://openssf.org/