Die produzentenrechtlichen Verkehrssicherungspflichten von Softwareproduzenten

(1)

Die produzentenrechtlichen Verkehrssicherungspflichten von Softwareproduzenten

Daniel Wittig

Nomos

Schriften zum Medien- und Informationsrecht 50

(2)

Schriften zum Medien- und Informationsrecht

herausgegeben von

Prof. Dr. Boris P. Paal, M.Jur.

Band 50

BUT_Wittig_7042-7.indd 2

BUT_Wittig_7042-7.indd 2 23.12.20 12:4923.12.20 12:49

(3)

Daniel Wittig

Die produzentenrechtlichen Verkehrssicherungspflichten von Softwareproduzenten

Nomos

(4)

D 6

1. Auflage 2021

© Nomos Verlagsgesellschaft, Baden-Baden 2021. Gesamtverantwortung für Druck und Herstellung bei der Nomos Verlagsgesellschaft mbH & Co. KG. Alle Rechte, auch die des Nachdrucks von Auszügen, der fotomechanischen Wiedergabe und der Über- setzung, vorbehalten. Gedruckt auf alterungsbeständigem Papier.

Onlineversion Nomos eLibrary

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Zugl.: Münster, Univ., Diss., 2020 ISBN 978-3-8487-7042-7 (Print) ISBN 978-3-7489-1091-6 (ePDF)

BUT_Wittig_7042-7.indd 4

BUT_Wittig_7042-7.indd 4 23.12.20 12:4923.12.20 12:49

(5)

Vorwort

Die vorliegende Arbeit wurde im August 2020 von der rechtswissenschaft- lichen Fakultät der Westfälischen Wilhelms-Universität Münster (WWU) als Dissertation angenommen. Sie entstand neben meiner beruflichen Tä- tigkeit als Rechtsanwalt in einer mittelständischen Wirtschaftskanzlei in Paderborn und unter Betreuung durch meinen Doktorvater Herrn Prof.

Dr. Hoeren, dem Direktor des Instituts für Informations-, Telekommuni- kations- und Medienrecht (ITM) an der WWU. Ihm Danke ich u. a. für sei- ne teils harsche Kritik, die zur Fokussierung der Arbeit auf das Wesentli- che führte und so maßgeblich zum Gelingen dieser beitrug. Ebenfalls danke ich Herrn Prof. Dr. Fabian Gieseke vom Lehrstuhl Maschinelles Lernen und Data Engineering für die rasche Erstellung des Zweitgutachtens. Mein Dank gilt auch meinen Arbeitskollegen, die Rücksicht auf meine nebenbe- rufliche Promotion nahmen und mich nach Möglichkeit unterstützen.

Während meiner Zeit im Referendariat wurde ich von einem meiner Mentoren auf die Problematik der Haftung von Softwareproduzenten auf- merksam gemacht. Ich musste feststellen, dass wir die für die Haftung wesentlichen Verkehrssicherungspflichten kaum bestimmen konnten. Ab diesem Zeitpunkt stand für mich fest, dass ich einen wissenschaftlichen Beitrag zu diesem Thema leisten wollte, um an der Lösung des Problems mitzuwirken.

Mein ganz besonderer Dank geht an meine Eltern, Petra und Werner Tanger, sowie an meine Ehefrau Katarina. Meine Eltern unterstützten stets vorbehaltlos meinen Lebensweg und die Entscheidungen, die ich auf diesem getroffen habe. Sie ermöglichten mir meine Ausbildung, welche die Basis für meine persönliche und berufliche Entwicklung geworden ist.

Nur durch Sie konnte ich mich immer auf meine Ziele konzentrieren, ohne mir Sorgen machen zu müssen. Meine Frau Katarina, welche seit dem Jahr 2016 an meiner Seite ist, gibt mir darüber hinaus in jeder Lebenslage ein unglaubliches Maß an Unterstützung, Rückhalt und Liebe. Ohne ihren Zuspruch und ihr Durchhaltevermögen hätte ich diese Arbeit wohl nicht vollenden können. All dies hat im wesentlichen Maße zum Gelingen dieser Arbeit beigetragen.

