KIberschutz: verantwortungsvolle Statusseite
Wir zeigen jetzt öffentlich, welche Open-Source-Projekte wir auf Lücken geprüft haben. Sieben von elf Fällen bleiben dabei ohne Namen.
Seit Juni prüfen wir unter dem Namen KIberschutz Open-Source-Projekte aus dem KI-Umfeld auf Sicherheitslücken und melden die Funde an die Maintainer. Bisher gab es davon nur einzelne Meldungen hier im Blog, jeweils dann, wenn ein Fall abgeschlossen war. Ab sofort steht der Gesamtstand auf einer eigenen Seite: kiberblick.de/kiberschutz.
Zwölf Repositories geprüft, 90 Funde, alle 90 gemeldet. Elf Fälle stehen auf der Seite. Vier davon mit Namen, sieben ohne.
Warum sieben Fälle keinen Namen tragen
Darüber haben wir am längsten nachgedacht: Eine Statusseite, die zeigt "wir haben in Projekt X vier ungefixte Lücken gefunden", ist keine Transparenz. Sie ist eine Einkaufsliste für jeden, der es auf Projekt X abgesehen hat. Die Lücke ist ja noch offen.
Deshalb erscheint ein Projekt auf der Seite nur dann mit Namen, wenn eine von drei Bedingungen erfüllt ist:
Bei den sieben anonymen Fällen steht deshalb nur, um was für ein Werkzeug es sich grob handelt, wie viele Funde es gab und wie schwer sie wiegen. Kein Name, keine Schwachstellenklasse, kein Dateiname. Ein "Datei-Synchronisierungstool, 13 Funde, 4 hoch" verrät nicht, welches Projekt gemeint ist, zeigt aber, dass da etwas läuft.
Sobald ein Projekt released, klappt der Eintrag auf. Dann bekommt der Fall eine eigene Detailseite mit Zeitleiste und einer Erklärung zu jedem einzelnen Fund.
Was die Zahlen zeigen
Zwei Werte aus dem bisherigen Verlauf, mit einer Einschränkung, die wichtiger ist als die Zahlen selbst.
Der erste: bei den Funden, die behoben wurden, lag die Zeit bis zum Code-Fix im Median bei einem Tag. Wer eine belegte Meldung mit fertigem Patch schickt, bekam bei den geprüften Projekten oft am selben oder nächsten Tag eine Reaktion.
Diese Zahl beschreibt allerdings nur die 38 Funde, die überhaupt gefixt wurden. Die 48 Funde, die noch offen sind, kommen darin nicht vor, sie warten aktuell zwischen zwei und zehn Tagen. Ein Median über die Erledigten sagt nichts über die Wartenden aus, und je länger die offenen Fälle liegen, desto weniger taugt der Wert als Erwartung. Deshalb steht auf der Statusseite jeder Fall einzeln statt einer Durchschnittszahl.
Der zweite Wert: 15 Funde sind im Code gefixt, aber noch nicht in einer veröffentlichten Version. Der Fix existiert, wer aus dem Git-Hauptzweig baut, hat ihn. Wer die letzte Release-Version einsetzt, hat ihn nicht. Bei einem Projekt liegt der Fix seit Ende Juli auf main, das letzte Release ist älter.
Deshalb trennt die Seite beide Zeitpunkte. Wer sie vermischt, erweckt den Eindruck, ein Problem sei erledigt, obwohl es bei den meisten Nutzern noch offen ist.
Eine Ausnahme, die wir offen benennen
Auf der Seite steht auch, was passiert, wenn ein Projekt gar nicht reagiert. Nach angemessener Frist veröffentlichen wir eine Lücke dann auch ohne Fix. Das klingt hart. Die Lücke existiert aber unabhängig davon, ob wir sie melden, und wer gezielt danach sucht, hat sie oft längst gefunden. Ab einem gewissen Punkt schützt Stillschweigen nicht mehr die Nutzer, sondern nur noch das Projekt, das nicht reagiert.
Bisher mussten wir das kein einziges Mal tun. Alle vier abgeschlossenen Fälle wurden gemeldet, gefixt und released, ohne dass wir Druck aufbauen mussten.
Auf kiberblick.de/kiberschutz steht der vollständige Stand: jeder Fall mit Zeitleiste, die aufgedeckten Fälle mit einer Erklärung zu jedem einzelnen Fund, dazu die drei Dinge, die wir Teams nach zwölf geprüften Projekten raten. Eines davon vorweg, weil es der billigste Schritt ist: Private Vulnerability Reporting in den Repository-Einstellungen einschalten. Bei mehreren der geprüften Projekte war es aus.