CRA Drittkomponenten & Lieferantenmanagement: Due Diligence, SBOM und Schwachstellen

Hersteller bleiben nach dem Cyber Resilience Act für die Cybersicherheit ihres Produkts verantwortlich, auch wenn zentrale Software-, Hardware- oder Open-Source-Komponenten von Dritten stammen. Artikel 13 verlangt deshalb gebührende Sorgfalt bei der Auswahl und Integration von Komponenten sowie einen belastbaren Prozess für Schwachstellen, Support und Änderungen in der Lieferkette.

Den Zusammenhang erläutert der Cyber Resilience Act im Überblick. Weitere Fachthemen finden Sie in der zugehörigen CRA-Themenübersicht.

Wie werden Drittkomponenten ausgewählt und bewertet?

Auswahl und Prüftiefe richten sich nach der Sicherheitswirkung im eigenen Produkt. Gebührende Sorgfalt verbindet technische Eignung, nachvollziehbare Herkunft und realistische Wartungsfähigkeit.

Was verlangt der CRA bei Drittkomponenten?

Artikel 13 verpflichtet Hersteller, bei der Integration von Komponenten Dritter gebührende Sorgfalt anzuwenden. Das gilt für kommerzielle Bauteile ebenso wie für Softwarebibliotheken, Firmware, Betriebssystemkomponenten und freie oder quelloffene Software. Ziel ist, dass die gewählte Komponente die Cybersicherheit des Endprodukts nicht untergräbt.

Die Pflicht ist risikobasiert. Eine kleine UI-Bibliothek hat meist eine andere Bedeutung als ein kryptografischer Stack, Bootloader oder Netzwerkdienst, der eine Kernfunktion trägt. Deshalb sollte die CRA-Risikobewertung die Kritikalität der Komponenten sichtbar machen.

Was bedeutet Due Diligence in der Praxis?

Due Diligence ist keine einmalige Lieferantenabfrage. Hersteller sollten bereits vor der Auswahl prüfen, ob eine Komponente aktiv gepflegt wird, Sicherheitsmeldungen veröffentlicht werden, Updates verfügbar sind und der erwartete Support zur eigenen Produktlebensdauer passt.

Bei besonders kritischen Komponenten können zusätzliche Nachweise sinnvoll sein: dokumentierter Security-Kontakt, Veröffentlichungsprozess für Advisories, Supportzusagen, Reaktionszeiten, sichere Updatewege oder unabhängige Prüfberichte. Umfang und Tiefe müssen zum Risiko passen.

Welche Informationen sollte das Komponentenregister enthalten?

Mindestens relevant sind Name, Hersteller oder Projekt, Version, Lizenz, Bezugsquelle, Produktbezug, Kritikalität, Supportende, Security-Kontakt und bekannte Abhängigkeiten. Diese Informationen ergänzen die Software Bill of Materials um betriebliche und organisatorische Angaben.

Wie bewertet man die Kritikalität einer Drittkomponente?

Wichtige Faktoren sind Funktionsrelevanz, Angriffsoberfläche, Berechtigungen, Datenzugriff, Austauschbarkeit, Verbreitung im Produktportfolio und die Folgen einer Kompromittierung. Ein Treiber mit Kernelrechten oder eine Authentisierungsbibliothek verdient typischerweise mehr Aufmerksamkeit als ein reines Darstellungsmodul.

Auch die Reichweite ist relevant. Wird dieselbe Komponente in zwanzig Produkten verwendet, kann eine einzelne Schwachstelle einen großen Teil des Portfolios betreffen. Solche Querschnittskomponenten sollten besonders gut inventarisiert und überwacht werden.

Wie priorisiert man Lieferantenprüfungen?

Ein risikobasiertes Modell spart Aufwand. Kernkomponenten mit hohen Berechtigungen, Internetzugang oder Zugriff auf sensible Daten werden tief geprüft. Weniger kritische Komponenten können mit einem vereinfachten Verfahren behandelt werden.

