Wenn ein OSS-Projekt mit offener Lücke stirbt

Selbst gehostete Open-Source-Software ist bequem, bis das Projekt dahinter stehen bleibt. Ein archiviertes Repository nimmt keine Pull Requests mehr an, veröffentlicht keine Releases und hat keinen Meldeweg für Sicherheitslücken. Wenn in so einem Projekt noch eine Lücke offen ist, wird sie nie mehr geschlossen. Für die Software in eurem Rechenzentrum ist das kein abstraktes Risiko, sondern ein konkreter Zustand, der an einem bestimmten Tag eintritt, oft ohne Ankündigung.

Dieser Artikel ist die praktische Antwort auf zwei Fragen: Was macht man als Finder einer Lücke, wenn das Projekt verschwunden ist? Und was macht man als Betreiber, der die Software weiter einsetzt? Als durchgehendes Beispiel dient die c4 GenAI Suite, die wir im KIberschutz-Projekt geprüft haben und die mitten im Meldeprozess archiviert wurde. Die Details zu dem Fall stehen in den beiden Fallartikeln (Teil 1, Teil 2); hier geht es um das Vorgehen, das sich daraus verallgemeinern lässt.

Was die Archivierung konkret kaputtmacht

"Archiviert" klingt nach einem Etikett, ist aber ein harter Schnitt. GitHub schaltet das Repository schreibgeschützt. Damit fällt mehr weg als nur neue Features.

Für eine gemeldete, aber noch nicht behobene Lücke heißt das: Der Fix, auf den man gewartet hat, wird nie kommen. Und die Lücke steht weiterhin im öffentlich lesbaren Code. Wer gezielt danach sucht, findet sie, völlig unabhängig davon, ob sie je gemeldet wurde.

Genau hier kippt die Logik der vertraulichen Meldung. Sie schützt Nutzer, solange ein Fix in Arbeit ist. Steht fest, dass keiner mehr kommt, verzögert das Schweigen nur, dass die Betreiber überhaupt davon erfahren, und die sind die Einzigen, die jetzt noch handeln können.

Was ein Finder ohne Gegenüber tun kann

Wenn das Projekt weg ist, fällt der koordinierte Weg weg, aber nicht die Verantwortung. Drei Schritte sind wir bei c4 gegangen. Ob am Ende CVE-Nummern dabei herauskommen, entscheidet noch der Review bei MITRE.

Erstens, selbst dokumentieren. Ein eigenes Advisory pro Fund, mit Beschreibung, betroffenen Versionen und, wo möglich, einem Patch, der sich auf die letzte veröffentlichte Version anwenden lässt. Das kann ein einfaches Markdown-Dokument in einem öffentlichen Repository sein. Entscheidend ist, dass Betreiber eine konkrete, überprüfbare Quelle haben.

Zweitens, eine CVE über den Finder-Weg beantragen. Eine öffentliche Kennung macht eine Lücke in den Abhängigkeits-Scannern vieler Teams erst gut auffindbar. Manche ziehen auch GitHub-Advisories über Dependabot und OSV, aber eine CVE ist die breiteste gemeinsame Kennung. Normalerweise beantragt der Hersteller sie. Fehlt der, springt die MITRE-Stelle für Fälle ein, die sonst niemand abdeckt. Ihr Antragsformular steht ausdrücklich auch Findern offen. Man reicht die Fund-Daten plus das eigene Advisory als Beleg ein und bekommt nach einem Review eine Nummer.

Drittens, die Grenze kennen. Eine CVE beantragen und veröffentlichen ist das eine. Ein Security Advisory im Namen des fremden Projekts herausgeben ist etwas anderes, und das geht nicht. Das eigene Advisory ist also ausdrücklich ein Finder-Advisory, keine Verlautbarung des Projekts.

Was Betreiber zuerst prüfen sollten

Für Betreiber ist die erste Frage nicht "abschalten oder nicht", sondern "bin ich überhaupt betroffen und wie dringend". Der Reihe nach.

flowchart TB
  A["OSS-Komponente<br/>archiviert"] --> B{"Offene Lücken<br/>oder CVEs?"}
  B -->|nein| C["Beobachten,<br/>Abhängigkeiten im Blick"]
  B -->|ja| D{"Patch oder<br/>Gegenmaßnahme<br/>verfügbar?"}
  D -->|ja| E["Einspielen bzw.<br/>am Proxy entschärfen"]
  D -->|nein| F["Migration<br/>priorisieren"]
  E --> G["Bewusste Entscheidung:<br/>Fork pflegen, wechseln<br/>oder mit eigener Wartung bleiben"]
  class B,D decision
  class F abort
  class C,G success
  classDef decision fill:#1A3A4A,stroke:#F59E0B,color:#FDE68A
  classDef abort fill:#7F1D1D,stroke:#EF4444,color:#FCA5A5
  classDef success fill:#14532D,stroke:#22C55E,color:#86EFAC

Klärt zuerst die Betroffenheit. Welche Version läuft bei euch, und welche Versionen nennen die Advisories als betroffen? Bei den drei offenen c4-Funden waren alle Versionen bis zur letzten betroffen, weil nie ein Fix erschien. Ein Blick in GitHub Advisories, OSV und die NVD zeigt, was bekannt ist.

Entschärft dann, was sich sofort entschärfen lässt. Nicht jede Lücke braucht einen Code-Fix im laufenden Betrieb. Eine Weiterleitungs-Lücke lässt sich oft am Reverse Proxy abfangen, ein Durchprobieren von Konten mit einem Ratenlimit bremsen, ein nach außen telefonierender Dienst mit Netzwerkregeln einhegen. Das kauft Zeit für die größere Entscheidung.

Und dann entscheidet bewusst. Ein archiviertes Projekt heißt nicht, dass ihr die Software morgen abschalten müsst. Es heißt, dass der Weiterbetrieb eine Entscheidung mit Aufwand ist und kein Automatismus. Wer bleibt, braucht realistisch drei Dinge: einen eigenen Fork, in den Sicherheitsfixes einfließen, jemanden, der die Abhängigkeiten im Blick behält, und eine Vorstellung davon, wohin gewechselt wird, wenn das zu teuer wird.

Die größere Lektion

Archivierte Abhängigkeiten sind kein Sonderfall. Viele Projekte werden irgendwann eingestellt, und für selbst gehostete Software heißt das, die Herkunft der eigenen Bausteine zu kennen, bevor es darauf ankommt. Das ist weniger spektakulär als eine einzelne Lücke, aber es ist der Teil, der am Ende über das Risiko entscheidet.

Das Archivieren selbst ist kein Vorwurf. Ein Projekt sauber einzustellen ist ehrlicher, als eine tote Codebasis mit einem Wartungsversprechen weiterzuschleppen. Nur sollte es angekündigt sein, damit Betreiber es mitbekommen, statt es zufällig im Repository zu entdecken. Mit der Archivierung wandert die Verantwortung vom Projekt zu denen, die die Software noch betreiben. Drei Dinge helfen, darauf vorbereitet zu sein:

• Die eigenen kritischen Abhängigkeiten inventarisieren, inklusive der selbst gehosteten.
• Ihre Aktivität regelmäßig prüfen: letztes Release, offene Issues, Reaktionszeit auf Meldungen.
• Für jede kritische Komponente eine Ausweichoption kennen, einen Fork oder eine Alternative.