Software

Software ist nach Artikel 3 Nummer 4 des Cyber Resilience Acts (CRA) der Teil eines elektronischen Informationssystems, der aus Computercode besteht. Die Verordnung beschreibt Software damit nicht als eigenständige Sache, sondern als Bestandteil eines Systems.

Aus der Definition allein folgt keine Pflicht. Sie entscheidet aber darüber, auf welchem Weg ein Erzeugnis in den Anwendungsbereich gerät, wie die CE-Kennzeichnung anzubringen ist und welche Erleichterungen der CRA ausschließlich für Software vorsieht.

Was der Begriff einschließt

Der Wortlaut kennt keine Untergrenze und keine Formvorgabe. Er nennt zwei Merkmale: Der Gegenstand muss Teil eines elektronischen Informationssystems sein, und er muss aus Computercode bestehen. Firmware in einem Mikrocontroller erfüllt das ebenso wie ein Betriebssystem, ein Gerätetreiber, eine Bibliothek, eine mobile Anwendung oder ein Skript.

Was „Computercode“ ist, definiert der CRA nirgends. Aus dem Begriff lässt sich deshalb weder eine Unterscheidung zwischen Quelltext und Maschinencode noch eine zwischen kompilierter und interpretierter Ausführung herleiten. Auf die Auslieferungsform kommt es ebenso wenig an, ob als Download, auf einem Datenträger oder bereits auf dem Gerät installiert.

Das Gegenstück steht in Nummer 5. Hardware ist dort ein physisches elektronisches Informationssystem, das digitale Daten verarbeiten, speichern oder übertragen kann, oder Teile eines solchen Systems. Beide Begriffe beschreiben also Teile desselben Systems, der eine den körperlichen, der andere den codierten.

Drei Rollen, in denen der CRA Software erfasst

Pflichten knüpfen nie an Software als solche an, sondern an die Rolle, in der sie auf den Markt gelangt:

• Als eigenes Produkt. Artikel 3 Nummer 1 beschreibt das Produkt mit digitalen Elementen als Software- oder Hardwareprodukt und dessen Datenfernverarbeitungslösungen. Ein Softwareprodukt steht damit gleichberechtigt neben einem Gerät.
• Als Komponente. Nach Artikel 3 Nummer 6 ist eine Komponente Software oder Hardware, die für die Integration in ein elektronisches Informationssystem bestimmt ist. Wird eine Softwarekomponente getrennt in den Verkehr gebracht, ist sie nach Nummer 1 selbst ein Produkt mit digitalen Elementen.
• Als Datenfernverarbeitungslösung. Nach Artikel 3 Nummer 2 zählt dazu entfernt stattfindende Datenverarbeitung, für die eine Software vom Hersteller selbst oder unter dessen Verantwortung konzipiert und entwickelt wird und ohne die das Produkt eine seiner Funktionen nicht erfüllen könnte.

Die dritte Rolle zieht zugleich die Grenze nach außen. Erwägungsgrund 12 stellt klar, dass Cloud-Dienste, die außerhalb der Verantwortung eines Herstellers entworfen und entwickelt wurden, nicht in den Anwendungsbereich fallen. Für Cloud-Computing-Dienste und Cloud-Dienstmodelle wie SaaS, PaaS und IaaS gilt stattdessen die Richtlinie (EU) 2022/2555, die NIS-2-Richtlinie. Derselbe Erwägungsgrund hält fest, dass Einrichtungen, die Cloud-Computing-Dienste in der Union erbringen, in deren Anwendungsbereich fallen, wenn sie als mittlere Unternehmen im Sinne der Empfehlung 2003/361/EG gelten oder die dort festgelegten Schwellenwerte überschreiten.

CE-Kennzeichnung ohne Gehäuse

Software hat keine Oberfläche, auf der sich ein Zeichen dauerhaft anbringen ließe. Artikel 30 Absatz 1 regelt diesen Fall eigens. Bei Produkten mit digitalen Elementen in Form von Software wird die CE-Kennzeichnung entweder auf der EU-Konformitätserklärung nach Artikel 28 oder auf der das Softwareprodukt begleitenden Website angebracht. Fällt die Wahl auf die Website, muss der betreffende Abschnitt für Verbraucher leicht und direkt zugänglich sein.