Die Priorisierung sollte dokumentiert sein. So ist später nachvollziehbar, warum für bestimmte Lieferanten zusätzliche Nachweise oder Reviews verlangt wurden.

Wie werden Komponenten und Abhängigkeiten erfasst?

Komponenten müssen dem tatsächlichen Produktstand zugeordnet sein. SBOM, Lieferanteninformationen und kritische Abhängigkeiten bilden gemeinsam die Grundlage für eine belastbare Bewertung.

Wie hängt die SBOM mit Lieferantenmanagement zusammen?

Die SBOM zeigt, welche Komponenten in einem Produkt enthalten sind. Lieferantenmanagement ergänzt, wer dafür verantwortlich ist, wie Sicherheitsinformationen bezogen werden und ob die Komponente während des eigenen Supportzeitraums voraussichtlich gepflegt werden kann.

Nur beides zusammen ermöglicht eine schnelle Reaktion. Eine CVE ist nutzlos, wenn unklar bleibt, in welchem Produktrelease die betroffene Version steckt. Umgekehrt hilft ein Lieferantenvertrag wenig, wenn die tatsächlich ausgelieferte Komponentenversion nicht bekannt ist.

Was ist bei Open-Source-Komponenten anders?

Open Source ist nicht pauschal riskanter oder von der Herstellerverantwortung ausgenommen. Der Hersteller muss auch bei freien Komponenten prüfen, ob Integration und Wartung zum eigenen Produkt passen. Gleichzeitig kann die Community-Struktur anders funktionieren als bei einem kommerziellen Lieferanten.

Der Beitrag CRA und Open Source erklärt die Rollen und Ausnahmen im Detail. Für den integrierenden Hersteller bleibt entscheidend, dass Schwachstellen der Komponente im eigenen Produktkontext bewertet und behandelt werden.

Was gilt für Unterauftragnehmer des Lieferanten?

Hersteller sollten besonders bei kritischen Komponenten verstehen, welche wesentlichen Abhängigkeiten hinter dem direkten Lieferanten stehen. Eine Cloud- oder Firmwarekomponente kann wiederum auf Drittanbieter angewiesen sein. Vollständige Transparenz bis zur letzten Unterkomponente ist nicht immer realistisch, aber kritische Abhängigkeiten sollten identifiziert werden.

Die SBOM und Lieferantendokumentation helfen, diese Kette schrittweise sichtbar zu machen. Entscheidend ist, welche Abhängigkeiten die Produktsicherheit oder Updatefähigkeit wesentlich beeinflussen.

Wie geht man mit Komponenten ohne klaren Maintainer um?

Eine unmaintained Komponente ist nicht automatisch unzulässig, erhöht aber das eigene Wartungsrisiko. Der Hersteller muss entscheiden, ob er Wartung selbst übernehmen kann, einen Fork pflegt, migriert oder die Komponente ersetzt.

Bei Kernfunktionen sollte diese Entscheidung nicht aufgeschoben werden, bis die erste kritische Schwachstelle erscheint. Wartungsfähigkeit gehört bereits in Secure by Design.

Wie werden Schwachstellen und Supportabhängigkeiten behandelt?

Der Hersteller bewertet die Betroffenheit im eigenen Produkt und organisiert Abhilfe sowie den Kontakt zum Komponentenhersteller oder Maintainer. Das Supportende einer Kernkomponente braucht eine rechtzeitig geplante Reaktion.

Was muss passieren, wenn eine Drittkomponente eine Schwachstelle hat?

Zuerst ist die eigene Betroffenheit zu klären: Welche Produkte und Versionen enthalten die Komponente, ist die verwundbare Funktion erreichbar und welche Auswirkungen sind realistisch? Danach folgen Priorisierung, Mitigation oder Patch sowie Nutzerinformation.

Artikel 13 verlangt zudem, dass identifizierte Schwachstellen in integrierten Komponenten dem Hersteller oder Maintainer der Komponente gemeldet werden. Der eigene Vulnerability-Handling-Prozess sollte diese Weitergabe als festen Schritt enthalten.