Paderborn, im November 2020 Daniel Wittig

5

(6)

(7)

Inhaltsverzeichnis

Einleitung

A. 19

Die steigende Bedeutung von Software für Wirtschaft und Gesellschaft

I.

20 Sicherheit von Software als gesamtgesellschaftliches

deliktsrechtliches Problem II.

21 Die Herstellung fehlerfreier Software unter ökonomischen

Gesichtspunkten III.

23 Verkehrssicherungspflichten – Kernstück der

Produzentenhaftung IV.

26 Begriffsdefinitionen

B. 28

Software und Softwareproduzent

I. 28

Daten

II. 29

IT-Sicherheit und Datensicherheit

III. 30

Der Begriff der IT-Sicherheit

1. 30

Schutzgüter der IT-Sicherheit

a) 32

Verfügbarkeit

aa) 32

Vertraulichkeit

bb) 32

Integrität

cc) 33

Authentizität

dd) 33

Interdependenz der Schutzgüter

ee) 33

Bedeutung der IT-Sicherheit

b) 34

Abgrenzung der IT-Sicherheit von der Produktsicherheit

c) 34

Ableitung des Begriffs der Datensicherheit

2. 35

Abgrenzung der Datensicherheit vom Datenschutz

3. 35

Schwachstelle

IV. 36

Deliktische Haftungsrisiken und die Produzentenhaftung

C. 39

Deliktisches Haftungsrisiko für Softwareproduzenten

I. 39

Zweiseitige Inanspruchnahme möglich

1. 39

Steigerung der Angriffsfläche durch IT und Vernetzung

2. 41

Bisherige Tätigkeit des Gesetzgebers

3. 41

7

(8)

Die Entwicklung der Produzentenhaftung

II. 42

Die Schaffung der Produzentenhaftung

1. 42

Verletzung einer Verkehrssicherungspflicht

2. 44

Entwicklung von Beweiserleichterungen

3. 45

Weiterhin offene Fragestellungen im Deliktsrecht

III. 45

Entscheidungen autonomer Systeme

1. 46

Daten als Rechtsgutverletzung

2. 47

Kausalitätsprobleme

3. 47

Verschuldensnachweis

4. 48

Bestimmung von Verkehrssicherungspflichten

5. 49

Versicherbarkeit der Haftungsrisikos

IV. 50

Geltung der Produzentenhaftung für die Softwareerstellung

V. 50

Die geltenden Verkehrssicherungspflichten

D. 52

Konstruktionspflichten

I. 55

Sicherheitserwartungen des Verkehrs

1. 56

Erkennbarkeit des Fehlers bei einem Inverkehrbringen

2. 57

Abgrenzung zum Entwicklungsfehler

3. 57

Fabrikationspflichten

II. 58

Instruktionspflichten

III. 59

Erkennbarkeit der Gefahr bei einem Inverkehrbringen

1. 60

Inhalt und Ausgestaltung der Instruktionspflichten

2. 60

Umfang der Instruktionspflichten

3. 61

Produktbeobachtungspflichten

IV. 62

Haftungsgrund der Produktbeobachtungspflichten

1. 64

Umfang der Produktbeobachtungspflicht

2. 64

Zeitraum statt Zeitpunkt der Pflichterfüllung

3. 65

Ende der Produktbeobachtungspflichten

4. 65

Handlungspflicht bei Entdeckung eines Fehlers

5. 66

Warnpflicht

a) 67

Gefahrverdacht

b) 67

Konstruktionsänderung

c) 68

Rückrufverpflichtung

d) 69

Äquivalenz- vs. Integritätsinteresse

aa) 69

Cheapest Cost Avoider

bb) 70

Neben Rücknahme auch Reparatur

cc) 72

Bestimmung im Einzelfall notwendig

dd) 73

Inhaltsverzeichnis

8

(9)

Kein subjektiver Anspruch des Nutzers

ee) 74

Die Ausgestaltung der Verkehrssicherungspflichten für Softwareproduzenten

E.

75 Keine Entlastung bei Eingriffen durch Hacker

I. 75

Maßstab für die Ermittlung der Verkehrssicherungspflichten

