Dieser Beitrag ist der achte Teil unserer Blogserie Tales From the Trenches: CRA Lessons Learned . Ziel dieser Serie ist es, Herstellern, Softwareanbietern und Anbietern vernetzter Produkte die praktischen Realitäten der Umsetzung von CRA-Compliance-Programmen näherzubringen. Wir stützen uns auf Erkenntnisse aus der Zusammenarbeit mit Kunden und aus Gesprächen mit Branchenführern. Organisationen erkennen, dass nachhaltige Compliance Governance, Transparenz, Verantwortlichkeit und Lifecycle-Management-Fähigkeiten erfordert, die weit über traditionelle Cybersecurity-Aktivitäten hinausgehen. Ein sicheres Produkt allein reicht für CRA-Compliance nicht aus.

 

Warum die Bereitschaft von Drittanbietern unter dem Cyber Resilience Act zum kritischen Erfolgsfaktor wird

Bei vielen Herstellern und Softwareanbietern konzentriert sich die Vorbereitung auf den Cyber Resilience Act (CRA) zunächst auf interne Aktivitäten. Organisationen inventarisieren Produkte, führen Risikobewertungen durch, etablieren Schwachstellenmanagement, erstellen Software Bills of Materials (SBOMs) und bauen Governance-Strukturen auf, um regulatorische Anforderungen zu erfüllen.

All diese Aktivitäten sind wesentlich. Unternehmen stellen jedoch fest, dass eine ausschließlich interne Perspektive nicht genügt.

Ihre Compliance-Lage kann ebenso stark von Ihren Lieferanten abhängen wie von Ihrer eigenen Organisation.

Moderne Produkte werden nur selten vollständig intern entwickelt. Sie hängen von komplexen Ökosystemen aus Komponentenherstellern, Softwarelieferanten, Cloud-Anbietern, externen Entwicklern, OEM-Partnern, Systemintegratoren und Open-Source-Communities ab. Jeder dieser Beteiligten kann ein Compliance-Risiko darstellen.

Ein Lieferant, der keine Informationen zu Softwarekomponenten liefern, Schwachstellenuntersuchungen unterstützen, Sicherheitsupdates pflegen, Nachweisanfragen beantworten oder an koordinierten Offenlegungsprozessen teilnehmen kann, schafft erhebliche Probleme für nachgelagerte Hersteller, die CRA-Pflichten erfüllen müssen.

Deshalb überdenken Organisationen ihre Lieferantenbeziehungen. Was früher vor allem eine Beschaffungsfrage war, wird schnell zu einer Cybersecurity-, Compliance- und Governance-Frage. Je näher die CRA-Durchsetzung rückt, desto deutlicher wird: Die Bereitschaft der Lieferanten kann einer der entscheidenden Faktoren für den Erfolg eines Compliance-Programms sein.

Erkenntnisse für Führungskräfte

Traditionell konzentrierte sich das Lieferantenmanagement auf Kosten, Qualität, Liefertermine, Fertigungskapazität und Service Levels. Cybersecurity-Anforderungen beschränkten sich häufig auf Vertragsklauseln, Sicherheitsfragebögen oder periodische Bewertungen.

Der CRA verändert diese Gleichung. Organisationen sind nun dafür verantwortlich, die Cybersecurity-Lage der auf den Markt gebrachten Produkte zu verstehen – auch wenn kritische Technologien von Dritten stammen.

Unternehmen stellen ihren Lieferanten deshalb neue Fragen:

  • Können unsere Lieferanten aktuelle SBOMs bereitstellen?
  • Wie schnell informieren sie uns über Schwachstellen?
  • Nutzen sie sichere Entwicklungsprozesse?
  • Können sie Incident-Untersuchungen unterstützen?
  • Liefern sie bei Bedarf Compliance-Nachweise?
  • Können sie langfristige Support-Zusagen erfüllen?
  • Was geschieht, wenn ein Lieferant eine kritische Komponente einstellt?

Diese Fragen wirken sich direkt darauf aus, ob eine Organisation Pflichten zu Schwachstellenmanagement, Incident-Meldung, technischer Dokumentation, Softwaretransparenz, Produktlebenszyklus-Support und regulatorischen Anfragen erfüllen kann – alles zentrale CRA-Themen.

Lieferanten-Governance wird damit zu einem strategischen Geschäftsthema statt zu einer reinen Beschaffungsaktivität. Organisationen erkennen zunehmend, dass der Cybersecurity-Reifegrad ihrer Lieferanten regulatorisches Risiko, Kundenvertrauen und operative Resilienz direkt beeinflusst.

Warum Lieferantenrisiken unter dem CRA zunehmen

Mehrere Faktoren erhöhen die Bedeutung der Lieferantenbereitschaft.

Produkte hängen von komplexen Lieferketten ab

