Sicherheitsupdates für Unternehmenssoftware: Wer haftet, wenn kein Entwickler mehr da ist

Ein mittelständisches Logistikunternehmen aus Hamburg musste das auf die harte Tour lernen. Der Freelancer, der 2022 ihr Buchungsportal gebaut hatte, zog 2024 ins Ausland, die Rechnungen blieben aus, und niemand übernahm seine Rolle. Achtzehn Monate später schickte das Einkaufsteam eines Kunden einen Sicherheitsfragebogen mit der Frage, wann die Abhängigkeiten des Portals zuletzt aktualisiert wurden. Die Antwort, mühsam aus Server-Logs zusammengesetzt, lautete: nie. Der Deal stand sechs Wochen lang still, während das Unternehmen fieberhaft herausfand, was die Verantwortung für Sicherheitsupdates überhaupt noch bedeutete, nachdem der ursprüngliche Entwickler verschwunden war.

Diese Situation ist weit verbreitet und wird selten offen angesprochen. Ein Unternehmen beauftragt eine individuelle Software, die Zusammenarbeit mit dem Entwickler oder der Agentur endet, und die Software läuft einfach weiter, weil sie noch funktioniert. Niemand entscheidet bewusst, die Updates einzustellen. Die Zuständigkeit für Patches wird schlicht nie neu vergeben, und die Lücke bleibt unsichtbar, bis ein Sicherheitsvorfall, ein Audit oder eine Kundenanfrage sie ans Licht bringt.

Wer haftet für Sicherheitsupdates, wenn kein Entwickler mehr da ist

Die kurze Antwort: das Unternehmen, dem die Software gehört, nicht der Entwickler, der sie gebaut hat. Sobald ein Projektvertrag endet, erlischt auch jede Verpflichtung des ursprünglichen Entwicklers, sofern der Vertrag nicht ausdrücklich eine laufende Wartung vorsah. Ein einmaliger Entwicklungsvertrag deckt genau das ab: eine Erstellung. Er begründet keine dauerhafte Pflicht des Entwicklers, fünf Jahre später noch CVE-Datenbanken für die Anwendung zu überwachen.

Damit bleibt das Risiko beim Unternehmen selbst, unabhängig davon, ob im Team jemand PHP-Abhängigkeitsbäume oder Symfony-Sicherheitshinweise versteht. Verarbeitet die Software Kundendaten, ist sie über das öffentliche Internet erreichbar oder mit anderen Geschäftssystemen verbunden, ist jemand im Unternehmen dafür verantwortlich, sie gepatcht zu halten, auch wenn niemand im Haus die Patches tatsächlich einspielen kann. Eigentum und Fähigkeit sind zwei verschiedene Dinge, und Unternehmen stellen oft erst fest, dass sie Ersteres ohne Letzteres besitzen, wenn bereits etwas schiefgelaufen ist.

Diese Lücke entsteht meist leise. Ein Entwickler verlässt das Unternehmen, ein Wartungsvertrag läuft aus, der Zuständigkeitsbereich eines Freelancers war enger gefasst, als irgendjemand noch weiß. Die Software selbst gibt keine Warnung. Eine PHP-Anwendung mit einer Sicherheitslücke sieht genauso aus und verhält sich genauso wie eine ohne, bis zu dem Moment, in dem das nicht mehr stimmt.

In der Praxis ist die Person, die am Ende zur Verantwortung gezogen wird, selten eine technische. Es ist ein Betriebsleiter, ein Finanzchef oder manchmal der Gründer, weil sie es sind, die den ursprünglichen Vertrag unterschrieben haben oder die Frage eines Kunden beantworten müssen. Diese Person muss den Code nicht verstehen. Sie muss wissen, wer aktuell die Befugnis hat, Patches einzuspielen, und die ehrliche Antwort lautet in vielen Unternehmen gerade: niemand.

NIS2 und die Pflichten, die nicht einfach verschwinden

Für Unternehmen in der EU ist das nicht nur eine Frage des Rufs. Die NIS2-Richtlinie hat deutlich mehr mittelständische Unternehmen in formale Cybersicherheitspflichten einbezogen als ihre Vorgängerrichtlinie, und einer der benannten Maßnahmenbereiche ist die Sicherheit bei Beschaffung, Entwicklung und Wartung von Software. Ein Unternehmen im Anwendungsbereich kann sich nicht darauf berufen, dass kein Entwickler mehr da war, um zu erklären, warum keine Patches eingespielt wurden. Die Richtlinie erwartet einen dokumentierten Prozess, und „wir hatten früher jemanden dafür" ist keiner.

Auch Unternehmen außerhalb des unmittelbaren Anwendungsbereichs von NIS2 übernehmen oft indirekt dieselben Erwartungen. Ein Kunde in einer regulierten Branche wird von seinen Zulieferern im Rahmen der eigenen Lieferketten-Prüfung die Patch-Frequenz abfragen, weil diese Pflicht aus seinen eigenen Compliance-Anforderungen nach unten weitergegeben wird. Verkauft Ihr Unternehmen an Banken, Versicherer, Gesundheitsdienstleister oder Akteure kritischer Infrastruktur, ist früher oder später mit einer solchen Abfrage zu rechnen, und „aktuell wartet niemand dieses System" wird dabei als Warnsignal behandelt, nicht als akzeptable Antwort.

