Physische Produkte werden über nahezu alle Branchen hinweg digitalisiert, indem sie mit integrierter Software ausgestattet werden. Dabei mag es lediglich um eine erleichterte Steuerungsmöglichkeit durch den Nutzer gehen – etwa via App –, vielfach steht aber eine umfassende Vernetzung des Produkts mit anderen Komponenten und der Außenwelt im Vordergrund. Nicht selten kommt der Softwarekomponente hierbei eine sicherheitsrelevante Funktion zu, und zwar nicht nur hinsichtlich personenbezogener Daten der Nutzer, sondern auch hinsichtlich sicherheitsrelevanter Funktionalitäten des Produkts selbst. So trifft Software in autonom gesteuerten Fahrzeugen oder Robotern wesentliche Fahrentscheidungen oder ist in industriellen Anlagen oder Medizinprodukten für die Steuerung sicherheitsrelevanter Funktionen verantwortlich.
Teilweise entwickeln Hersteller des physischen Gesamtprodukts die integrierte Software selbst. Der in der Praxis vorwiegend anzutreffende Fall ist aber, dass die Software von einem externen Dritten eingekauft wird. Dieser kann selbst wiederum auch lediglich als Händler fungieren und die Software – oder Teile davon – von weiteren Dritten beziehen. Auch können einzelne Leistungen, etwa die Implementierung von Sicherheitsfunktionen oder die Durchführung von Tests, an weitere spezialisierte Dienstleister ausgelagert sein. Der für eine sicherheitsrelevante Fehlfunktion tatsächlich verantwortliche Leistungserbringer kann also der direkte Vertragspartner des Endgeräteherstellers sein – ebenso gut aber auch ein weiteres Glied in der Lieferkette, das zum Endgerätehersteller keine unmittelbare Vertragsbeziehung unterhält.
Die Einschaltung von Subunternehmern zur Implementierung von Software in das eigene Endprodukt einschließlich aller damit verbundenen weiteren Aufgaben entbindet jedoch den Hersteller des Endprodukts nicht von seiner eigenen produkthaftungs- und produktsicherheitsrechtlichen Verantwortung. Umso wichtiger ist es, dass sich Endproduktehersteller potentielle Schadensszenarien frühzeitig vergegenwärtigen. Dazu gehört nicht zuletzt, die involvierten Subunternehmer im Schadensfall zur schnellen Bereitstellung von Abhilfemaßnahmen – etwa in Form von Patches – heranziehen zu können und zu prüfen, ob eine Regressnahme beim verantwortlichen Subunternehmer möglich ist, wenn erforderliche Feldmaßnahmen durchgeführt worden sind.
Cybersicherheitslücke erfordert Korrekturmaßnahme im Feld
Die Problematik soll am Beispiel eines Cybersicherheitsmangels eines beliebigen Produkts verdeutlicht werden: Wird nach dem Inverkehrbringen eine sicherheitsrelevante Lücke bekannt und unterschreitet das Produkt deshalb das regulatorisch geforderte Cybersicherheitsniveau, muss der Hersteller oft kurzfristig reagieren. Ausgangspunkt zur Bestimmung der regulatorischen Anforderungen ist der Cyber Resilience Act (CRA), dessen wesentliche materielle Anforderungen ab dem 11.12.2027 gelten. Produkte mit digitalen Elementen müssen risikoadäquat konzipiert, entwickelt und hergestellt werden. Sie sollen insbesondere ohne bekannte ausnutzbare Schwachstellen auf den Markt gelangen und so beschaffen sein, dass Schwachstellen durch Sicherheitsupdates behoben werden können. Während des Supportzeitraums sind erkannte Schwachstellen unverzüglich zu adressieren und zu beseitigen. Diese Pflichten treffen den Hersteller des Produkts auch dann, wenn die Schwachstelle nicht in eigener Software, sondern in einer zugelieferten Komponente liegt. Art. 13 Abs. 5 CRA verlangt ausdrücklich, bei der Integration von Komponenten Dritter die gebotene Sorgfalt walten zu lassen, damit diese die Cybersicherheit des Produkts nicht beeinträchtigen. Erwägungsgrund 34 nennt hierfür unter anderem die Prüfung des Updateverlaufs einer Komponente, den Abgleich mit Schwachstellendatenbanken und – abhängig vom Risiko – zusätzliche Sicherheitstests. Wird später eine Schwachstelle in einer integrierten Komponente entdeckt, muss der Hersteller nach Art. 13 Abs. 6 CRA zwar auch denjenigen informieren, der die Komponente herstellt oder wartet – das entbindet ihn aber nicht davon, die Schwachstelle im eigenen Produkt adressieren und beheben zu müssen.
Technisch kann eine Abstellmaßnahme vergleichsweise einfach durch ein Softwareupdate „Over-the-Air“ (OTA) vorgenommen werden. Fehlt eine entsprechende Updatearchitektur – was für sich genommen schon einen Verstoß gegen Cybersicherheitsvorgaben begründen kann, wenn nicht die Produktart an sich mit einer Updatefunktion inkompatibel ist –, können auch Feldmaßnahmen erforderlich werden. Produkte müssen dann gegebenenfalls zum Hersteller oder zu Dienstleistern zurück, damit etwa Steuergeräte neu programmiert oder Komponenten ausgetauscht werden können. Dass vermeintlich für die Misere verantwortliche Zulieferer oder Komponentenhersteller in solchen Konstellationen dem Endproduktehersteller sofort unterstützend zur Seite stehen oder gar Korrekturmaßnahmen im Feld aktiv und auf eigene Rechnung begleiten, kommt in der Praxis nur selten vor. Tatsächlich sind die beteiligten Akteure oftmals uneins, worin genau die Ursache eines im Feld aufgetretenen Problems besteht und wer sich darum zu kümmern hat. Oftmals bedarf es einer umfassenden technischen und rechtlichen Aufarbeitung, bevor Verantwortlichkeiten zugewiesen werden können. Der Hersteller des Endprodukts steht in solchen Fällen also regelmäßig selbst in der Verantwortung und ist darauf angewiesen, den verantwortlichen Beteiligten im Nachgang haftbar zu halten und Regressansprüche gegen diesen erfolgreich durchzusetzen.
Gesamtschuldnerische Haftung des Komponentenherstellers nach neuem Produkthaftungsrecht
Der Regierungsentwurf zur Umsetzung der Produkthaftungsrichtlinie (EU) 2024/2853 sieht eine gesamtschuldnerische Haftung zwischen End- und Komponentenhersteller vor, wenn eine fehlerhafte Komponente den Fehler des Gesamtprodukts verursacht (§ 15 ProdHaftG-E). Daraus folgt vor allem ein Innenausgleichsanspruch zugunsten des Endgeräteherstellers, wenn dieser im Außenverhältnis Aufwendungen getragen oder Schäden erlitten hat, die im Innenverhältnis der Softwareentwickler als eigentlicher Schadensverursacher zu ersetzen hat. Diese drohende Haftung des Komponentenherstellers kann in bestimmten Fällen Endherstellern – zumindest indirekt – dabei behilflich sein, Softwareentwickler zur Beseitigung eines Sicherheitsproblems im Feld unmittelbar zu bewegen.
Für die hier interessierende Konstellation enthält das Produkthaftungsrecht aber sowohl in seiner aktuellen als auch in seiner Entwurfsfassung eine wichtige Einschränkung: Die Produkthaftung erstreckt sich ausdrücklich nicht auf solche Schäden, die die fehlerhafte Komponente am Gesamtprodukt selbst verursacht, sondern erfasst lediglich Körper- und Gesundheitsbeeinträchtigungen, Beschädigungen nicht ausschließlich beruflich genutzter Sachen und künftig auch die Beschädigung oder Vernichtung nicht beruflich genutzter Daten. Die Limitierung des Produkthaftungsgesetzes zeigt sich bei präventiven Feldmaßnahmen besonders deutlich: Wird eine Schwachstelle entdeckt, bevor sie zu einer Körperverletzung, einer ersatzfähigen Sachbeschädigung oder einem ersatzfähigen Datenverlust geführt hat, greift das Produkthaftungsgesetz nicht. Die nach dem neuen Produkthaftungsrecht vorgesehene Komponentenhaftung gewinnt für den Regress daher vor allem dann Bedeutung, wenn die Sicherheitslücke bereits einen Drittschaden verursacht hat.
Vertragliche Regressansprüche gegen Softwarelieferanten und -entwickler
Umgekehrt folgt daraus, dass für alle anderen Konstellationen, in denen Feldmaßnahmen zur Vermeidung von Personen- oder Sachschäden beziehungsweise eines Datenverlusts erforderlich werden, eine Regressdurchsetzung über die Vertragskette der erfolgversprechendste Weg ist. Adressat ist dann in aller Regel zunächst der Vertragspartner, der die Software bereitgestellt hat, unabhängig davon, ob dieser sich selbst weiterer Entwickler bedient hat oder nicht. Zur Prüfung des Regressanspruchs kommt es zentral auf den Pflichten- und Leistungskatalog des Vertragspartners an. Welche Vertragstypologie für einen Softwarevertrag einschlägig ist, hängt dabei von seiner konkreten Ausgestaltung ab; bei individuell entwickelten Softwarelösungen, dauerhaften Supportleistungen und kombinierten Lizenz-, Entwicklungs- und Wartungsmodellen sind regelmäßig verschiedene Vertragstypen relevant und muss die vermeintlich verletzte Vertragspflicht regelmäßig gesondert eingeordnet werden.
Für einen „Cybersicherheitsregress“ ist diese Einordnung deshalb wichtig, weil nicht jede später entdeckte Sicherheitslücke ohne weiteres eine bereits bei Ablieferung vorhandene vertragliche Pflichtverletzung des Softwareentwicklers darstellen muss. Wird beispielsweise eine Software ausgeliefert, obwohl sie eine bereits bekannte, ausnutzbare Schwachstelle enthält, liegt die Annahme einer mangelhaften Leistung nahe. Problematisch sind hingegen Fälle, in denen die Software bei Ablieferung dem geschuldeten Sicherheitsniveau entsprach und gegebenenfalls erst Jahre später aufgrund neuer Angriffsmethoden, neuer Erkenntnisse oder einer zwischenzeitlich erkannten Schwachstelle sicherheitskritisch wird. Hier liegt ein signifikantes Regressrisiko. Die eigene Pflicht des Endherstellers, fortlaufend einschlägige Cybersicherheitsanforderungen zu erfüllen, kann deutlich länger reichen als die ursprüngliche vertragliche Pflicht des Softwarelieferanten. Schuldet dieser lediglich eine einmalige, mangelfreie Softwarelieferung oder endet seine Wartungs- und Updateverpflichtung nach einem bestimmten Zeitraum, kann der Hersteller in die Situation geraten, hinsichtlich erforderlicher Nachbesserungsarbeiten keine durchsetzbaren Regressansprüche zu haben. Endhersteller sind daher gut beraten, Verträge mit Softwarelieferanten dahingehend kritisch zu prüfen, dass sie ihre Rechte gegenüber dem Softwarelieferanten über die gesamte Dauer der eigenen Verantwortlichkeit durchsetzen können – gegebenenfalls auch über das gesetzliche Maß hinaus. Zugleich sollte der Softwarelieferant vertraglich nicht so weit in die Pflicht genommen werden, dass sein Versicherungsschutz auf dem Spiel steht.
Ersatzfähige Schadenspositionen
Daneben lohnt eine kritische Prüfung der Verträge mit dem Softwarelieferanten hinsichtlich der ersatzfähigen Schadenspositionen. Die Bereitstellung eines korrigierten Softwarestands kann selbst Gegenstand der Nacherfüllung sein. Soweit Kaufrecht anwendbar ist, trägt der Verkäufer gemäß § 439 Abs. 2 BGB die zum Zweck der Nacherfüllung erforderlichen Transport-, Wege-, Arbeits- und Materialkosten; bei werkvertraglicher Einordnung bestehen entsprechende Nacherfüllungspflichten unter den gesetzlichen Voraussetzungen des Selbstvornahmerechts. Zudem eröffnen die §§ 280 ff. BGB bei einer zu vertretenden Pflichtverletzung Schadensersatzansprüche.
Soweit es um die Durchführung einer Feldaktion geht, können Kosten für ein OTA-Update, für die Root-Cause-Analyse, die Integration des Patches in den Softwarestand des Gesamtprodukts, für Validierungsaktivitäten sowie das weitere Monitoring entstehen. Ist ein OTA-Update technisch nicht möglich oder nicht geboten, können Werkstattarbeitszeit, Anfahrt, Diagnose, manuelles Updaten, Ausbau und Austausch von Komponenten sowie erhebliche logistische Aufwendungen hinzukommen. Darüber hinaus treten gegebenenfalls Kosten für Händlerkommunikation, Hotlines oder die Identifikation der betroffenen Produktpopulation sowie vielfach im Zusammenhang mit der Durchführung des Rückrufs stehende Rechtsberatungskosten.
Ob all diese Positionen ersatzfähige Schadenspositionen darstellen, lässt sich nicht pauschal beantworten. Die Schadensersatzpflicht des Softwarelieferanten kann durch wirksame Haftungsbeschränkungen limitiert sein, was stets im Einzelfall zu prüfen ist. Im Anwendungsbereich deutschen Kaufrechts ist zudem der Vorrang der Nacherfüllung zu beachten: Der Käufer kann die Kosten einer eigenmächtigen Mangelbeseitigung grundsätzlich nicht schon deshalb ersetzt verlangen, weil der Verkäufer entsprechende eigene Aufwendungen erspart hat. Dem Verkäufer soll vielmehr grundsätzlich die Möglichkeit zur „zweiten Andienung“ verbleiben. Schafft der Softwarelieferant nicht unmittelbar Abhilfe und will der Endhersteller aus Gründen der Eilbedürftigkeit einen Dritten mit der Beseitigung des Mangels beauftragen, sollte er sicherstellen, durch eine angemessene Fristsetzung das Recht der zweiten Andienung gewahrt zu haben, oder prüfen lassen, ob im konkreten Fall eine Fristsetzung entbehrlich ist, sodass Kosten für die Beauftragung des Dritten beim ursprünglichen Softwarelieferanten gleichwohl regressiert werden können.
Auch sollte die sogenannte Untersuchungs- und Rügeobliegenheit gemäß § 377 HGB beachtet werden. Eine bei der üblichen Eingangskontrolle nicht erkennbare Sicherheitslücke stellt regelmäßig einen verdeckten Mangel dar, der unverzüglich gerügt werden muss, sobald er entdeckt wird.
Fazit
Die europäische Cybersecurity-Regulierung verschärft die Verantwortung des Herstellers für das Gesamtprodukt – sie verlagert die daraus entstehenden Kosten aber nicht automatisch auf denjenigen Zulieferer, in dessen Verantwortungsbereich die Sicherheitslücke technisch entstanden ist. Wirtschaftlich entscheidend ist der nach Durchführung der erforderlichen Abhilfemaßnahmen folgende Regress. Um hier keine Überraschungen zu erleben, sollten Verträge mit Softwarelieferanten und -entwicklern vorab umfassend geprüft werden.
