CRA umsetzen: Anforderungen an die Behandlung von Schwachstellen?

Unsere bisherigen Beiträge zum CRA haben sich vor allem mit den Anforderungen an die Sicherheit von Produkten mit digitalen Elementen beschäftigt. Doch was passiert nach der Markteinführung? Die Antwort liefert Teil II von Anhang I des Cyber Resilience Acts. Darin geht es um die Behandlung von Schwachstellen während des gesamten Produktlebenszyklus.

Produkte müssen nicht nur sicher ausgeliefert werden, sie müssen auch während ihrer Nutzungsdauer sicher bleiben. Hersteller sind also verpflichtet, Schwachstellen zu erkennen, darauf zu reagieren und ihre Kunden zu informieren.

Die Verordnung listet dazu acht Anforderungen, die sich konkret an Hersteller richten. In diesem Beitrag erklären wir jede dieser Anforderungen:

• Was steht drin?
• Was bedeutet das für Ihr Unternehmen konkret?
• Worauf müssen Sie achten?
• Welche Tools und Prozesse helfen bei der Umsetzung?

Inhaltsverzeichnis

• 1. Ermittlung und Dokumentation von Schwachstellen und Komponenten
• 2. Behebung von Schwachstellen durch Sicherheitsupdates
• 3. Regelmäßiges Security-Testing
• 4. Veröffentlichung von Infos zu behobenen Schwachstellen
• 5. Koordinierte Offenlegung von Schwachstellen
• 6. Kontakt und Austausch zu Schwachstellen
• 7. Sichere Update-Verteilung
• 8. Kostenlose Bereitstellung von Security-Updates inkl. Anleitung

1. Ermittlung und Dokumentation von Schwachstellen und Komponenten

Die erste Anforderung aus Teil II des CRA verpflichtet Hersteller dazu, Schwachstellen und verwendete Komponenten ihrer Produkte systematisch zu identifizieren und zu dokumentieren. Dazu gehört insbesondere die Erstellung einer Software-Stückliste (SBOM – Software Bill of Materials) in einem gängigen, maschinenlesbaren Format. Diese SBOM muss zumindest die obersten Abhängigkeiten aller eingesetzten Softwarebestandteile enthalten.

Wer nicht weiß, welche Bibliotheken, Frameworks oder Drittkomponenten in seinem Produkt enthalten sind, kann Schwachstellen weder erkennen noch rechtzeitig darauf reagieren. Besonders bei Open-Source-Software und zugekauften Modulen ist die vollständige Erfassung essenziell. Diese Anforderung zielt damit auf eine Verbesserung der Software-Lieferkettensicherheit ab, ein Thema, das seit Lücken wie Log4Shell (CVE-2021-44228), Heartbleed (CVE-2014-0160) oder EternalBlue (CVE-2017-0144) höchste Aufmerksamkeit genießt.

💡 Unsere Empfehlung: Als Hersteller sollten Sie die Erfassung von Abhängigkeiten automatisieren. Tools wie Syft, CycloneDX oder SPDX können hierzu in CI/CD-Pipelines integriert werden. Mehr dazu in unserem Blogpost Governance: Software Bill of Materials (SBOM).

2. Behebung von Schwachstellen durch Sicherheitsupdates

Die zweite Anforderung verlangt von Herstellern, dass sie Schwachstellen unverzüglich behandeln und beheben. Dies muss in Form von Sicherheitsaktualisierungen erfolgen, also durch Software-Updates, die gezielt Sicherheitsprobleme adressieren. Dabei gilt: Wenn technisch möglich, sind diese Updates getrennt von Funktionsaktualisierungen bereitzustellen. In der Anforderung stecken zwei Aspekte. Zum einen ist da der Zeitfaktor. Es darf keine langen Verzögerungen bei der Bereitstellung von Patches geben. In der Praxis heißt das, dass Unternehmen einen etablierten Patch-Prozess benötigen, der es erlaubt, sicherheitskritische Änderungen kurzfristig auszuliefern, unabhängig von geplanten Releases oder Feature-Roadmaps.

💡 Unsere Empfehlung: Hersteller sollten einen eigenen Prozess zur Bereitstellung von Sicherheitsupdates etablieren. Dieser muss in der Lage sein, Patch-Updates zu erzeugen und auszuliefern. Überprüfen Sie Ihre Installationsroutinen und Service-Anweisungen entsprechend. Zudem gehört zur Behandlung auch die Bewertung von Schwachstellen. Nutzen Sie hierzu ein strukturiertes Bewertungsmodell wie z. B. CVSS. Um die Behebung von Schwachstellen richtig priorisieren zu können, ist zudem Ihre eigene, herstellerspezifische Risikoanalyse unumgänglich.