II. 77

Einflussfaktor der Verkehrserwartung an Software

1. 78

Einzelfallentscheidung – Kriterium des Absatzmarktes

a) 79

Einzelfallentscheidung – Kriterium des Nutzerkreises

b) 80

Einflussfaktor „aktueller Stand von Wissenschaft und Technik“

2.

80 Abgrenzung vom Stand der Technik

a) 80

Verwendung unbestimmter Rechtsbegriffe

aa) 81

Inhaltliche Unterscheidung

bb) 82

Heranziehung des Standes von Wissenschaft und Technik

b) 83

Konkretisierung des Standes von Wissenschaft und Technik

c)

85 Bildung des Standes von Wissenschaft und Technik in der IT-Branche

d)

85 Schwerpunkt Ausland

aa) 86

Beeinflussung durch Marktführer

bb) 86

Erweiterung der Einflussfaktoren

cc) 87

Einfluss technischer Standards und Zertifizierungen auf den aktuellen Stand von Wissenschaft und Technik e)

88 Technische Standards

aa) 89

Technische Standards sind keine verbindlichen Rechtsnormen

bb)

89 Problem der Bestimmtheit eines technischen

Standards cc)

90 Praktische Bedeutung von technischen Standards

dd) 91

Keine Entlastung durch Einhaltung technischer Standards

(1)

91 Technische Standards als Ansatzpunkt der

Konkretisierung unbestimmter Rechtsbegriffe (2)

92 Änderung des Standes von Wissenschaft und Technik nach einem Inverkehrbringen

f)

93 Einhaltung des Standes von Wissenschaft und Technik

durch Zertifizierung g)

93 Begriff der Zertifizierung

aa) 94

9

(10)

Keine Entlastung durch eine Zertifizierung

bb) 94

Statische Zertifikate

(1) 94

Ausnahme: Öffentliches Recht

(2) 95

Einfluss von Zertifizierungen auf Verkehrssicherungspflichten h)

95 Besonderheiten im IT-Sektor

i) 95

Common Criteria – aktueller Einfluss und zukünftige Möglichkeiten

aa)

97 Ausgestaltung der Common Criteria

(1) 98

Common Criteria als Selbstverpflichtung

(2) 99

Vorteile der Common Criteria für die Produzenten

(3)

99 Hürden für die Produzenten

(4) 100

Zukünftige Möglichkeiten der Common Criteria

(5) 100

Protection Profiles

bb) 101

Aufbau der Protection Profiles

(1) 102

Anwendungsbereich einzelner Protection Profiles

(2) 102

Zukünftige Möglichkeiten der Protection Profiles

(3) 103

Security Design Principles

cc) 103

Branchenspezifische Standards (Beispiel: PCI-DSS)

dd) 104

Secure Coding Guidelines

ee) 104

Einfluss von unbekannten Zertifikaten auf die

Verkehrssicherungspflichten von Softwareproduzenten ff)

105 Bestehen unbekannter Zertifikate

(1) 105

Auswirkungen von im Verkehr unbekannten Zertifikaten

(2)

106 Einflussfaktor Cybersecurity Act

3. 107

Allgemeine Ziele

a) 107

Sicherheitsziele

b) 108

Harmonisierung

aa) 109

Fragmentierung

bb) 110

Konkrete Sicherheitsziele

cc) 110

Ausgestaltung des Zertifizierungsverfahrens

c) 111

Keine Einführung operativer Zertifizierungssysteme

aa) 111

Rückgriff auf technische Normen

bb) 111

Unterschiedliche Ansätze und Sicherheitsstufen für die Schemata

cc)

112 Freiwilligkeit der Zertifizierung

dd) 112

Rolle der Cybersicherheitsbehörde ENISA

d) 113

10

(11)

Auswirkungen der Verordnung auf Softwareproduzenten – Erhöhung des Sicherheitsstandards

e)

114 Einflussfaktor DS-GVO auf die Verkehrssicherungspflicht

4. 115

Datenschutz ungleich Datensicherheit

a) 116

Anwendungsbereich der DS-GVO

b) 116