Muss eigener Fix-Code an den Maintainer zurückgegeben werden?

Wenn ein Hersteller selbst eine Schwachstelle in einer integrierten Komponente behebt oder modifiziert, kann es erforderlich sein, relevante Informationen und gegebenenfalls Änderungen oder Code an die Person oder Organisation weiterzugeben, die die Komponente entwickelt oder wartet. Der konkrete Umfang hängt von Fall, Lizenz und Sicherheitskontext ab.

Wichtig ist, dass die Behebung nicht nur lokal versteckt bleibt, wenn dadurch andere Integratoren und Nutzer derselben Komponente weiter gefährdet wären. Gleichzeitig sollte die Offenlegung koordiniert erfolgen, damit keine unnötigen Exploit-Details vor einem verfügbaren Fix veröffentlicht werden.

Wie überwacht man Komponenten über den Supportzeitraum?

Ein einmaliger Scan vor Release reicht nicht. Während des CRA-Supportzeitraums müssen neue Advisories, Versionswechsel, End-of-Life-Ankündigungen und Sicherheitsupdates überwacht werden. Für Kernkomponenten ist ein Owner sinnvoll, der Änderungen bewertet.

Automatisierte Dependency-Scans können helfen, ersetzen aber nicht die organisatorische Beobachtung. Besonders Hardware, proprietäre Firmware und kommerzielle SDKs liefern Sicherheitsinformationen oft über eigene Portale oder Vertragskanäle.

Was passiert, wenn eine Kernkomponente End of Life erreicht?

Dann entsteht ein strukturelles Risiko. Der Hersteller muss prüfen, ob die Komponente selbst weiter gewartet werden kann, ob ein Wechsel möglich ist oder ob der eigene Produktsupport angepasst werden muss. Ein nicht mehr gepflegter Kernbestandteil kann die Fähigkeit zur künftigen Schwachstellenbehebung erheblich einschränken.

Deshalb sollte das Supportende kritischer Komponenten bereits bei der Produktauswahl mit dem geplanten eigenen Supportzeitraum abgeglichen werden. Ein Produkt zehn Jahre zu unterstützen und gleichzeitig eine Kernkomponente mit zwei Jahren Restlaufzeit einzuplanen, braucht eine belastbare Migrationsstrategie.

Wie werden Lieferanten, Einkauf und Marktrollen verbunden?

Verträge und Zuständigkeiten sichern den erforderlichen Informationsfluss. Sie ergänzen die technische Prüfung und ersetzen weder die eigene Herstellerverantwortung noch die Pflichten anderer Wirtschaftsakteure.

Welche CRA-Klauseln gehören in Lieferantenverträge?

Verträge können sicherstellen, dass der Hersteller die für seine eigenen Pflichten benötigten Informationen erhält. Sinnvoll sind je nach Risiko Regelungen zu Security-Kontakt, Schwachstelleninformation, Supportdauer, Versions- und Änderungsmitteilungen, SBOM-Informationen, Updatebereitstellung und Reaktionswegen.

Vertragsklauseln ersetzen keine technische Due Diligence. Sie helfen aber, Informationsrechte, Fristen und Verantwortlichkeiten festzuhalten. Der CRA Lieferanten- & Drittkomponentencheck kann als strukturierte Arbeitsgrundlage für die Prüfung dienen.

Wie verbindet man Beschaffung und Security organisatorisch?

Einkauf sollte wissen, welche Security-Nachweise für kritische Komponenten erforderlich sind, während Security die kommerziellen und betrieblichen Zwänge versteht. Ein kurzer Freigabepunkt vor Bestellung oder Integration kann verhindern, dass ungeprüfte Komponenten zum Standard werden.

Neue Versionen oder Lieferantenwechsel sollten einen erneuten Check auslösen. So bleibt die technische Produktakte mit dem realen Lieferstand synchron.

Was gilt für Importeure und Händler in der Lieferkette?