Herstellung, obwohl nichts gefertigt wird

Die Konformitätsbewertungsmodule des CRA prüfen die Konzeptions-, Entwicklungs- und Herstellungsphase. Bei Software fällt die Herstellungsphase im gewohnten Sinn weitgehend weg. Erwägungsgrund 92 löst das auf. Kompilieren, Zusammenfügen zu Versionen, Packen, Bereitstellen zum Herunterladen und Kopieren auf physische Datenträger gelten als Tätigkeiten, die dem Herstellungsprozess gleichkommen. Ihre Build- und Release-Strecke ist damit Prüfgegenstand und nicht Beiwerk.

Die Sonderregel für Softwareversionen

Softwareentwicklung verläuft in Versionen, und jede wesentlich geänderte Version ist ein erneutes Inverkehrbringen. Ohne Sonderregel müsste ein Hersteller jede je ausgelieferte Version weiter mit Sicherheitsaktualisierungen versorgen.

Artikel 13 Absatz 10 begrenzt das. Hat ein Hersteller nacheinander wesentlich geänderte Versionen eines Softwareprodukts in den Verkehr gebracht, darf er die Erfüllung der Anforderung aus Anhang I Teil II Nummer 2, also das unverzügliche Behandeln und Beheben von Schwachstellen einschließlich der Bereitstellung von Sicherheitsaktualisierungen, auf die zuletzt in den Verkehr gebrachte Version beschränken. Daran hängen zwei Bedingungen. Nutzer der früheren Version müssen kostenlos Zugang zur zuletzt in den Verkehr gebrachten Version haben, und ihnen dürfen keine zusätzlichen Kosten für die Anpassung der Hardware- und Softwareumgebung entstehen, in der sie die Originalversion verwenden.

Erwägungsgrund 40 nennt als Beispiel die Aufrüstung eines Desktop-Betriebssystems, die keine neue Hardware verlangt, also weder eine schnellere Zentraleinheit noch mehr Speicher. Er stellt zugleich klar, dass der Hersteller die übrigen Anforderungen an die Behandlung von Schwachstellen während des Unterstützungszeitraums weiter erfüllen soll. Eine Strategie für die koordinierte Offenlegung und Vorkehrungen für den Informationsaustausch über mögliche Schwachstellen sollen danach für alle nachfolgenden, wesentlich geänderten Versionen des in den Verkehr gebrachten Softwareprodukts gelten. Ob eine Aktualisierung diese Schwelle überhaupt erreicht, richtet sich nach der wesentlichen Änderung.

Testversionen und alte Archive

Zwei weitere Vorschriften gelten ausdrücklich nur für Software. Nach Artikel 4 Absatz 3 dürfen die Mitgliedstaaten die Bereitstellung unfertiger Software nicht verhindern, die dem CRA nicht entspricht, sofern sie nur für einen begrenzten, für Testzwecke erforderlichen Zeitraum bereitgestellt wird und eine sichtbare Kennzeichnung deutlich darauf hinweist, dass sie der Verordnung nicht entspricht und außer zu Testzwecken nicht auf dem Markt verfügbar sein wird. Erwägungsgrund 37 nennt Alpha-, Beta- und Vorabversionen, erwartet eine Risikobewertung vor der Freigabe und hält fest, dass Nutzer nicht zu einer Aktualisierung auf reine Testversionen gezwungen werden sollen. Für Sicherheitsbauteile im Sinne anderer Harmonisierungsrechtsvorschriften der Union gilt diese Ausnahme nach Artikel 4 Absatz 4 nicht.

Artikel 13 Absatz 11 erlaubt außerdem öffentliche Softwarearchive, die den Zugang zu historischen Versionen erleichtern. Bedingung ist, dass die Nutzer klar und in leicht zugänglicher Form über die Risiken der Verwendung nicht unterstützter Software informiert werden.