Sachlicher Anwendungsbereich

aa) 117

Räumlicher Anwendungsbereich

bb) 118

Persönlicher Anwendungsbereich

cc) 118

Verantwortlicher

(1) 119

Auftragsverarbeiter

(2) 119

Hersteller – Softwareproduzenten

(3) 120

Mittelbare Anwendbarkeit der DS-GVO auf Softwareproduzenten

(4)

121 Hersteller als Adressat des Art. 25 DS-GVO –

Datenschutz durch Technikgestaltung (a)

Sicherheit der Verarbeitung (b)

Zertifizierungsmaßnahmen (c)

124 Bindung der Produzenten an die Pflichten der DS-GVO

c) 125

Konkretisierung der Verkehrssicherungspflichten

aa) 125

Stand von Wissenschaft und Technik

(1) 126

Diskrepanz: „Stand der Technik“ und „Stand von Wissenschaft und Technik“

(a)

127 Umsetzungserschwernis aufgrund fehlender

verbindlicher Leitlinien (b)

129 Rückgriff auf bereits bestehende Normen

unzureichend (c)

129 Erwartungshaltung der Verantwortlichen

(2) 131

Notwendigkeit der präzisen Abgrenzung bei der Verkehrserwartung

(a)

132 Keine direkte Verpflichtung über

Verkehrssicherungspflichten möglich (b)

132 Indirekte Verpflichtung

(c) 133

Zumutbarkeit

(3) 134

Zwischenfazit zu den Auswirkungen der DS-GVO

(4) 135

Verschiebung der Nachfrage

(a) 135

Keine Bußgelder, aber Schäden

(b) 136

Erste Schritte mit und durch die DS-GVO

bb) 137

Beispiel: Produktbeobachtungspflicht

(1) 137

11

(12)

Beispiel: Konstruktionspflichten

(2) 138

Beispiel: Instruktionspflichten

(3) 138

Möglichkeit der Einhaltung datenschutzrechtlicher Vorschriften

cc)

138 Die (mittelbaren) Pflichten der DS-GVO für

Softwareproduzenten d)

139 Grundsätze der Datenverarbeitung, Art. 5 DS-GVO

aa) 140

Neuausrichtung der Grundsätze der Datenverarbeitung

(1)

140 Bezugnahme auf die Sicherheit der

Datenverarbeitung (2)

141 Datenschutz durch Technikgestaltung und

Voreinstellung, Art. 25 DS-GVO bb)

142 Anforderungen der Norm

(1) 143

Privacy by Design

(a) 143

Privacy by Default

(b) 143

Organisatorische Maßnahmen

(c) 144

Umsetzung der Norm

(2) 144

Frühe Berücksichtigung der Einzelmaßnahmen

(a)

145 Die wirtschaftliche Komponente der

Umsetzung (b)

145 Datenschutz durch Technikgestaltung

(c) 146

Datenschutz durch Voreinstellung

(d) 148

Sicherheit der Verarbeitung, Art. 32 DS-GVO

cc) 149

Anforderungen der Norm

(1) 149

Umsetzung der Norm

(2) 150

Konkret benannte Maßnahmen

(a) 151

Weitere – technisch unbenannte – Maßnahmen des Art. 32 DS-GVO (b)

151 Zertifizierungsmaßnahmen, Art. 42 DS-GVO

dd) 154

Ziele der Zertifizierung

(1) 154

Zertifikat für Produzenten

(2) 154

Data Breach Notification, Art. 33 DS-GVO

ee) 156

Einflussfaktor „EU-Richtlinie über bestimmte vertragsrechtliche Aspekte der Bereitstellung digitaler Inhalte“

5.

156 Anwendungsbereich

a) 157

Updatepflicht – Mangelbegriff

b) 158

Grenze der Unverhältnismäßigkeit

c) 159

12

(13)

Gewährleistungsfrist

d) 159

Mögliche Auswirkungen auf die

Verkehrssicherungspflichten der Softwareproduzenten e)

160 Die Konstruktionspflichten der Softwareproduzenten

III. 161

Schlüsselfrage: Sind Fehler bei einem Inverkehrbringen erkennbar?

