Die Richtlinie (EU) 2024/2853 stuft Software und Systeme der künstlichen Intelligenz als “Produkte” ein, die der verschuldensunabhängigen Haftung unterliegen. Dies verändert das Risikoprofil von Softwarehäusern grundlegend: Im Falle eines Schadens, der durch eine Schwachstelle verursacht wurde, haftet der Hersteller auch ohne Verschulden, es sei denn, er kann nachweisen, dass der Fehler nach dem Stand der Technik zum Zeitpunkt des Inverkehrbringens nicht erkennbar war. Ein Penetrationstest ist das Instrument, das diesen Nachweis in dokumentierter und verteidigbarer Form erbringt.

Dieser Artikel ist Teil des Minileitfadens zur Richtlinie (EU) 2024/2853. Für den allgemeinen Überblick konsultieren Sie den Richtlinien-Hub oder vertiefen Sie die Kapitel zu digitalen Produkten und Softwarehaftung.

Wann ein Softwareprodukt als fehlerhaft gilt

Die Richtlinie definiert ein Produkt als fehlerhaft, wenn es nicht die Sicherheit bietet, die die Öffentlichkeit berechtigterweise erwarten darf, wobei auch die geltenden Cybersicherheitsanforderungen zu berücksichtigen sind. Für Software bedeutet dies, dass eine ausnutzbare Schwachstelle – selbst wenn sie noch nicht ausgenutzt wurde – ausreichen kann, um das Produkt zum Zeitpunkt der Veröffentlichung als fehlerhaft einzustufen.

Ein Penetrationstest, der vor dem Inverkehrbringen und nach jeder wesentlichen Änderung durchgeführt wird, ermöglicht den Nachweis, dass die Schutzmaßnahmen des Produkts systematisch überprüft wurden und bekannte oder vernünftigerweise erkennbare Schwachstellen adressiert wurden. Ohne diese Dokumentation muss der Hersteller das Fehlen von Mängeln ohne konkrete Beweise belegen.

Beweislast und technische Dokumentation

Die Richtlinie führt einen Mechanismus für den Zugang zu Beweismitteln ein, der den Hersteller verpflichten kann, im Falle eines Rechtsstreits die technische Dokumentation vorzulegen. Wenn diese Dokumentation nicht existiert oder unvollständig ist, wird der Fehler vermutet. Existiert sie hingegen und ist sie auf dem neuesten Stand, kann sich der Hersteller auf den Entlastungsgrund des “Stands der Technik” berufen: Der Fehler war zum Zeitpunkt der Veröffentlichung mit den verfügbaren Methoden nicht erkennbar.

Ein datierter Penetrationstest-Bericht, der von einem unabhängigen Team unterzeichnet wurde und sich auf die getesteten Softwareversionen bezieht, ist die direkteste Form dieser Dokumentation. Eine automatisierte Analyse reicht nicht aus: Es bedarf einer manuellen und kreativen Tätigkeit, die das Verhalten eines realen Angreifers simuliert.

Haftung bei Eingreifen eines externen Angreifers

Die Richtlinie behält die Haftung des Herstellers auch dann bei, wenn der Schaden gemeinsam durch den Produktfehler und das Handeln eines Dritten verursacht wird – zum Beispiel durch einen Angreifer, der eine nicht behobene Schwachstelle ausnutzt. Das Vorhandensein eines Hackers in der Kausalkette entbindet den Hersteller nicht von seiner Verantwortung.

Der Penetrationstest dient genau dazu, dieses Szenario zu simulieren: Wenn eine Schwachstelle mit Standard-Angriffstechniken erkennbar ist, kann der Hersteller nicht behaupten, sie sei unvorhersehbar gewesen. Die Dokumentation, dass der Test durchgeführt wurde – und dass die aufgedeckten Schwachstellen behoben wurden –, reduziert das Risiko von Schadensersatzforderungen für physische oder psychische Schäden sowie Datenverluste erheblich.

Penetrationstest oder Vulnerability Assessment: Was verlangt die Richtlinie?

Das Vulnerability Assessment identifiziert bekannte Schwachstellen durch automatisierte Scans und den Abgleich mit öffentlichen Datenbanken. Es ist nützlich für die kontinuierliche Überwachung, liefert jedoch nicht die Beweise, die die Richtlinie im Streitfall verlangt.

Der Penetrationstest fügt die manuelle und offensive Komponente hinzu: Ein erfahrener Tester prüft, ob die Schwachstellen im spezifischen Kontext des Produkts tatsächlich ausnutzbar sind, verknüpft mehrere Schwächen, um einen realen Angriff zu simulieren, und dokumentiert den verfolgten Pfad. Diese Analysetiefe – und ihre Nachvollziehbarkeit – macht den Penetrationstest zum geeigneten Instrument, um den Beweisanforderungen der Richtlinie zu entsprechen.

Für Softwareprodukte und Webanwendungen deckt das Web Application Penetration Testing von ISGroup diesen Bedarf mit OSSTMM- und OWASP-Methoden, strukturierten Berichten und Unterstützung bei der Behebung (Remediation).

Nützliche weiterführende Informationen

• Leitfaden zur Richtlinie (EU) 2024/2853 — der vollständige Rahmen zur verschuldensunabhängigen Haftung für Produkte, einschließlich Software und KI.
• Digitale Produkte und EU-Richtlinie — wie die Richtlinie auf Software, Apps und integrierte digitale Komponenten angewendet wird.
• Softwarehaftung — Analyse der spezifischen Pflichten für Softwarehersteller.
• Vulnerability Assessment und EU-Richtlinie — wann ein VA ausreicht und wann ein Penetrationstest erforderlich ist.

Häufig gestellte Fragen

• Wie oft muss ein Penetrationstest durchgeführt werden, um für die Richtlinie nützlich zu sein?
• Die Richtlinie legt kein festes Intervall fest, aber das Kriterium ist die wesentliche Änderung: Jede Veröffentlichung, die sicherheitsrelevante Funktionen ändert, erfordert einen neuen Test. Ein Test, der an einer früheren Version durchgeführt wurde, deckt keine später eingeführten Schwachstellen ab.
• Muss der Penetrationstest von einer externen Stelle durchgeführt werden?
• Die Richtlinie schreibt dies nicht explizit vor, aber im Falle eines Rechtsstreits hat ein von einem unabhängigen Team erstellter Bericht ein deutlich höheres Beweisgewicht als eine interne Analyse. Die Unabhängigkeit des Testers stärkt die Glaubwürdigkeit der Dokumentation.
• Deckt der Penetrationstest auch Systeme der künstlichen Intelligenz ab?
• Ja, sofern das KI-System im Sinne der Richtlinie als Produkt eingestuft ist. Bei KI-Komponenten, die in Software integriert sind, muss der Test neben herkömmlichen Anwendungsschwachstellen auch modellspezifische Angriffsvektoren – wie Prompt-Injection oder Eingabemanipulation – umfassen.
• Was passiert, wenn der Penetrationstest Schwachstellen aufdeckt, die vor der Veröffentlichung nicht behoben werden?
• Der Bericht dokumentiert die zum Zeitpunkt der Veröffentlichung bekannten Schwachstellen. Wenn der Hersteller sich entscheidet, das Produkt dennoch ohne Behebung dieser Schwachstellen zu veröffentlichen, wird die Dokumentation zu einem Beweis gegen ihn: Sie belegt, dass der Fehler bekannt war und nicht behoben wurde.

[Callforaction-WAPT-Footer]