Wer pflegt das noch? Offene Software für zehn Jahre auswählen

Ein Betrieb entscheidet selten für ein einzelnes Jahr. Wer ein Werkzeug einführt, bindet sich für einen Zeitraum, der länger ist als die meisten Verträge, die er sonst schließt. Bei offener Software hängt dieser Zeitraum an drei Dingen: an Personen, die den Code weiterentwickeln, an Verträgen, die jemand abschließt, und an einem Repository, das erreichbar bleibt. Die Frage lautet deshalb nicht, welche Lösung die beste ist, sondern woran sich vor der Einführung erkennen lässt, ob sie trägt.

Die Beispiele in diesem Beitrag sind fiktiv, und der Beitrag bewertet kein Produkt. Er vergleicht Pflegemodelle als Kategorien und benennt die Stellen, an denen eine Entscheidung tatsächlich fällt.

Wer haftet für die Pflege?

Viele Betriebe gehen stillschweigend davon aus, dass jemand anderes für die Pflege einsteht. Bei offener Software trifft diese Annahme selten zu, und seit dem 10. Dezember 2024 ist der Grund dafür ausdrücklich geregelt. Die europäische Verordnung über die Cyberresilienz gilt für Produkte mit digitalen Elementen. Sie erfasst offene Software nur, wenn sie auf dem Markt bereitgestellt wird; Software, die ihre Hersteller nicht monetarisieren, gilt nicht als kommerzielle Tätigkeit und fällt damit heraus. Für Entwicklerinnen und Entwickler, die Quellcode beitragen, der nicht in ihrer Verantwortung steht, gilt sie ebenfalls nicht.

Für Projekte, die niemand auf diese Weise vertreibt, hat der Gesetzgeber eine eigene Kategorie geschaffen: den Open-Source-Software-Steward. Gemeint ist eine juristische Person, die ein solches Produkt nachhaltig unterstützt und eine Hauptrolle für seine Lebensfähigkeit spielt. Für sie gilt ein leichteres Regime: Sie unterliegt den Pflichten aus Artikel 24, also einer Sicherheitspolitik für Entwicklung und Schwachstellenumgang, der Zusammenarbeit mit den Marktüberwachungsbehörden und der Meldung aktiv ausgenutzter Schwachstellen. Nach Artikel 64 Absatz 10 werden Stewards für Verstöße nicht mit Geldbußen belegt. Die Berichtspflichten gelten ab dem 11. September 2026, die wesentlichen Pflichten ab dem 11. Dezember 2027.

Diese Regeln sagen einem Hersteller, was er schuldet. Sie begründen keinen Anspruch für den, der die Software einsetzt. Wer ein Werkzeug betreibt, hat keinen Vertrag mit dem Projekt und niemanden, den er in Anspruch nehmen könnte, wenn eine Meldung liegen bleibt. Die Pflegefrage ist damit keine Frage der Lizenz, sondern der eigenen Zuständigkeit. Wer selbst in den Anwendungsbereich einer Regelung fällt, trägt andere Pflichten als der, der sie nur über einen Kundenvertrag weitergereicht bekommt. Wie sich diese beiden Wege trennen lassen, beschreibt der Beitrag dazu, wann NIS2 einen kleineren Betrieb erfasst.

Ein Sicherheitshinweis, den niemand liest, ist kein Sicherheitshinweis. Wer keine eigene Abteilung dafür hat, braucht trotzdem eine Person und eine Vertretung. Wie ein Grundschutz ohne eigene Sicherheitsabteilung aussieht, steht im Leitfaden zum sicheren Betrieb ohne eigenes Security-Team.

Woran erkennt man vorher, ob ein Projekt trägt?

Eine Lizenz regelt, was ein Betrieb tun darf. Sie sagt nichts darüber, wer den Code weiterentwickelt. Für die Frage nach zehn Jahren ist deshalb die Form der Pflege aussagekräftiger als der Lizenztext. Vier Modelle lassen sich unterscheiden, und an jedes lässt sich etwas anderes verlangen.

Die Zuordnung fällt leichter, wenn man vier Beobachtungen trennt: Wie viele Personen haben Schreibrechte, oder hängt das Projekt an einer einzigen? Erscheinen Veröffentlichungen in einem erkennbaren Rhythmus? Steht eine Organisation dahinter, die auch in zwei Jahren noch existiert? Werden Fehlerberichte beantwortet oder sammeln sie sich ungelesen? Die letzte Beobachtung ist die aussagekräftigste, weil sie sich nicht planen lässt.

Wenn keine dieser Beobachtungen trägt, bleibt der Fork. Er ist rechtlich fast immer möglich und praktisch teuer, weil der Betrieb die Pflege vollständig übernimmt. Warum ein Fork ein Notausgang und kein Beschaffungsweg ist, steht im Beitrag über Abhängigkeit statt Ablösung.

Der folgende Prüfpfad ordnet die fünf Stationen, an denen sich eine Entscheidung festmachen lässt. Er ist eine Arbeitshilfe der Redaktion und kein Prüfsiegel.

Was lässt sich vor dem Kauf verlangen?

Die wichtigste Maßnahme kostet nichts und wird am häufigsten versäumt: Für jedes Werkzeug wird eine Person benannt, die Meldungen liest, dazu eine Vertretung. Ohne sie bleiben alle weiteren Vorkehrungen folgenlos, weil niemand sie auslöst. Die zweite Maßnahme ist ein Vertrag mit einer Zahl darin. Ein Support-Vertrag ohne genannte Reaktionszeit ist eine Absichtserklärung; verlangt werden kann eine Frist für die Korrektur und die Benennung der Stelle, die sie schuldet.