Das Datenschutzrecht fügt eine zweite Ebene hinzu. Nach der DSGVO lässt sich eine bekannte, ungepatchte Schwachstelle, die zu einer Datenschutzverletzung führt, kaum noch als unvorhersehbares Ereignis verteidigen, sobald der Hersteller oder die Sicherheitscommunity einen Fix veröffentlicht hat. Aufsichtsbehörden fragen in der Regel nicht, ob ein Entwickler fest angestellt war. Sie fragen, ob angemessene technische Maßnahmen vorhanden waren, und eine zwei Jahre alte, ungepatchte Abhängigkeit mit bekannter Schwachstelle gilt selten als angemessen.

Was Cyber-Versicherer heute erwarten

Cyber-Versicherungen haben sich in den letzten Jahren deutlich verändert, und Patch-Management ist heute ein zentraler Bestandteil der Risikoprüfung, nicht mehr nur eine Randnotiz. Viele Versicherer fragen Antragsteller inzwischen direkt, wie schnell kritische Schwachstellen behoben werden, und manche verlangen einen dokumentierten Prozess, bevor sie überhaupt eine Police ausstellen.

Das eigentliche Risiko zeigt sich im Schadensfall, nicht beim Vertragsabschluss. Lässt sich ein Sicherheitsvorfall auf eine Schwachstelle zurückführen, für die seit Monaten ein Patch verfügbar war, prüfen Versicherer zunehmend genau, ob die im Antrag angegebenen Praktiken tatsächlich befolgt wurden. Ein Unternehmen, das im Antrag „ja, wir patchen zeitnah" angegeben hat und dann durch eine seit zwei Jahren unberührte Abhängigkeit geschädigt wird, steht bei der Regulierung schlechter da als eines, das eine Lücke offen benannt und bereits mit der Schließung begonnen hatte.

Das schafft einen unangenehmen Anreiz, das Problem kleinzureden, um die Prämien nicht steigen zu lassen, was genau der falsche Weg ist. Versicherer kalkulieren bekannte Lücken ein. Lücken, die erst nach einem Schadensfall auftauchen, lassen sich dagegen kaum sauber kalkulieren.

Wie ein dokumentierter Update-Prozess tatsächlich aussieht

Nichts davon erfordert die Festanstellung eines Vollzeit-Entwicklers. Es erfordert, eine verantwortliche Stelle zu benennen und ihr einen wiederholbaren Prozess zu geben, sei es eine interne Einstellung, ein Freelancer mit festem Rhythmus oder ein externer Partner. Drei Elemente machen den Unterschied zwischen einem echten Prozess und guten Vorsätzen.

Das erste ist eine Inventarisierung. Man kann nicht patchen, was man nicht aufgelistet hat. Das bedeutet: jede Anwendung, jede wichtige Abhängigkeit darin und das End-of-Life-Datum für ihre Sprach- und Framework-Version. PHP 8.2 verliert den Sicherheitssupport am 31. Dezember 2026; Symfony 5.4 erreicht sein End of Life sogar noch früher. Ein Unternehmen, das eines von beidem ohne Plan für die Zeit danach betreibt, trägt eine Uhr mit sich, auf die es nicht geschaut hat.

Das zweite ist ein Rhythmus mit einem benannten Verantwortlichen. „Wir kommen schon noch dazu" ist kein Rhythmus. Eine monatliche oder vierteljährliche Überprüfung für routinemäßige Abhängigkeits-Updates, plus eine separate, schnellere Spur speziell für alles, was als Sicherheitshinweis gekennzeichnet ist, gibt Ihnen etwas, auf das Sie tatsächlich verweisen können, wenn ein Kunde oder Versicherer nachfragt. Das muss nicht aufwendig sein. Es muss im Kalender stehen, mit dem Namen einer konkreten Person, nicht einer Abteilung.

Das dritte ist eine Dokumentation. Wenn etwas gepatcht wird, halten Sie fest, was sich geändert hat und wann, auch wenn es nur drei Zeilen in einem gemeinsamen Dokument sind. Dieser Punkt macht aus „wir nehmen Sicherheit ernst" einen Satz mit Substanz statt bloßer Behauptung, und es ist der Punkt, den die meisten Unternehmen überspringen, weil er sich wie Papierkram anfühlt statt wie Sicherheitsarbeit. Bei einem Audit, einer Einkaufsprüfung oder der Untersuchung eines Sicherheitsvorfalls ist genau dieses Protokoll oft das Einzige, das ein Unternehmen mit Prozess von einem Unternehmen mit Glück unterscheidet.

Wolf-Tech richtet genau diesen Prozess im Rahmen unserer Code-Qualitätsberatung ein, beginnend mit der Abhängigkeits- und Versionsinventur, die den meisten Unternehmen in dieser Lage noch fehlt. Wir behandeln auch verwandte Wartungsfragen, einschließlich dessen, was ein Software-Wartungsvertrag tatsächlich beinhalten sollte, sobald Sie sich für laufende Betreuung statt punktueller Reparaturen entscheiden.

Betreibt Ihr Unternehmen produktive Software, für die aktuell niemand die Verantwortung trägt, ist der ehrliche erste Schritt herauszufinden, was genau installiert ist und wie alt es ist. Melden Sie sich unter hello@wolf-tech.io oder besuchen Sie wolf-tech.io, und wir helfen Ihnen herauszufinden, wo die Lücken tatsächlich liegen, bevor ein Kunde, ein Prüfer oder ein Versicherer sie als Erster findet.