Sorgfaltspflicht bei Komponenten Dritter

Die Sorgfaltspflicht bei Komponenten Dritter steht in Artikel 13 Absatz 5 des Cyber Resilience Acts (CRA). Hersteller müssen danach die gebotene Sorgfalt walten lassen, wenn sie von Dritten bezogene Komponenten in ihre Produkte mit digitalen Elementen integrieren, sodass diese Komponenten die Cybersicherheit des Produkts nicht beeinträchtigen. Ausdrücklich eingeschlossen ist freie und quelloffene Software, die nicht im Rahmen einer Geschäftstätigkeit auf dem Markt bereitgestellt wurde.

Der Absatz beginnt mit der Wendung „Für die Zwecke der Erfüllung der in Absatz 1 festgelegten Pflicht“. Die Sorgfalt ist damit kein eigenständiges Ziel, sondern das Mittel, mit dem ein Hersteller die grundlegenden Cybersicherheitsanforderungen auch für die Teile einhält, die er nicht selbst geschrieben hat. Auf die Art der Komponente kommt es dabei nicht an. Der Wortlaut unterscheidet nicht zwischen Software und Hardware, und Artikel 13 Absatz 6 spricht ausdrücklich von einer Software- oder Hardware-Änderung.

Vier Prüfungen, die Erwägungsgrund 34 benennt

Der verfügende Teil sagt, dass Sorgfalt zu walten hat, aber nicht, worin sie besteht. Diese Lücke füllt Erwägungsgrund 34. Er nennt vier Maßnahmen, von denen je nach Lage eine oder mehrere Berücksichtigung finden sollten. Verbindlich angeordnet ist keine davon, denn ein Erwägungsgrund ist keine Vorschrift:

• gegebenenfalls prüfen, ob der Hersteller der Komponente die Konformität mit dem CRA nachgewiesen hat, unter anderem durch die Kontrolle, ob die Komponente bereits die CE-Kennzeichnung trägt
• prüfen, ob die Komponente regelmäßig Sicherheitsaktualisierungen erhält, etwa anhand der bisher erschienenen
• prüfen, ob die Komponente frei von Schwachstellen ist, die in der Europäischen Schwachstellendatenbank oder in anderen öffentlich zugänglichen Datenbanken registriert sind
• zusätzliche Sicherheitsprüfungen durchführen

Den Maßstab gibt derselbe Erwägungsgrund vor. Der angemessene Umfang der Sorgfalt richtet sich nach Art und Ausmaß des Cybersicherheitsrisikos, das mit einer bestimmten Komponente verbunden ist. Eine Bibliothek, die Datumsangaben formatiert, und ein TLS-Stack verlangen deshalb nicht dieselbe Prüftiefe.

Ohne Bestandsverzeichnis keine Sorgfalt

Geprüft werden kann nur, was bekannt ist. Anhang I Teil II Nummer 1 verlangt deshalb, Schwachstellen und Komponenten des Produkts zu ermitteln und zu dokumentieren, unter anderem durch Erstellung einer Software-Stückliste (SBOM) in einem gängigen maschinenlesbaren Format. Als Umfang nennt die Verordnung „zumindest die obersten Abhängigkeiten“.

Das Wort „zumindest“ ist wörtlich zu nehmen. Die oberste Ebene ist die Untergrenze der Stückliste, nicht die Grenze der Sorgfaltspflicht. Für diese nennt der CRA gar keine Tiefe. Sie folgt dem Risiko, und das steckt häufig in einer Bibliothek, die erst über zwei Zwischenstufen ins Produkt gelangt.

Was bei einem Fund zu geschehen hat

Artikel 13 Absatz 6 regelt den Fall, dass ein Hersteller eine Schwachstelle in einer eingebauten Komponente feststellt. Drei Schritte gehören dann zusammen:

• Meldung an die Person oder Einrichtung, die die Komponente herstellt oder wartet
• Behandlung und Behebung der Schwachstelle nach den Anforderungen aus Anhang I Teil II
• Weitergabe des Codes oder der Unterlagen an diese Stelle, wenn eine eigene Software- oder Hardware-Änderung entwickelt wurde, gegebenenfalls in maschinenlesbarem Format

