Die neue Produkthaftungs-Richtlinie der EU - Ist es das Ende freier Software?

[Jens01]

Und zu den USA, da gibt es ein anderes Wirtschaftssystem.
Dort kannst Du alles auf den Markt werfen, was und wie Du willst. Sollte sich aber irgendwann herausstellen, dass Dein Produkt nicht funktioniert, dann werden erhebliche Strafen fällig. Beispiele sind VW mit dem Abgasskandal und Bayer mit Roundup (monsanto)

[Rollo62]

Ja natürlich.
Es gibt aber fünf große Unterschiede, mindestens ...

1. Ein Ziegel, Fenster, Heizung, Mörtel und andere Komponenten sind in der Regel nicht so komplex und fehleranfällig und können den Zustand kaum dynamisch verändern.
2. Ein Ziegel, Fenster, Heizung, Mörtel und andere Komponenten werden in der Regel nicht ständig aktiv von Hackern angegriffen
3. Ein Ziegel, Fenster, Heizung, Mörtel und andere Komponenten stellen in der Regel keine fatalen Sicherheitsrisiken dar, selbst wenn sie sich verändern
4. Ein Ziegel, Fenster, Heizung, Mörtel und andere Komponenten, selbst wenn sie gefährlich sind, werden in der Regel nur punktuell eingesetzt und nicht millionenfach im Web kopiert
5. Ein Ziegel, Fenster, Heizung, Mörtel und andere Komponenten werden in der Regel nicht Opensource als freie Komponenten angeboten, deren Hersteller hat auch immer gewerbliches Interesse und Verantwortung

[Redeemer]

Zitat von Rollo62:

3. Ein Ziegel, Fenster, Heizung, Mörtel und andere Komponenten stellen in der Regel keine fatalen Sicherheitsrisiken dar, selbst wenn sie sich verändern
4. Ein Ziegel, Fenster, Heizung, Mörtel und andere Komponenten, selbst wenn sie gefährlich sind, werden in der Regel nur punktuell eingesetzt [...]

Also es gibt recht viele Häuser mit Fenstern. Quelle: Wir verkaufen Fenster und wir haben doch so einige Kunden.

Zitat von himitsu:

Zitat:

2. Ein Ziegel, Fenster, Heizung, Mörtel und andere Komponenten werden in der Regel nicht ständig aktiv von Hackern angegriffen

Da behauptet der Specht was anderes.

Bei uns sind es Krähen, die diesen Sommer den Mörtel aus dem First gepickt haben. Die Steine sind dann runtergerollt aber zum Glück nicht auf die Autos gefallen.

[himitsu]

Drüben kannst du aber auch alles und jeden verklagen, mit exorbitanten Schadensforderungen (Milliarden Dollars)
Gut, hier sind die "Anbieter" jetzt mehr haftbar, aber wenn, dann zum Glück nicht so extrem, wie anderswo.

Es gibt Länder, da wird Taschendieben noch die Hand abgehackt (spätestens nach dem zweiten Mal unterlassen sie es freiwillig).

Wenn die hier an einer Parkbank die Nylonstrumphose aufreist, mußt du die Stadt verklagen, welcher der Park gehört, in welcher diese Bank steht, aber da drüben kannst du auch direkt die Bank verklagen.
Der Fall, als jemand Gott verklagt hatte, wegen Terrorismuß, Nötigung usw. (der bedroht dich ja ständig "wenn du nicht, dann ...", also Gewaltandrohung und auch mindestens tätlicher Angriff ala Massenmord, sowie durch ihn verursachten Inzest uvm.)

Zitat:

2. Ein Ziegel, Fenster, Heizung, Mörtel und andere Komponenten werden in der Regel nicht ständig aktiv von Hackern angegriffen

Da behauptet der Specht was anderes.

[Rollo62]

Ok, es gibt viele lustige Beispiele.
Bevor das hier aber komplett abdriftet ...

Ich wollte eigentlich nur wissen und diskutieren wie Ihr mit dem Thema umgeht.
Wie weist ihr nach, das Eure Software sicher ist.
Wie zertifiziert Ihr Eure Softwre, falls die mit Kundendaten arbeitet.
Wie zertifiziert und sichert Ihr eure Lieferketten ab, wenn Ihr Fremdkomponenten einsetzt.
Wie sichert Ihr Eure Lieferketten ab, die aus dem Ausland kommen ab?
Wie sichert Ihr Eure Lieferketten gegen Kinderarbeit? ( Ok, Ok, Scherz ... oder doch nicht ? )

Wegducken ist KEINE Option, soviel sei mal sicher, es werden ähnliche Pflichten für uns alle kommen, wie bei normalen Produkten auch.
Es ist nur den wenigsten bewusst, was da bereits alles gefordert wird.