Importeure und Händler haben eigene CRA-Prüf- und Reaktionspflichten. Für den Hersteller ist wichtig, dass Informationen über Konformität, Sicherheitsupdates und Support die Lieferkette erreichen. Der Artikel CRA-Pflichten für Importeure behandelt deren Rolle separat.

Ein belastbarer Herstellerprozess erleichtert den Wirtschaftsakteuren ihre Prüfung, weil Produktversion, Dokumentation, Supportende und Security-Kontakt klar verfügbar sind.

Wie sollte ein Lieferanten-Review dokumentiert werden?

Für kritische Komponenten reicht eine Bewertung mit Datum, Verantwortlichem, geprüften Nachweisen, offenen Punkten und Entscheidung. Wichtig ist, dass spätere Prüfer erkennen können, warum eine Komponente trotz eines bekannten Risikos akzeptiert oder warum eine Alternative gewählt wurde.

Das Review sollte außerdem einen nächsten Prüftermin oder Trigger enthalten – etwa Supportende, Major Release, Lieferantenwechsel oder kritisches Advisory. So wird Due Diligence zu einem Lifecycle-Prozess statt zu einer einmaligen Beschaffungsakte.

Wie werden Änderungen und offene Befunde freigegeben?

Komponentenupdates und Lieferantenwechsel werden nach ihrer Sicherheitswirkung geprüft. Offene Befunde benötigen nachvollziehbare Maßnahmen und Entscheidungen; verbindliche Sicherheitsanforderungen können nicht allein intern abbedungen werden.

Wie behandelt man Lieferantenwechsel?

Ein Lieferantenwechsel ist nicht nur eine Einkaufsentscheidung. Neue Hardware- oder Softwarekomponenten können andere Schnittstellen, Schwachstellen, Supportbedingungen und Sicherheitsmechanismen mitbringen. Deshalb sollte ein Wechsel einen Security-Impact-Check auslösen.

Bei tiefgreifenden Änderungen kann zusätzlich zu prüfen sein, ob sich die Risikobewertung oder Konformitätsbewertung ändert. Der Beitrag wesentliche Änderung nach CRA grenzt relevante Fälle ein.

Welche Rolle spielt Security Testing?

Lieferantennachweise sind hilfreich, entbinden den Hersteller aber nicht von der Prüfung des eigenen Integrationskontexts. Eine sichere Bibliothek kann durch falsche Konfiguration oder unsichere Nutzung im Produkt problematisch werden.

Das CRA Security Testing sollte daher auch Schnittstellen, Konfigurationen und Fehlerfälle relevanter Drittkomponenten abdecken.

Was passiert bei kurzfristigen Lieferengpässen?

Gerade Hardwarehersteller ersetzen Bauteile manchmal unter Zeitdruck. Ein „form-fit-function“-Ersatz kann sicherheitlich trotzdem relevant sein, wenn Firmware, Schlüssel, Debugschnittstellen oder Treiber abweichen. Deshalb sollte auch ein Notfall-Lieferantenwechsel mindestens einen kompakten Security-Impact-Check durchlaufen.

Bei sicherheitskritischen Komponenten kann ein ungeprüfter Ersatz ein größeres Risiko darstellen als eine verspätete Auslieferung. Beschaffung und Produktverantwortung sollten diese Entscheidung gemeinsam treffen.

Wie werden Lieferanten-Findings geschlossen?

Ein Fragebogen mit roten Punkten ist noch keine Risikobehandlung. Offene Findings brauchen Owner, Maßnahme und Frist. Mögliche Entscheidungen sind Nachweis nachfordern, technische Kompensation einbauen, vertragliche Zusage vereinbaren, alternative Komponente vorbereiten oder nach Prüfung der einschlägigen Anforderungen eine andere begründete Entscheidung treffen. Verbindliche Produktanforderungen können nicht allein durch eine interne Risikoübernahme ersetzt werden.

Die Entscheidung sollte mit Produkt-Risikobewertung und Supportplanung verbunden werden, damit dieselbe Lücke nicht bei jedem Audit neu entdeckt wird.

Wie verhindert man ungeprüfte Komponentenupdates?

