Zusammen mit Forschern der Harvard-Universität hat die Core Infrastructure Initiative der Linux Foundation Schwachstellen im FOSS-Ökosystem untersucht.
Ging es in der Census-I-Untersuchung noch um die meistgenutzten Debian-Pakete und die Sicherheit rund um den Linux-Kernel, widmet sich die Core Infrastructure Initiative Census II nun den zentralen FOSS-Komponenten, die zum Beispiel in Anwendungen auf dem Production-Server laufen, Maven und NPM wären hier Beispiele.
Freie und quelloffene Software läuft zwar mittlerweile auf extrem vielen Infrastrukturen weltweit, doch einige der verwendeten Kernkomponenten bergen Sicherheitsrisiken in sich. Das liegt auch daran, dass Entwickler nicht jede kleine Komponente in ihren Frameworks auf die Sicherheit hin abklopfen. Auf diese Weise landen immer wieder Komponenten in den Architekturen und Frameworks, die potenziell unsicher sind, weil alte Versionen zum Einsatz kommen, die niemand mehr betreut, die Maintainer zu wenig Ressourcen haben, um die Sicherheit zu gewährleisten oder weil bekannte Sicherheitslücken in der Software stecken.
Heartbleed-Fallout
Das Problem ist nicht neu: 2014 entflammte im Zuge von Heartbleed, einer gravierenden Lücke in Open SSL, die Debatte um unsichere Komponenten in Open-Source-Stacks. Seitdem hat sich zum Beispiel im Open-SSL-Projekt sehr viel getan, sind aber auch Projekte wie die Core Infrastructure Initiative (CII) entstanden, die sich damit beschäftigen, zentrale Open-Source-Komponenten und ihre Schwachstellen zu identifizieren. Sie hilft dann mit Ressourcen und Geld, diese Lücken zu beheben.
Ziel ist der CII ist, eine sichere und vertrauenswürdige Basis aufzubauen, in der auch die kleinste Komponente noch hinreichende Sicherheit gewährleistet. Solche nachträglichen Korrekturen sind sicherlich nicht ideal, Security sollte üblicherweise Teil des gesamten Entwicklungszyklus sein. Dennoch zeigt das Beispiel Open SSL auch, dass auch späte Maßnahmen durchaus Sinn ergeben und Risiken minimieren.
Census II
Die CII hat nun zusammen mit dem Laboratory for Innovation Science at Harvard University (LISH) einen Census II genannten vorläufigen Bericht veröffentlicht, der die Sicherheit von Projekten untersucht, die in weit verbreiteten Open-Source-Anwendungen häufig zum Einsatz kommen. Ziel sei es nicht, mit dem Finger auf kritische Projekte zu zeigen. Vielmehr will das Projekt Erkenntnisse zu strukturellen Problemen sammeln, um in Zukunft die Kern-Infrastruktur besser abzusichern.
Zusammen mit mehreren Firmen aus dem SCA-Bereich (Software Composition Analysis) hat die CII nun freie Kernkomponenten identifiziert, die in zahlreichen Software-Stacks, darunter auch in proprietären, stecken beziehungsweise deren Basis bilden. Am Ende präsentiert das Dokument eine Top-Ten-Liste mit Javascript-Komponenten und eine weitere Top-Ten-Liste mit zentralen Komponenten, die kein Javascript verwenden. Das Ergebnis: Vor allem Komponenten für NPM (Javascript) und Maven (Java) scheinen in diesen beiden Bereichen zentrale Rollen zu spielen.
Drei Erkenntnisse
Drei strukturelle Erkenntnisse ziehen die Forscher aus ihren ersten Untersuchungen: Erstens sehen sie einen Bedarf für eine standardisierte Namensgebung für Software-Komponenten. Ohne diese sei es Organisationen nur schwer möglich, sich über Probleme in ihrer Software auszutauschen. Dieses Problem sei auch nicht neu, das National Institute for Standards and Technology (NIST) kämpfe seit Jahrzehnten damit.
Zweitens hänge noch immer viel Software in den individuellen Repositories der Entwickler. Diese seien oft weniger gut geschützt als organisatorische, zentrale Repositories und damit anfälliger für Backdoors. Zudem bestehe die Gefahr, dass Entwickler ihre Komponenten aus dem Repository zurückziehen und damit komplettes Chaos verursachen, wie es 2016 aufgrund eines Markenstreits geschah.
Drittens zeigte sich bei den Untersuchungen, dass für eine Aufgabe häufig Software A zum Einsatz komme obwohl sich viele Entwickler einig darüber sind, dass Software B dieselbe Funktionalität biete, aber wesentlich besser betreut werde und aktueller sei. Oder anders formuliert: Frameworks und Stacks verwenden mitunter Legacy-Software. Der Grund liegt auf der Hand: Die wenigen Maintainer kümmern sich eher um die neueren Pakete und fassen die scheinbar funktionierenden Teile nicht an. Das fällt den Maintainern aber spätestens dann auf die Füße, wenn eine alte Komponenten Ärger macht, aber niemand mehr dahinter ist, der sie repariert.
Die CII will nun Konsequenzen aus ihren Erkenntnissen ziehen. Sie will Projekte unterstützen, die sich um einheitliche Identifizierungen von Software-Komponenten kümmern. Zugleich will sie aber auch den positiven Beitrag von FOSS für die vorhandenen IT-Ökosysteme würdigen und im März 2020 eine Umfrage unter FOSS-Entwicklern starten. Die soll nicht nur die Relevanz von FOSS-Projekten für die Ökonomie erkunden, sondern will sich auch mit der Zeit beschäftigen, die FOSS-Entwickler neben ihrem Hauptjob ihren Projekten widmen. Weitere Details zur Studie liefert das PDF der CII.