Das alles wird wohl auch demnächst durch Zertifizierer usw. teuer eingekauft werden müssen,
die dann jährlich beim Vorlieferanten durch die Bude gehen, einen Kaffee trinken, wie Könige behandelt werden und dann einen schönen Bericht schreiben ( und immer was finden müssen, um ihre Rechtfertigung zu bestätigen ).

Edit:

Ach ja, und ganz wichtig, die Verpflichtung zur Risikoanalyse gehört auch dazu.
Wie macht Ihr das?

[Jens01]

Nein. Das ist ein vergleichbares Beispiel:

Zitat:

Es gibt aber fünf große Unterschiede, mindestens ...

1. Ein Ziegel, Fenster, Heizung, Mörtel und andere Komponenten sind in der Regel nicht so komplex und fehleranfällig und können den Zustand kaum dynamisch verändern.
2. Ein Ziegel, Fenster, Heizung, Mörtel und andere Komponenten werden in der Regel nicht ständig aktiv von Hackern angegriffen
3. Ein Ziegel, Fenster, Heizung, Mörtel und andere Komponenten stellen in der Regel keine fatalen Sicherheitsrisiken dar, selbst wenn sie sich verändern
4. Ein Ziegel, Fenster, Heizung, Mörtel und andere Komponenten, selbst wenn sie gefährlich sind, werden in der Regel nur punktuell eingesetzt und nicht millionenfach im Web kopiert
5. Ein Ziegel, Fenster, Heizung, Mörtel und andere Komponenten werden in der Regel nicht Opensource als freie Komponenten angeboten, deren Hersteller hat auch immer gewerbliches Interesse und Verantwortung

Zu1 Doch, diese Komponenten sind sehr komplex.
Zu2 richtig.
zu3 Doch, sogar ein sehr hohes.
zu4 Doch, wenn es Produkt entwickelt wurde, wird es tausendfach produziert.
zu5 Doch, Konstruktionsweisen, werden ebenso verbreitet.

Das war auch nur ein Beispiel. Das könnte man auch mit Autos oder anderen Maschinen machen.

[sh17]

Zitat von Rollo62:

Bevor das hier aber komplett abdriftet ...
Ich wollte eigentlich nur wissen und diskutieren wie Ihr mit dem Thema umgeht.

Ja, bitte zurück zum Thema.

Wie weist ihr nach, das Eure Software sicher ist.
Wie zertifiziert Ihr Eure Software, falls die mit Kundendaten arbeitet.
Wie zertifiziert und sichert Ihr eure Lieferketten ab, wenn Ihr Fremdkomponenten einsetzt.
Wie sichert Ihr Eure Lieferketten ab, die aus dem Ausland kommen ab?
Wie sichert Ihr Eure Lieferketten gegen Kinderarbeit? ( Ok, Ok, Scherz ... oder doch nicht ? )

Also alle Zertifizierungen, die ich bisher so kenne, kosten richtig viel Geld und gelten dann immer nur für die jeweils zertifizierte Version. Neues Update da -> neue Zertifizierung. Das kann also nicht die Lösung sein.
Ich denke der erste Weg ist die Minimierung der Fremdkomponenten. Erst die mit Closed Source, dann die anderen.
Ansonsten der Ausbau von Unit-Tests für Geschäftsregeln, was sehr viel Arbeit bedeutet.
Das sind so meine naiven Vorstellungen.

Was ist denn z.B. mit der genutzten Datenbank? Die wird man in der Regel ja nicht selbst entwickeln, gehört aber sicher zum "Produkt". Für Fehler in dieser muss ich dann wohl auch gerade stehen?

[joachimd]

Ich denke, ein guter Anfang ist, zuerst zu wissen, was man selber hat und einsetzt. Da Software nie fehlerfrei sein wird (das beweisen fast täglich alle "Großen"), muss man sicherstellen, dass kontrolliert nachgearbeitet werden kann.
Neben einer Quellcodeverwaltung auf jeden Fall auch eine "Stückliste" erstellen:
https://www.bsi.bund.de/DE/Service-N...rderungen.html.

Dann noch die Maßnahmen 8.25 bis 8.34 aus der https://de.wikipedia.org/wiki/ISO/IEC_27002 umsetzen.
Alles weitere werden die Gerichte entscheiden.

Bzgl freier Software:
https://www.heise.de/hintergrund/Sof...-10027145.html

Zitat:

Eine Bereichsausnahme besteht unter anderem für Open-Source-Software: Um Innovation und Forschung nicht zu behindern, ist freie und quelloffene Software, die außerhalb einer gewerblichen Tätigkeit entwickelt und angeboten wird, von der Haftung ausgenommen, wobei die Reichweite dieser Ausnahme aktuell – ähnlich der Ausnahme im Cyber Resilience Act (CRA) – diskutiert wird. Im Ergebnis führt die ProdHaftRL zu einer weitgehenden Haftung des (Software-)Herstellers für fehlerhafte Produkte – unabhängig davon, ob dieser in einem direkten Vertragsverhältnis zum Geschädigten steht.