1.

164 Möglichkeit der fehlerfreien Erstellung von Software

a) 164

Falschaussage: Fehlerfreie Erstellung nicht möglich

aa) 165

Gründe für die Fehlerhaftigkeit von Software

bb) 166

Gestiegene Komplexität

(1) 167

Mehr Code, mehr Fehlermöglichkeiten

(a) 167

Erschwerung der Testbedingungen

(b) 168

Kosten für Qualitätssicherung

(2) 168

Missmanagement

(3) 169

Qualitätssicherung als Geldverschwendung

(a) 169

Fehlerhafte Zeit- und Kostenplanung

(b) 170

Lückenhafte Dokumentation

(c) 171

Wartungsverträge

(d) 171

Marktgegebenheiten

(4) 171

Nachgefragte Qualität

(a) 171

Unklare Anforderungen an Software

(b) 173

Verkürzte Produktzyklen

(c) 173

Wettbewerbsnachteil Fehlerfreiheit

(d) 174

Fehlende Cybersicherheitskenntnisse

(5) 174

Agile Programmiermethoden

(6) 175

Alterung der Software

(7) 176

Korrektur der These

b) 177

Konstruktionspflichten der Softwareproduzenten

2. 177

Keine Ausnahme von den Konstruktionspflichten

a) 178

Abschwächung der Konstruktionspflichten durch Verkehrserwartung

b)

179 Einzelne Konstruktionspflichten

c) 180

Konstruktive und analytische Qualitätssicherung

aa) 181

Organisationspflichten im Arbeitsablauf – konstruktive Maßnahmen

bb)

182 Organisation des Betriebs und des Arbeitsablaufs

(1) 182

Einsatz eines Versionsverwaltungssystems

(2) 185

Entwicklungs- und Testdokumentationen

(3) 185

Absicherung der Entwicklungsumgebung

(4) 186

Einzelfallentscheidung

(5) 186

13

(14)

Analytische / Technische Prüfpflichten

cc) 187

Automatisierte Prüfungstools (Debugging)

(1) 187

Teilautomatisierte werkzeuggestützte Analyse

(a) 188

Debugger

(b) 189

Automatisierte Prüfungstools und Big Data

(c) 190

Integrierte Entwicklungsumgebungen

(d) 191

Softwaretests – Organisation und Grundsätze

(2) 191

Testgrundsätze

(a) 192

Testorganisation

(b) 193

Testorganisation in verschiedenen Entwicklungsmodellen

(c)

195 Softwaretests – Arten und Auswahl

(3) 197

Statische und dynamische Testverfahren

(a) 198

White- und Black-Box-Tests

(b) 198

Überblick verschiedener Testarten

(c) 199

Auswahl der Tests

(d) 201

Manuelle Softwareprüfungen

(4) 203

Formen der manuellen Softwareprüfungen

(a) 204

Vorteile der manuellen Softwareprüfungen

(b) 205

Manuelles Testen als Ergänzung, nicht als Alternative

(c)

206 Nachweis der Fehlerfreiheit –

Softwareverifizierung (5)

207 Weitere mögliche Konstruktionspflichten

dd) 207

Programmierung redundanter Software

(1) 208

Updatability by Design

(2) 208

Behebung festgestellter Schwachstellen im Quellcode

(3)

210 Anpassung in laufender Produktion

(a) 210

Zeitrahmen zur Behebung der Schwachstelle

(b) 210

Vorgaben an Zulieferer

(4) 212

Zusammenfassung der einzelnen Konstruktionspflichten

3. 213

Organisatorische Pflichten

a) 213

Technische / Analytische Pflichten

b) 214

Verpflichtende Testverfahren

aa) 215

Testtechniken

bb) 216

Weitere Konstruktionspflichten

c) 217

BSIMM-Studie

d) 217

Besonderheit: OEM‑Version

4. 218

14

(15)

Die Produktbeobachtungspflichten der Softwareproduzenten

IV. 218

Verschärfung der Produktbeobachtungspflicht bei (bewusst) fehlerhafter Software

1.

219 Beobachtung der eigenen Software

2. 220