Heutige vernetzte Produkte enthalten häufig Embedded-Prozessoren, Betriebssysteme, Open-Source-Software, Drittanbieter-Bibliotheken, Cloud-Dienste, Kommunikationsmodule und Sicherheitskomponenten.

Für ein einzelnes Produkt sind mitunter Hunderte Lieferanten nötig. Bei großen, heterogenen Portfolios steigt diese Zahl stark. Je größer das Ökosystem, desto größer die Compliance-Herausforderung.

Transparenz endet oft an Lieferantengrenzen

Schon die eigenen Entwicklungsprozesse vollständig zu verwalten und zu überwachen ist schwierig. Sobald Drittanbieter-Technologie beteiligt ist, nimmt die Transparenz über Cybersecurity-Compliance häufig deutlich ab. Ohne Lieferantentransparenz lassen sich kritische Compliance-Fragen nur schwer beantworten.

Schwachstellen wandern durch Lieferketten

Eine Schwachstelle in einer vom Lieferanten bereitgestellten Komponente kann schnell mehrere Produkte betreffen. Wird eine Schwachstelle gemeldet, muss die Organisation feststellen können, welche Produkte und Kunden betroffen sind, welche Behebungsoptionen bestehen und ob regulatorische Meldepflichten greifen.

Dafür sind genaue und zeitnahe Informationen vom Lieferanten erforderlich.

Lifecycle-Verantwortung endet nicht mit der Produkteinführung

Der CRA verlangt fortlaufenden Support und Schwachstellenmanagement über Jahre nach der Markteinführung. Unternehmen reichen diese Anforderungen wiederum an ihre Lieferanten weiter. Viele Lieferanten sind darauf noch nicht vorbereitet.

Herausforderungen aus der Praxis

Schwachstellen in Drittanbieter-Komponenten waren für OEMs schon immer schwierig. Mit dem CRA werden sie zusätzlich zum Compliance-Risiko. Wird eine kritische Schwachstelle offengelegt, wenden sich OEMs sofort an den Lieferanten. Kann dieser betroffene Versionen nicht schnell benennen oder keine Anleitung zur Behebung liefern, ist der OEM blockiert. Tage gehen verloren. Das Problem ist dann nicht die Reaktionsfähigkeit des Herstellers, sondern die mangelnde Vorbereitung des Lieferanten.

Auch bei CRA-Readiness-Prüfungen kann der Nachweis der Softwarekomponenten schwierig werden. Hersteller sind auf vollständige SBOMs ihrer Lieferanten angewiesen, doch viele Lieferanten können diese einschließlich unterstützender Dokumentation noch nicht liefern. So entsteht ein Compliance-Problem außerhalb der eigenen Organisation.

Eine weitere Herausforderung entsteht, wenn ein Technologieanbieter unerwartet den Support für eine kritische Softwarekomponente beendet. Die Komponente kann weiterhin in aktiv unterstützten Produkten stecken. Der Austausch ist teuer und disruptiv und erfordert oft erhebliche Reengineering-Arbeit. Selbst wenn die Funktion weiterhin gegeben ist, schafft fehlender Support ein Compliance-Risiko – ausgelöst nicht durch eine Schwachstelle, sondern durch eine Lifecycle-Entscheidung des Lieferanten.

Best Practices für Lieferanten-Governance unter dem CRA

Organisationen, die Lieferantenrisiken erfolgreich adressieren, verfolgen mehrere gemeinsame Strategien.

Cybersecurity-Anforderungen für Lieferanten festlegen

Erwartungen zu Schwachstellenmeldungen, SBOM-Verfügbarkeit, Sicherheitsupdates, Incident-Benachrichtigungen und Compliance-Nachweisen sollten klar definiert und möglichst vertraglich verankert werden.

Risikostufen für Lieferanten einführen

Nicht alle Lieferanten bergen das gleiche Risiko. Sie sollten nach Produktkritikalität, Sicherheitswirkung, Abhängigkeitsgrad und regulatorischer Relevanz klassifiziert werden. Hochrisiko-Lieferanten benötigen stärkere Aufsicht.

Lieferantenbereitschaft regelmäßig bewerten

Cybersecurity-Fähigkeiten sollten periodisch und nicht nur beim Onboarding geprüft werden. Zu betrachten sind Schwachstellenmanagement, sichere Entwicklung, Incident Response, Dokumentationsqualität, Lifecycle-Support sowie der Umgang mit entdeckten Schwachstellen und Cybervorfällen.

Transparenz der Software-Lieferkette verbessern

Organisationen sollten nachvollziehen können, wo Komponenten von Lieferanten eingesetzt werden – einschließlich Softwareabhängigkeiten, Versionsinformationen und Supportstatus. Transparenz ist die Grundlage wirksamer Governance.

Lieferantenausfälle einplanen

