Die Europäische Kommission erarbeitet aktuell den Entwurf einer Orientierungshilfe zur Umsetzung des Cyber Resilience Act. Der Entwurf ist auf der Website der Kommission verfügbar und in seiner aktuellen Version bereits sehr gut geeignet, wertvolle Hilfe zur Umsetzung des CRA insbesondere im Zusammenhang mit der Verwendung von Open Source in Softwareprojekten zu leisten.
Der Inhalt im Überblick
Inhalte der Orientierungshilfe
Die Orientierungshilfe umfasst grundsätzlich alle Teile des CRA. Sie enthält eine große Anzahl konkreter Beispiele dafür, was unter einem „Produkt mit digitalen Elementen“ zu verstehen ist, und was die „Bereitstellung auf dem Markt“ für Softwareprodukte oder Geräte bedeutet, die bereits vor Inkrafttreten des CRA existierten.
Sie deckt dabei alle Bereiche des CRA wie sicheres Design, Schwachstellenmanagement, Incident Response, Updates und Patches sowie Dokumentation und technische Nachweise ab.
CRA und Open Source
Wesentliche Elemente bei der Entwicklung von Softwareprodukten sind regelmäßig Open Source Produkte, meist Bibliotheken und Werkzeuge, die nicht kommerziell vermarktet werden, aber Teil von kommerziellen Produkten werden können. Die Orientierungshilfe benutzt hierfür den Begriff FOSS (free and open source software).
Der CRA bezieht sich ausdrücklich nur auf kommerzielle Produkte. Entsprechend der Regelungen im Blue Guide (Kapitel 2.2) kommt es dabei nicht darauf an, ob das Produkt gegen Zahlung eines Entgelts oder sonst wie auf den Markt kommt. Entscheidend ist die kommerzielle Absicht des Anbieters. Zusammen mit der Verwendung von FOSS ist die Bandbreite der möglichen Konstellationen enorm.
Die Orientierungshilfe unterscheidet deshalb in Bezug auf die Verantwortlichkeit für FOSS sehr genau zwischen dem (bisher schon bekannten) Maintainer, der sich außerhalb der Anwendung des CRA befindet, und dem Manufacturer sowie dem Open Source Software Steward, die beide innerhalb der Regeln des CRA agieren.
Open Source und verantwortliche Rollen
Die einfachste Rolle ist der Manufacturer:
Der Manufacturer ist eine kommerziell handelnde juristische Person. Er entwickelt Software, um diese Software selbst oder ein darauf basierendes Produkt zu verkaufen. Ob der Manufacturer seinen Sourcecode öffentlich macht oder nicht, spielt überhaupt keine Rolle. Als kommerzieller Hersteller unterliegt er dem CRA.
Ebenso einfach ist der Maintainer:
Der Maintainer ist eine nicht-kommerziell handelnde natürliche Person, die Software zur freien Verwendung entwickelt. Die Art der (nicht-kommerziellen) Lizenz, unter der der Maintainer seine Software freigibt, spielt keine Rolle, und er unterliegt nicht dem CRA.
Neu ist die Rolle des Open Source Software-Stewards:
Der Software-Steward ist immer eine juristische Person: entweder kommerziell handelnd oder eine Non-Profit-Organisation.
Als Non-Profit-Organisation stellt er FOSS zur kommerziellen Verwendung her. Er finanziert also seinen eigenen Geschäftsbetrieb daraus, erzielt aber für sich selbst keinen Ertrag. Der häufigere Fall dürfte der sein, dass der Software-Steward FOSS zwar kostenfrei bereitstellt, sein Geschäftsmodell aber darauf beruht, technischen Support wie Patches und Erweiterungen für diese Software zu erbringen. In beiden Konstellationen findet der CRA Anwendung.
Allerdings: Wird die Software frei abgegeben, und der Entwickler bietet zu seiner Software eigenständig buchbare Schulungen an, dann ist nur die Schulung das kommerzielle Produkt. Die Software selbst wird nicht kommerziell bereitgestellt und fällt nicht unter den CRA.
Bestimmung der Verantwortlichkeit
Da ein Maintainer von FOSS niemals wissen kann, wer sein Projekt möglicherweise in ein eigenes System integriert und (entsprechend der zugrundeliegenden Lizenz) kommerziell vermarktet, kann er niemals für die Sicherheit seiner Software verantwortlich gemacht werden.
Die Verantwortung liegt im einfachen Fall bei dem Manufacturer. Das ist derjenige, der FOSS in seine Anwendung integriert und auf den Markt bringt. Hier hat sich mit der Einführung des CRA tatsächlich nichts an der bisherigen Lage verändert: Der Hersteller kann seine Verantwortung nicht delegieren. Es ist jedoch die neue Verpflichtung hinzugekommen, eine umfassende Risikobewertung aller eingesetzten Komponenten vorzunehmen und das Verfahren zur Absicherung der Vollständigkeit und Korrektheit dieser Risikobewertung komplett zu dokumentieren.
Interessant ist hier die Rolle des Software Stewards:
Die Verantwortlichkeit des Stewards ist immer auf ein bestimmtes Produkt bezogen sowie die Intention, mit der der Steward dieses Produkt entwickelt.
Es hängt sehr davon ab, welche Art von Services der Steward für seine FOSS erbringt. Es könnte sein, dass die Software zu ihrem Betrieb Services benötigt, die der Steward in seiner Infrastruktur erbringt. Dann unterliegt der Steward mit seiner Infrastruktur selbst dem CRA. Bietet er aber für seine Software nur Schulung oder Hilfestellung an, bleibt die Verantwortung beim Manufacturer.
Es kann deshalb sein, dass ein Steward mit einer FOSS unter den CRA fällt, mit einer anderen aber nicht.
Der Nutzen für die Umsetzung des CRA
Die Regelungen des CRA sind umfangreich und komplex. Es reicht nicht mehr aus, die ISO 27001 verstanden und zertifiziert zu haben, die Rechtslage wird vielfältiger. An dieser Stelle liefert die Orientierungshilfe zur Umsetzung des CRA bereits jetzt mit dem vorliegenden Entwurf einen wertvollen, lesenswerten Beitrag.