Bemerkenswert ist der dritte Schritt. Er verpflichtet den Hersteller, eine selbst entwickelte Korrektur an die Quelle zurückzugeben, statt sie im eigenen Produkt zu behalten. Damit endet die Sorgfalt auch nicht mit der Entwurfsphase. Nach Erwägungsgrund 34 gelten die Pflichten zum Umgang mit Schwachstellen für das Produkt in seiner Gesamtheit, einschließlich aller integrierten Komponenten, beim Inverkehrbringen ebenso wie über den gesamten Unterstützungszeitraum.

Der Sonderfall quelloffene Software

Bei freier und quelloffener Software greift die übliche Lieferkettenlogik nicht. Wer eine nicht kommerziell bereitgestellte Bibliothek einbaut, hat keinen Vertragspartner, an den sich eine Anforderung weiterreichen ließe, und in aller Regel auch keine Konformitätserklärung vor sich. Artikel 13 Absatz 5 nimmt diesen Fall trotzdem ausdrücklich in die Sorgfaltspflicht hinein.

Artikel 25 ist die Antwort darauf. Er ermächtigt die Kommission, durch delegierte Rechtsakte freiwillige Programme zur Bescheinigung der Sicherheit einzuführen, mit denen Entwickler, Nutzer und andere Dritte die Konformität quelloffener Produkte bewerten können. Der Artikel schafft diese Programme nicht, er erlaubt sie nur. Solange keines besteht, bleibt die Bewertung beim integrierenden Hersteller.

Die CE-Lücke der ersten Jahre

Die erste der vier Prüfungen wird anfangs selten weiterhelfen. Der CRA gilt ab dem 11. Dezember 2027, und nach Artikel 69 Absatz 2 unterliegen vorher in den Verkehr gebrachte Produkte seinen Anforderungen erst dann, wenn sie danach eine wesentliche Änderung erfahren. Artikel 69 Absatz 3 nimmt davon allein die Meldepflichten des Artikels 14 aus, die für alle Produkte im Anwendungsbereich gelten. Viele eingebaute Komponenten werden auf Jahre hinaus keine CE-Kennzeichnung nach dieser Verordnung tragen.

Erwägungsgrund 35 spricht das offen an: In einem solchen Fall sollte der Hersteller seiner Sorgfaltspflicht auf andere Weise nachkommen. Welche Weise das ist, lässt die Verordnung offen. In der Praxis bleiben die anderen drei Maßnahmen übrig, also der Verlauf der Sicherheitsaktualisierungen, der Abgleich mit Schwachstellendatenbanken und eigene Prüfungen.

Wie sich Sorgfalt belegen lässt

Eine eigene Dokumentationsform schreibt der CRA für die Sorgfaltspflicht nicht vor. Artikel 13 Absatz 7 verlangt aber, alle relevanten Cybersicherheitsaspekte des Produkts systematisch und in einer der Art der Cybersicherheitsrisiken angemessenen Weise zu dokumentieren, einschließlich der Schwachstellen, von denen der Hersteller Kenntnis erlangt, und aller von Dritten bereitgestellten einschlägigen Informationen. Wer seine Prüfungen je Komponente festhält, erfüllt beides in einem Zug.

Der Aufwand hat einen handfesten Grund. Verstöße gegen Artikel 13 fallen nach Artikel 64 Absatz 2 in die obere Bußgeldstufe, vorgesehen sind bis zu 15 000 000 EUR oder, bei Unternehmen, bis zu 2,5 % des gesamten weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres, je nachdem, welcher Betrag höher ist. Hinzu kommt Artikel 13 Absatz 25. Danach kann die Gruppe für administrative Zusammenarbeit (ADCO) für bestimmte Kategorien von Produkten eine unionsweite Bewertung der Abhängigkeit von Softwarekomponenten beschließen. Zu diesem Zweck können die Marktüberwachungsbehörden die Hersteller dieser Kategorien auffordern, ihre Software-Stückliste vorzulegen.