3. Regelmäßiges Security-Testing

Die dritte Anforderung schreibt vor, dass die Sicherheit des Produkts mit digitalen Elementen regelmäßig und wirksam getestet und überprüft werden muss. Diese Prüfung darf also nicht nur einmalig im Rahmen der Markteinführung erfolgen, sondern ist über den gesamten Produktlebenszyklus hinweg erforderlich. Die Prüfung muss sich an neue Bedrohungen, neu entdeckte Schwachstellen und Veränderungen am Produkt anpassen.

💡 Unsere Empfehlung: Effektives Security-Testing basiert auf einem Methodenmix. Nutzen Sie statische Codeanalyse (SAST), dynamisches Testen (DAST), Fuzzing, Penetrationstests und Reviews. Automatisieren Sie so viel wie möglich. Tools wie SonarQube, Semgrep, OWASP ZAP oder GitHub CodeQL lassen sich hierzu in Ihre CI/CD-Pipelines integrieren. Mehr dazu in unserem Blogpost Security: Automatisierter Web Security Check mit OWASP ZAP. Achten Sie auf regelmäßige Ausführung der Tests. Ausführung nur bei eigener Codeänderung ist zu wenig. Führen Sie zudem regelmäßiges CVE-Monitoring durch. Der automatisierte Abgleich mit Schwachstellen-Datenbanken (z. B. CVE) wird von Werkzeugen wie Grype oder Dependency-Track unterstützt. Hersteller sollten auch berücksichtigen, dass es mittlerweile eine europäische CVE-Datenbank gibt. Darüber hinaus empfiehlt sich der Aufbau eines interdisziplinären Security Review Boards, das sicherheitsrelevante Änderungen freigibt und Risiken bewertet.

4. Veröffentlichung von Infos zu behobenen Schwachstellen

Die vierte Anforderung verpflichtet Hersteller dazu, nach Bereitstellung eines Sicherheitsupdates relevante Informationen über die behobene Schwachstelle zu veröffentlichen. Diese Informationen müssen so gestaltet sein, dass die Nutzer das betroffene Produkt identifizieren, die Auswirkungen und Schwere der Schwachstelle einschätzen sowie klare Anweisungen zur Behebung erhalten können. Nur wenn die Veröffentlichung selbst ein Sicherheitsrisiko darstellen würde, darf diese verzögert erfolgen, bis den Nutzern ausreichend Zeit zum Patchen eingeräumt wurde. Es handelt sich bei dieser Anforderung primär um eine Kommunikationspflicht. Die Herausforderungen sind daher weniger technischer, sondern vielmehr organisatorischer Natur.

💡 Unsere Empfehlung: Definieren Sie Formate und Kanäle für die Veröffentlichung. Stellen Sie sicher, dass Sie die inhaltlichen Anforderungen dabei erfüllen und legen Sie gleichzeitig fest, nach welchem Zeitplan Veröffentlichungen erfolgen. Denken Sie diese Prozesse aus Nutzersicht. Die Reise beginnt dabei häufig mit einer dedizierten Security-Advisory-Seite innerhalb Ihrer Web-Präsenz. Beachten Sie auch, dass Meldungen an ENISA notwendig sind, das zugehörige Meldeportal steht aber noch nicht zur Verfügung.

5. Koordinierte Offenlegung von Schwachstellen

Hersteller sind verpflichtet, eine Strategie zur koordinierten Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure, CVD) aufzustellen und umzusetzen. Damit soll sichergestellt werden, dass gemeldete Schwachstellen strukturiert entgegengenommen, geprüft, behoben und kommuniziert werden. Im Idealfall im Einklang mit dem meldenden Dritten, z. B. Sicherheitsforschern oder Kunden.

💡 Unsere Empfehlung: Erstellen Sie eine öffentlich zugängliche CVD-Policy. Erwägen Sie zusätzlich die Nutzung einer security.txt gemäß RFC 9116, um maschinenlesbar auf Ihre CVD-Kontaktstelle hinzuweisen.

6. Kontakt und Austausch zu Schwachstellen

Die sechste Anforderung fordert, dass Hersteller Maßnahmen ergreifen, um den Austausch von Informationen über mögliche Schwachstellen in ihren Produkten zu erleichtern. Dazu gehört insbesondere die Bereitstellung einer Kontaktadresse, über die Schwachstellen gemeldet werden können.

