Linus Torvalds, der Schöpfer von Linux und Git, hat sein eigenes Gesetz für die Softwareentwicklung, und das geht so: „Wenn genug Augen da sind, sind alle Bugs flach.“ Dieser Satz bringt das Prinzip von Open Source auf den Punkt: Je mehr, desto besser – wenn der Code für jeden leicht zugänglich ist, um Fehler zu beheben, ist er ziemlich sicher. Aber ist das so? Oder gilt das Sprichwort „all bugs are shallow“ nur für oberflächliche Fehler und nicht für solche, die tiefer liegen? Es stellt sich heraus, dass Sicherheitslücken in Open Source schwieriger zu finden sind, als wir dachten. Emil Wåreus, Leiter der Forschungs- und Entwicklungsabteilung bei Debricked, hat es auf sich genommen, die Leistung der Community genauer zu untersuchen. Als der Datenwissenschaftler, der er ist, fragte er natürlich die Daten: Wie gut ist die Open-Source-Gemeinschaft darin, Sicherheitslücken rechtzeitig zu finden?
Der Nervenkitzel der (Schwachstellen-)Jagd
Das Auffinden von Open-Source-Schwachstellen wird in der Regel von den Betreuern des Open-Source-Projekts, von Benutzern, Prüfern oder externen Sicherheitsforschern durchgeführt. Aber trotz dieser großartigen Code-Archäologen, die dazu beitragen, unsere Welt zu sichern, tut sich die Gemeinschaft immer noch schwer damit, Sicherheitslücken zu finden.
Im Durchschnitt dauert es über 800 Tage, bis eine Sicherheitslücke in Open-Source-Projekten entdeckt wird. Die berüchtigte Sicherheitslücke in Log4shell (CVE-2021-44228) blieb zum Beispiel satte 2649 Tage unentdeckt.
Die Analyse zeigt, dass 74% der Sicherheitslücken tatsächlich mindestens ein Jahr lang unentdeckt bleiben! Java und Ruby scheinen hier die größten Herausforderungen zu haben, denn die Community braucht mehr als 1000 Tage, um Sicherheitslücken zu finden und zu veröffentlichen. Unser [weißer] Hut geht an die PHP/Composer-Community, die die anderen leicht übertrifft.
Die Nadel im Techstack
Interessant ist auch, dass einige der verschiedenen Schwachstellentypen (CWE) anscheinend schwerer zu finden und zu veröffentlichen sind, was eigentlich dem Gesetz von Linus widerspricht. Die Schwachstellen CWE-400 (Unkontrollierter Ressourcenverbrauch) und CWE-502 (Deserialisierung von nicht vertrauenswürdigen Daten) sind in der Regel nicht auf eine einzelne Funktion beschränkt oder können als beabsichtigte Logik in der Anwendung erscheinen. Mit anderen Worten: Es handelt sich nicht um einen „oberflächlichen Fehler“.
Es scheint auch, dass die Entwicklergemeinschaft etwas besser darin ist, CWE-20 (Improper Input Validation) zu finden, bei dem der Fehler meist nur ein paar Zeilen Code in einer einzigen Funktion ist.
Schwachstellen mit leistungsfähigen Abhilfemaßnahmen beheben
Warum ist das wichtig? Als Nutzer von Open Source, und das sind so ziemlich alle Unternehmen auf der ganzen Welt, ist das Problem der Sicherheitslücken in Open Source ein wichtiges. Die Daten zeigen uns, dass wir dem Linus’schen Gesetz nicht ganz trauen können – nicht weil Open Source weniger sicher ist als andere Software, sondern weil nicht alle Bugs oberflächlich sind.
Zum Glück gibt es leistungsfähige Tools, mit denen man viele Open-Source-Projekte auf einmal analysieren kann. Es hat schon [White Knight Hacker gegeben, die mit diesen Methoden Tausende von Sicherheitslücken auf einmal aufgedeckt haben]. Es wäre naiv, nicht davon auszugehen, dass böswillige Organisationen und Einzelpersonen dasselbe tun. Als Ökosystem, das die Grundlage für unsere softwarezentrierte Welt bildet, muss die Gemeinschaft ihre Fähigkeit, Sicherheitslücken in Open Source zu finden, offenzulegen und zu beheben, deutlich verbessern.
Letztes Jahr hat Google 10 Milliarden Dollar für einen Open-Source-Fonds bereitgestellt, um die Sicherheit von Open Source zu verbessern.
Darüber hinaus hilft Debricked Unternehmen dabei, diese Schwachstellen nutzbar zu machen, indem es ihre gesamte Software, jeden Branch, jeden Push und jeden Commit auf neue (Open-Source-)Schwachstellen hin überprüft. Debricked scannt sogar kontinuierlich alle alten Commits auf neue Schwachstellen, um sicherzustellen, dass sie aktuelle, genaue und umsetzbare Informationen über den von dir genutzten Open Source liefern. Debricked hilft Entwicklern sogar dabei, deine Sicherheitslücken mit automatisierten Pull-Requests zu beheben, ohne dass es zu einer Abhängigkeitshölle kommt – ziemlich toll!
Die Wahrheit liegt in den Daten
Was ist also der beste Weg, um dein Projekt oder dein Unternehmen vor Open-Source-Schwachstellen zu schützen? Wie wir im Fall von Log4j und Spring4shell sowie bei den Zahlen gesehen haben, können wir nie wirklich darauf vertrauen, dass die Community alle Risiken findet und behebt. Die Wahrscheinlichkeit ist groß, dass es in deinem Code noch viele unentdeckte und nicht veröffentlichte Schwachstellen gibt, und du kannst nicht viel dagegen tun.
Laut Debricked ist die beste Möglichkeit, dies zu verhindern, die Einführung eines kontinuierlichen Schwachstellen-Scans in deinem SDLC. In Kombination mit der auf maschinellem Lernen basierenden Schwachstellendatenbank wird bei jeder Änderung des Codes automatisch gescannt. So bist du in Echtzeit auf dem neuesten Stand und erfährst von neuen Schwachstellen, bevor es jemand anderes tut. Sobald eine Schwachstelle behoben ist, kannst du automatisch einen Fix Pull Request generieren oder die Schwachstelle manuell mit Hilfe von Debricked beheben. Derzeit bietet Debricked Korrekturen für JavaScript und Go an, weitere Sprachen werden in Kürze unterstützt.