Für Übernahmen, Geschäftsaufgaben, Produkteinstellungen oder Support-Ende sollten Notfallpläne bestehen. Sie erhöhen die Resilienz und senken langfristige Risiken.

Häufige Fallstricke

Annehmen, dass Lieferanten CRA-bereit sind

Viele Lieferanten bauen ihre eigenen Compliance-Programme noch auf; manche haben noch nicht begonnen. Die Bereitschaft muss verifiziert und darf nicht vorausgesetzt werden.

Nur Tier-1-Lieferanten betrachten

Kritische Risiken entstehen oft tiefer in der Lieferkette. Soweit möglich sollten indirekte Abhängigkeiten bewertet werden. Ein Kommunikationsmodul in einem IoT-Gerät hat beispielsweise eigene Lieferketten mit Hardware-IP, intern entwickelter Software und lizenzierten Komponenten. Transparenz muss Lieferanten und Unterlieferanten umfassen.

Lieferantenbewertungen als reine Beschaffungsübung behandeln

Fähigkeiten, Produkte und Support-Zusagen ändern sich. Deshalb sind regelmäßige Neubewertungen erforderlich.

Open-Source-Abhängigkeiten übersehen

Open-Source-Komponenten in Lieferantenlösungen können zusätzliche Transparenz- und Governance-Probleme verursachen. Dieses Thema behandeln wir im nächsten Beitrag ausführlicher.

Maßnahmen für OEMs und Softwareanbieter

Sofortige Prioritäten

  1. Kritische Lieferanten und Softwareabhängigkeiten inventarisieren.
  2. Lieferanten identifizieren, die CRA-relevante Produkte unterstützen.
  3. Cybersecurity-Reife der Lieferanten bewerten.
  4. Prozesse zur Offenlegung von Schwachstellen prüfen.
  5. Verfügbarkeit und Qualität von Lieferanten-SBOMs bewerten.
  6. Support-Zusagen dokumentieren.
  7. Security-Compliance-Anforderungen definieren und Verträge dagegen prüfen.
  8. Eskalationsverfahren für lieferantenbezogene Sicherheitsereignisse einrichten.

Wer früh beginnt, reduziert spätere Compliance- und Betriebsrisiken deutlich.

Wie OmniTrust Certify helfen kann

Die Verwaltung lieferantenbezogener Compliance-Pflichten wird bei großen Produktportfolios und komplexen Software- und Komponentenlieferketten schnell unübersichtlich. OmniTrust Certify hilft zu verstehen, wie Drittanbieter-Abhängigkeiten einzelne Produkte, deren Cyberrisiko und regulatorische Konformität beeinflussen.

Mit Certify können Hersteller und Softwareanbieter:

  • Ein lebendes Produktprofil mit Lieferantenkomponenten, Software, Firmware und Abhängigkeiten aufbauen
  • SBOMs erstellen oder einlesen und Drittanbieter-Softwareabhängigkeiten identifizieren
  • Lieferanten und Komponenten mit den Produkten verknüpfen, in denen sie verwendet werden
  • Schwachstellen und Cyberrisiken von Drittanbieter-Komponenten identifizieren
  • Vom Lieferanten bereitgestellte Sicherheits-, Compliance- und Lifecycle-Nachweise pflegen
  • Auswirkungen von Lieferantenrisiken auf geltende Vorschriften und Standards einschließlich CRA bewerten
  • Nachvollziehbarkeit zwischen Lieferanten, Komponenten, Schwachstellen, Risiken, Kontrollen, Anforderungen und Nachweisen herstellen
  • Betroffene Produkte neu bewerten, wenn sich Komponenten, Schwachstellen, Supportstatus oder regulatorische Anforderungen ändern

Indem Certify Lieferantenabhängigkeiten mit demselben lebenden Produktdatensatz verknüpft, der für Cyberrisiken und regulatorische Konformität genutzt wird, hilft es Organisationen nicht nur zu erkennen, ob ein Lieferant ein Risiko darstellt, sondern welche Produkte betroffen sind, was dies für die Compliance bedeutet und welche Maßnahmen erforderlich sind.

Zusammenfassung

Eine zentrale Erkenntnis aus frühen CRA-Umsetzungen ist, dass Compliance nicht mehr an Organisationsgrenzen endet. Die Fähigkeit, Konformität nachzuweisen, kann letztlich von den Organisationen abhängen, die Software, Komponenten, Technologien und Dienste für Ihre Produkte bereitstellen.

Hersteller und Softwareanbieter, die unter dem CRA erfolgreich sein wollen, müssen Cybersecurity-Governance über die eigenen Grenzen hinaus auf die gesamte Produktlieferkette ausdehnen. Denn in der heutigen vernetzten Welt können Ihre Lieferanten zu Ihrem größten Compliance-Risiko werden.