Beobachtung von Fremdsoftware

3. 220

Integrierte Produktbeobachtung

4. 222

Vorteile der integrierten Produktbeobachtung

a) 222

Integrierte Produktbeobachtung – Keine rein zukünftige Pflicht

b)

223 Anwendbarkeit neben passiver und aktiver

Produktbeobachtung c)

224 Handlungspflichten bei Entdeckung einer Gefahr

5. 224

Warnung vor Schwachstellen

a) 225

Nutzerspezifische Warnung

aa) 226

Art der Verbreitung der Warnung

(1) 227

Mitteilungsquote

(2) 227

Verständlichkeit der Warnung

(3) 228

Unzulänglichkeit einer Warnung

bb) 228

Warnung als Gefahrerhöhung

cc) 229

Mitteilungspflicht von Sicherheitsstörungen beim BSI

dd) 230

Keine Herausgabe des Quellcodes

b) 231

Softwarestilllegung mittels „Kill Switch“

c) 231

Stilllegung effektiver als Update?

aa) 232

Grenzen der Stilllegung

bb) 232

Beschränkung auf internetbasierte Software

(1) 233

Mögliche Eigentumsverletzung durch Stilllegung

(2) 233

Zwangsupdate als gleich effektives Mittel

(3) 233

Bedrohung des Nutzers allein

(4) 234

Kombination aus Kill Switch und Update

cc) 234

Erweiterte Rückruf- und Updatepflichten

d) 234

Ausgestaltung des Rückrufs bei Software

aa) 236

Verschiebung der Zumutbarkeitserwägung

bb) 236

Geringe Kosten für Update / Patch

(1) 237

Dekompilierungsverbot

(2) 239

Keine Umgehung des

Dekompilierungsverbotes durch Reverse- Engineering

(a)

240 Angewiesenheit auf den Produzenten

(b) 241

Keine generelle Rückruf-/Updatepflicht

cc) 241

Einklang mit dem Effizienzprinzip

(1) 243

15

(16)

Nachhaltige Behebung

(2) 244

Ende des Software-Supports

dd) 244

Kein subjektiver Anspruch auf Updates

ee) 245

Weitere Verkehrssicherungspflichten für Softwareproduzenten

V. 245

Fabrikationspflichten

1. 246

Instruktionspflichten

2. 247

Allgemeine Instruktionspflicht

a) 247

Erneute Instruktionspflicht nach einem Update

b) 248

Notwendigkeit zur Schaffung eines IT-Produktsicherheitsrechts oder von IT-Sicherheitsstandards

F.

249 Schaffung einer IT-Sicherheit-Grundverordnung

I. 251

Ausgestaltung und Bestandteile einer IT-Sicherheit- Grundverordnung

1.

252 Einführung als Schutzgesetz i. S. d. § 823 Abs. 2 BGB

a) 252

Einführung einer Meldepflicht

b) 253

Sanktionierung unsicherer IT-Produkte

c) 253

Updatepflicht

d) 254

Prüfstelle für IT-Produkte

e) 255

Notwendigkeit einer neuen Gesetzgebung

2. 255

Schaffung von technischen Standards

II. 256

Vorteile gegenüber Recht de lege ferenda

1. 258

Ausgestaltung und Inhalt technischer Standards

2. 259

Normungsorganisationen

a) 260

Abstufung der Pflichten

b) 261

Security by Design und Security by Default

c) 262

Kontinuierliche Weiterentwicklung

d) 264

Updatepflicht und Länge des Software-Supports

e) 265

Mehrstufige Zertifizierungen

f) 266

(Re-)Zertifizierungspflichten

g) 266

Schwachstellen veröffentlichen

h) 267

Schaffung von Standards allein genügt nicht

3. 269

Initiative der Wirtschaft – Charter of Trust

III. 270

Gründe für die Erstellung der Charter of Trust

1. 271

Kernziele der Charter of Trust

2. 271

Weitere Ziele und Maßnahmen der Charter of Trust

3. 271

Fazit bezüglich der Charter of Trust

4. 272

16

(17)

Fazit

G. 274

Literaturverzeichnis 285

17

(18)