Automatische Dependency-Bots oder Lieferantenupdates können Wartung erleichtern, sollten kritische Komponenten aber nicht ohne Produktprüfung austauschen. Eine neue Version kann APIs, Standardkonfigurationen, Berechtigungen oder Sicherheitsmechanismen verändern, obwohl sie formal nur ein Patchrelease ist.

Für Kernkomponenten sollte deshalb eine Freigabelogik gelten: Changelog und Security-Hinweise prüfen, SBOM aktualisieren, relevante Tests ausführen und erst danach in den Produktrelease übernehmen. Das hält Lieferkettenautomatisierung mit der eigenen Produktverantwortung zusammen.

Wie sollte ein Lieferantenwechsel sicher freigegeben werden?

Ein Wechsel von Bibliothek, Firmwarelieferant, Cloud-Dienst oder Hardwarekomponente sollte einen kurzen Security-Impact-Check auslösen. Dabei werden neue Abhängigkeiten, Supportdauer, Sicherheitskontakte, Updatewege und mögliche Änderungen an Berechtigungen oder Schnittstellen geprüft. Für kritische Komponenten sollten SBOM, Risikobewertung und relevante Tests vor dem nächsten Produktrelease aktualisiert werden. So bleibt die Lieferkette auch bei wirtschaftlich motivierten Wechseln technisch beherrschbar.

Welche Nachweise und Kontrollen machen den Prozess belastbar?

Die Produktakte verbindet Komponentenstand, Entscheidungen, Supportannahmen und Prüfungen. Regelmäßige Kontrollen zeigen, ob der Prozess auch bei neuen Sicherheitsinformationen tatsächlich funktioniert.

Wie dokumentiert man Drittkomponenten für die technische Akte?

Die technische Dokumentation sollte Komponentenbezug, SBOM, relevante Due-Diligence-Entscheidungen, bekannte Risiken, Supportannahmen und gegebenenfalls Test- oder Lieferantennachweise enthalten. Nicht jeder Einkaufsvertrag muss vollständig Bestandteil der Produktakte sein.

Wichtig ist die Evidenzkette: Warum wurde eine kritische Komponente gewählt, wie wird sie überwacht und wie kann der Hersteller bei einer Schwachstelle reagieren?

Welche typischen Fehler treten auf?

• SBOM existiert, aber ohne Produkt- und Versionsbezug.
• Kernkomponenten werden nur nach Preis und Funktion ausgewählt.
• Supportende des Lieferanten wird nicht mit eigener Produktlaufzeit abgeglichen.
• Schwachstellen werden pauschal an den Lieferanten delegiert.
• Open Source wird nicht als Lieferkettenbestandteil betrachtet.
• Änderungen des Lieferanten gelangen ungeprüft in den Build.
• Keine Vertretung oder kein Security-Kontakt für kritische Lieferanten.

Wie können KMU ein pragmatisches Lieferantenmanagement aufbauen?

Ein KMU kann mit einer einfachen Kritikalitätsklasse starten: A für kern- oder sicherheitskritische Komponenten, B für relevante Standardkomponenten, C für geringe Sicherheitswirkung. Klasse A erhält besonders tiefe Prüfungen. Umfang und Regelmäßigkeit der Kontrollen für die übrigen Klassen richten sich ebenfalls nach dem konkreten Risiko.

Zusätzlich werden SBOM, Supportende und Security-Kontakt zentral gepflegt. Damit entsteht mit überschaubarem Aufwand ein belastbarer Überblick über die wichtigsten Abhängigkeiten.

Wo stehen die Pflichten zu Drittkomponenten?

Die verbindlichen Herstellerpflichten ergeben sich insbesondere aus Artikel 13 Absätze 5 und 6 sowie Anhang I Teil II der Verordnung (EU) 2024/2847. Dort werden Due Diligence, Schwachstellenbehandlung, Meldung an Komponentenhersteller oder Maintainer und die SBOM-Anforderungen verankert.

Quellen geprüft am 4. Oktober 2026. Redaktion: Jörn Poppenhäger.