Die dritte Maßnahme betrifft die Lieferkette. Ein Betrieb, der vier Werkzeuge einsetzt, hängt an mehreren hundert Bestandteilen, von denen er die meisten nicht bewusst ausgewählt hat. Eine Software-Stückliste macht sie sichtbar, bevor ein Vorfall es tut. Verlangt werden kann ein maschinenlesbares Verzeichnis in einem der beiden verbreiteten Formate SPDX oder CycloneDX. Das Bundesamt für Sicherheit in der Informationstechnik beschreibt in der Technischen Richtlinie TR-03183 (öffnet in einem neuen Tab), welche Angaben es enthalten soll und wie es sich den Formaten zuordnen lässt. Das Amt weist zugleich darauf hin, dass die Richtlinie unverbindlich ist und keine Konformitätsvermutung trägt; sie taugt als Bezugsrahmen, nicht als Nachweis.

Eine vierte Maßnahme wird regelmäßig mit einer fünften verwechselt. Zu testen ist der Ausstieg, und zwar einmal, bevor er gebraucht wird; ein Export, der nie zurückgelesen wurde, ist kein Ausstieg. Die Hinterlegung des Quellcodes dagegen hilft bei offener Software wenig, weil der Quellcode ohnehin veröffentlicht ist. Abdecken könnte sie die Konfiguration, die Anpassungen und das Wissen des Dienstleisters. Wer sie einkauft, sollte genau benennen, was hinterlegt wird.

Vor der flächendeckenden Einführung steht ein begrenzter Versuch; wie er aufgesetzt wird, ohne die Organisation zu binden, steht im Beitrag über den Pilot, der klein bleiben darf. Ob ein Werkzeug im Haus oder als Dienst betrieben wird, verschiebt nur, wer welche Aufgabe hat. Welche Fragen das aufwirft, ordnet die Auswahlhilfe zum Passwortmanager für ein Team ein.

Wie überbrückt man die Lücke zwischen Meldung und Aktualisierung?

Der Satz, es gebe eine Korrektur, ist kein Zustand. Zwischen einer Meldung und einer installierten Aktualisierung liegen mehrere Schritte, und der Betrieb beherrscht nur die letzten beiden.

Die ersten vier Schritte können abgeschlossen sein, während im Betrieb noch die alte Fassung läuft. Genau in diesem Zwischenraum liegt das Risiko. Ein Bericht zur Datenlage von Netzrandgeräten nennt für sie einen mittleren Abstand von null Tagen zwischen der Veröffentlichung einer Schwachstelle und ihrer massenhaften Ausnutzung; in der kleinen Teilmenge, auf der diese Zahl beruht, stand ein erheblicher Teil der Fälle schon am Tag der Veröffentlichung im Katalog bekannter ausgenutzter Schwachstellen. Für den gesamten Katalog liegt der Wert bei fünf Tagen. Auf der anderen Seite steht die Behebung: 32 Tage an Netzrandgeräten, 38 Tage über den Katalog, und nur etwa die Hälfte der betrachteten Fälle war im Berichtsjahr vollständig behoben.

Diese Zahlen beschreiben Netzrandgeräte, nicht offene Software im Besonderen, und sie stammen aus einem fremden Bericht über amerikanische Erhebungen. Übertragen werden kann die Form des Problems: Der Abstand zwischen Ausnutzung und Behebung ist die eigentliche Frist, und der Betrieb beeinflusst nur den Teil, der bei ihm liegt. Wer Verteilung und Installation nicht in einen festen Rhythmus bringt, verlängert genau diesen Abstand.

Was die Auswahl nicht entscheidet

Die Antwort auf die Ausgangsfrage ist unspektakulär. Das gewählte Werkzeug entscheidet nicht, ob ein Betrieb in zehn Jahren noch trägt, sondern nur, wie aufwendig der Ausstieg wird und wie viel Pflege beim Betrieb hängen bleibt. Was die Zeitspanne bestimmt, ist, ob im Haus jemand die Hinweise liest und handeln kann. Diese Aufgabe lässt sich an einen Dienstleister geben, aber nicht an ein Projekt.

Zwei Grenzen bleiben offen. Es gibt keine belastbare Zahl dafür, wie lange kleinere und mittlere Betriebe in Deutschland ein solches Werkzeug tatsächlich betreiben, und ebenso wenig dafür, wie viele von ihnen ein Verzeichnis ihrer Bestandteile führen; wo eine solche Angabe fehlt, steht hier keine. Offen ist zweitens die Rechtslage selbst: Die praktischen Leitlinien der Kommission zum Anwendungsbereich sind erst seit dem 27. Juli 2026 veröffentlicht, und die wesentlichen Pflichten gelten erst ab Dezember 2027. Wer für den eigenen Fall Sicherheit braucht, ist auf eine Prüfung des Einzelfalls angewiesen und nicht auf einen Beitrag wie diesen.

Prüfbar bleibt, was der Betrieb selbst festlegen kann: eine benannte Person, eine Frist im Vertrag, eine Stückliste im Haus und ein Ausstieg, der einmal funktioniert hat. Diese vier Punkte sind die eigene Antwort auf die Frage, wer pflegt, wenn niemand sonst es tut.