💡 Unsere Empfehlung: Stellen Sie Kontaktmöglichkeiten (z. B. eine dedizierte E-Mail-Adresse wie security@company.com) bereit, über die Dritte idealerweise verschlüsselt mit Ihnen kommunizieren können. Stellen Sie hierzu einen PGP-Schlüssel zur Verfügung. Zudem müssen Sie die Zuständigkeiten klären. Es muss klar definiert sein, wer eingehende Meldungen prüft, priorisiert und bearbeitet – auch am Wochenende, bei Urlaub oder Ausfall. Teil Ihrer CVD-Policy sollten auch Ihre Reaktionszeiten sein. Halten Sie diese Informationen auch in Ihrer security.txt fest. Und denken Sie immer daran: Wer Sie auf diesem Weg kontaktiert, ist Ihnen zumeist wohlgesonnen und will helfen. Reagieren und kommunizieren Sie respektvoll.

7. Sichere Update-Verteilung

Die siebte Anforderung verpflichtet Hersteller dazu, Mechanismen für die sichere Verbreitung von Aktualisierungen bereitzustellen. Damit soll sichergestellt werden, dass Aktualisierungen ohne Manipulation beim Kunden ankommen.

💡 Unsere Empfehlung: Als Hersteller sollten Sie auf etablierte Update-Frameworks setzen, die Sicherheitsmechanismen wie Signaturprüfung, Transportschutz und Recovery-Funktionen bereits mitbringen. Geeignete Open-Source-Lösungen sind beispielsweise Mender.io, Eclipse Hawkbit oder SWUpdate. Auch für nicht vernetzte Geräte (z. B. USB-Update via Servicepersonal) gelten Sicherheitsanforderungen. Die Update-Datei sollte mindestens signiert sein und vor der Installation auf Integrität geprüft werden. Eine Checksumme allein reicht in der Regel nicht aus. Abschließend gilt: Die beste Sicherheitsaktualisierung nützt nichts, wenn sie nicht beim Nutzer ankommt. Deshalb sollten Sie als Hersteller auch in Ihre Serviceprozesse und die Kundenkommunikation investieren.

8. Kostenlose Bereitstellung von Security-Updates inkl. Anleitung

Die achte Anforderung verpflichtet Hersteller dazu, Sicherheitsupdates unverzüglich und kostenlos bereitzustellen. Eine Ausnahme können maßgeschneiderte Produkte darstellen, für die mit einem gewerblichen Nutzer etwas anderes vertraglich vereinbart wurde. Mit dem Update müssen Hinweise und Informationen über das Update mitgeliefert werden, insbesondere zu möglichen Maßnahmen, die der Nutzer ergreifen sollte.

💡 Unsere Empfehlung: Die Bereitstellung von Sicherheitsupdates sollte niedrigschwellig und friktionsfrei erfolgen. Richten Sie ein zentrales Download-Portal oder eine automatische Update-Funktion ein, über die Patches für alle unterstützten Produktversionen sowie zugehörige Informationen wie betroffene Versionen, Beschreibung der Schwachstelle, Installationsanleitung oder Hinweise auf eventuelle Kompatibilitätsfragen angeboten werden. Für Embedded- oder Industrieprodukte empfiehlt sich die Integration in vorhandene Service- und Instandhaltungsprozesse, z. B. durch gezielte Schulungen oder Update-Hinweise im Kundenportal.

Fazit

Mit Teil II des Anhangs I macht der Cyber Resilience Act unmissverständlich klar, dass Schwachstellenmanagement kein Nebenkriegsschauplatz ist und den gesamten Lebenszyklus umfasst. Hersteller müssen in der Lage sein, über den gesamten Lebenszyklus hinweg auf Schwachstellen zu reagieren, sie zu beheben, Updates sicher bereitzustellen und betroffene Nutzer transparent zu informieren.

Das verlangt nicht nur technische Fähigkeiten, sondern auch gut abgestimmte Prozesse, klare Verantwortlichkeiten und eine professionelle Kommunikationsstrategie. Unternehmen, die heute schon ein funktionierendes Schwachstellenmanagement betreiben, sind im Vorteil. Für alle anderen ist jetzt der richtige Zeitpunkt, dies strukturiert aufzubauen. Wer dies nicht tut, riskiert mehr als regulatorische Sanktionen. Der Vertrauensverlust bei Kunden, Integratoren und Partnern kann schwerer wiegen als jedes Bußgeld.

Nehmen Sie sich daher jetzt die Zeit für eine ehrliche Bestandsaufnahme. Prüfen Sie, welche Anforderungen Sie bereits erfüllen und wo noch Handlungsbedarf besteht. Gerne unterstützen wir Sie mit unserem CRA-Workshop. Praxisnah, kompakt und mit klarem Fahrplan für die Umsetzung.