Alltagsprobleme im Patch-Management von Open Source

Eine Schwachstelle wird gefunden, ein Patch wird geschrieben, eine neue Version wird veröffentlicht. So stellt man sich den Ablauf vor. In der Praxis ist das der Bestfall - und er tritt seltener ein, als die meisten Unternehmen annehmen.

Der Bestfall

Das Projekt findet die Fehlerursache, behebt das Problem korrekt und veröffentlicht umgehend eine neue Version mit dem Fix. Sie aktualisieren die Abhängigkeit, die Schwachstelle ist geschlossen.

Das funktioniert bei großen, gut organisierten Projekten mit hauptberuflichen Maintainern und strukturierten Release-Prozessen. Bei der Mehrzahl der Projekte in einer typischen SBOM sieht die Realität anders aus.

Typische Probleme

Der Patch ist nicht ausreichend. Die Korrektur behebt das gemeldete Symptom, aber nicht die eigentliche Ursache. Die Schwachstelle bleibt ausnutzbar - nur auf einem anderen Weg.
Wir schreiben den Patch, aber er wird nicht akzeptiert. Maintainer lehnen Beiträge ab - aus technischen Gründen, wegen abweichender Designvorstellungen oder weil sie die Sicherheitsrelevanz anders einschätzen.
Der Patch wird akzeptiert, aber es gibt kein Release. Der Fix liegt im Hauptentwicklungszweig, aber niemand erstellt eine neue Version. Wochen, Monate, manchmal Jahre vergehen ohne Release.
Das Projekt ist unmaintained. Der Patch wird geschrieben, aber es gibt niemanden, der ihn anwendet. Es wird kein Review geben, keine Zusammenführung und kein Release.
Wir pflegen einen Fork, aber die Toolchain zieht nicht mit. SCA-Tools und automatische Update-Pipelines kennen nur das Originalprojekt. Sie beziehen weiterhin die alte, ungepatchte Version.
Der Maintainer widerspricht der Einschätzung. Nicht jeder Maintainer stimmt zu, dass ein Problem sicherheitsrelevant ist. Ohne Einigung gibt es keinen Fix.
Der Fix verursacht eine Regression. Die Korrektur behebt die Schwachstelle, bricht aber bestehende Funktionalität. Nutzer stehen vor der Wahl zwischen Sicherheitslücke und defekter Software.
Der Fix erfordert inkompatible API-Änderungen. Die korrekte Behebung verlangt Änderungen an der Schnittstelle, die nachgelagerte Projekte nicht übernehmen können, ohne selbst umzubauen.

Warum das für Sie relevant ist

Jedes dieser Szenarien bedeutet: Eine bekannte Schwachstelle bleibt offen, obwohl theoretisch ein Fix existiert oder existieren könnte. Ihre Compliance-Verpflichtungen unterscheiden nicht zwischen "kein Fix verfügbar" und "Fix verfügbar, aber praktisch nicht einsetzbar". Die gesetzliche Erwartung ist klar:

DORA Art. 9 Abs. 4 lit. f fordert Patch-Management als Teil des IKT-Risikomanagements
CRA Anhang I Teil II Nr. 2 verlangt die unverzügliche Behebung ausnutzbarer Schwachstellen durch Sicherheitsaktualisierungen

"Einfach patchen" ist keine Lösung, wenn die Realität des Open-Source-Ökosystems dagegensteht. Genau deshalb existiert OTTRIA als Vermittler zwischen Ihrem Unternehmen und der Open-Source-Welt: Wir navigieren diese Situationen täglich, kennen die Maintainer, die Prozesse und die Ausweichstrategien. Wenn ein Patch abgelehnt wird, pflegen wir einen Fork. Wenn ein Projekt verwaist ist, übernehmen wir die Wartung. Wenn ein Release ausbleibt, koordinieren wir mit der Community.

Weiterlesen

Sie stecken in einem dieser Szenarien? OTTRIA löst Patch-Blockaden in der Open-Source-Lieferkette. Sprechen Sie mit uns.