[Rollo62]

Zitat von sh17:

Also alle Zertifizierungen, die ich bisher so kenne, kosten richtig viel Geld und gelten dann immer nur für die jeweils zertifizierte Version. ...
Ich denke der erste Weg ist die Minimierung der Fremdkomponenten. Erst die mit Closed Source, dann die anderen.

Ja, so viel selber machen wie möglich, oder vor-zertifizierte Komponenten einkaufen, als "Nachweis" der Konformität in Teilen.
Closed Source ist sowieso schon immer ein No-Go für mich, schon aus anderen Gründen ...

Zitat von sh17:

Ansonsten der Ausbau von Unit-Tests für Geschäftsregeln, was sehr viel Arbeit bedeutet.

Genau, es gibt ja entsprechende Normen und allgemein annerkannte Regeln der Technik.
Ich werde versuchen diese im ersten Schritt mal "anzupeilen", also eine Umsetzung "gemäß" oder "in Anlehnung an" diese oder jene Regel.
Aus jeden Fall alle möglichen QS-Standards für Software versuchen einzuhalten, um den Stand der Technik nachzuweisen.
Dann wird es womöglich später erforderlich sein, sicherheitskritische Teile extern zertifizieren zu lassen.
Oder eben sicherheitskritische Teile in externe Cloud-Systeme auszulagen, die zertifiziert sind,
aber das allein wird wohl nicht reichen, denn ich bin nach wie vor für das Ganze verantwortlich.
Womöglich kann man auch intern Teile herausziehen und separat zertifizieren, quasi als "Baumusterprüfung" von Komponenten,
das könnte die Kosten womögöich reduzieren.

Zitat von sh17:

Was ist denn z.B. mit der genutzten Datenbank? Die wird man in der Regel ja nicht selbst entwickeln, gehört aber sicher zum "Produkt". Für Fehler in dieser muss ich dann wohl auch gerade stehen?

Ja, aber das könnte gut eine vor-zertifizierte Komponente sein.
Wie bei anderen Produkten auch, ist es immer gut Zertifikate von Vorlieferanten zur Lieferantenbewertung einzuholen,
all das zielt darauf ab, das gesamte Risiko zu verringern und wird positiv gewertet.

Zitat von sh17:

Neues Update da -> neue Zertifizierung. Das kann also nicht die Lösung sein.

In der Theorie ist das wohl so gedacht, aber praktisch unmöglich.
Deshalb wird es wohl um die Nachweise gehen, dass Du einigermaßen alles richtig machst.
Ein Prüfinstitut kann ja gar nicht in die Details schauen, aber es wird sich durch eine Liste typischer Fehler durcharbeiten.
Also sowas wie Usereingaben ungeprüft zur DB zu schicken sollte man dann tunlichst unterlassen.
Praktikabel wird das dann durch jährliche Audits nachgeprüft, die dann jedes Mal 1-3000 EUR Kosten, wenn es dem normalen Umfang entspricht.
Bei z.B. Messgeräterichtlinie wird dann auch nach ca. 5 Jahren wieder eine Nachprüfung erforderlich, die dann entsprechend teuer wird.

Es gibt aber immer verschiedene Möglichkeit die Konformität nachzuweisen, obiges gilt jetzt für die hochkritischen Bereiche,
also da wo notifizierte Stellen vorgeschrieben werden.
Es könnte gut sein, dass dies schon da vorgeschrieben wird, wo Du mit einfachen Kundendaten arbeitest z.B auch im WebShop,
das wäre dann schon der worst-case.

Unabhängig ob Dein Prüfistitut dir eine AAAAA Note gibt, wenn was passiert bist Du sowieso immer in Haftung und kannst das nicht auf das Prüfinstitut abwälzen.
Solche Fälle kenne ich auch, wo es quasi einen Prüfinstitut-War gibt, TÜV gegen SGS, beide mit verschiedenen Einschatzungen.
Das muss nicht immer gut für Dich ausgehen.

[himitsu]

Zitat:

Neues Update da -> neue Zertifizierung. Das kann also nicht die Lösung sein.

Programm aufteilen und die Teile zertifizieren.

Erstmal mehr Zertifizieriungen und teurer, aber die Teile sind kleiner, also sollten jeweils günstiger werden,
und dann sind auch nicht immer alle Teile neu zu zertifizieren, bzw. es ist eventuell auch nicht für alle Teile nötig.

Zitat:

Kinderarbeit

Rentnerarbeit ... Kinder sterben eh aus

KI-Zwangsarbeit (die können sich ja garnicht wehren)