Die 10 größten identifizierten Risiken von Open-Source-Software

Im Rahmen von Bemühungen, Cybersecurity-Teams besser über Probleme aufzuklären, die zu einer Kompromittierung von Software-Lieferketten führen können, hat Endor Labs, ein Anbieter von Plattformen für die Verwaltung von Open-Source-Software, einen Bericht veröffentlicht, in dem die 10 größten Risiken von Open-Source-Software im Jahr 2023 aufgeführt sind. Primäres Ziel ist es, ein größeres Bewusstsein für Probleme in Sachen Anwendungssicherheit zu schaffen, die sich aus der Art und Weise ergeben, wie Open-Source-Software entwickelt wird. Die Liste umfasst:

Bekannte Schwachstellen: Eine Version einer Softwarekomponente kann anfälligen Code enthalten, der versehentlich von seinen Entwicklern eingeführt wurde.  Wenn Details zu Schwachstellen öffentlich bekannt gegeben werden, ist möglicherweise nicht ohne Weiteres ein Patch verfügbar.

Ungewartete Software: Eine Softwarekomponente wird möglicherweise nicht mehr aktiv entwickelt, was zur Folge hat, dass Patches für funktionale und nicht funktionale Bugs nicht rechtzeitig oder überhaupt nicht bereitgestellt werden.

Name-Confusion-Angriffe: Angreifer können Komponenten erstellen, deren Name denen legitimer Open-Source- oder Systemkomponenten ähnelt, auch Typosquatting genannt. Sie könnten ebenfalls versuchen, vertrauenswürdige Autoren zu imitieren (Brand-Jacking) oder mit üblichen Benennungsmustern in verschiedenen Sprachen oder Ökosystemen zu spielen (Combosquatting).

Kompromittierung legitimer Pakete: Angreifer können Ressourcen kompromittieren, die Teil eines bestehenden legitimen Projekts oder einer zugehörigen Vertriebsinfrastruktur sind, um bösartigen Code in Softwarekomponenten einzuschleusen.

Veraltete Software: Ein Projekt kann eine veraltete Version einer Softwarekomponente verwenden, obwohl eine neuere, sicherere Version existiert.

Nicht überwachte Abhängigkeiten: Unter Umständen sind sich Entwickler einer Abhängigkeit von einer Komponente nicht bewusst, da sie Teil eines anderen Upstream-Moduls ist, das sie verwendet haben.

Lizenz-Risiken: Es kann sein, dass eine Softwarekomponente oder ein Projekt überhaupt nicht über eine Lizenz verfügt, oder dass ihre bzw. seine Lizenz nicht mit dem geplanten Verwendungszweck vereinbar ist oder über Anforderungen verfügt, die nicht erfüllt werden (können).

Unausgereifte Software: Ein Open-Source-Projekt wendet möglicherweise keine bewährten Entwicklungspraktiken an, sodass z. B. ein Standard-Versionierungsschema genutzt wird oder es an einer Regressionstestsuite, Überprüfungsrichtlinien oder Dokumentation mangelt.

Nicht genehmigte Änderungen: Eine Softwarekomponente kann sich ändern, ohne dass Entwickler solche Änderungen bemerken, überprüfen oder genehmigen können, entweder weil der Download-Link auf eine nicht versionierte Ressource bzw. eine böswillig geänderte versionierte Ressource verweist oder aufgrund einer unsicheren Datenübertragung.

Unbekannte Herkunft: Details über den Quellcode, den Build-Prozess oder den Vertriebsprozess einer Softwarekomponente können unbekannt oder nicht überprüfbar sein.

Unternehmen benötigen einen besseren Überblick über die potenziellen operationellen Risiken, die mit der zunehmenden Abhängigkeit von Open-Source-Software einhergehen, da sich nach einer Reihe von aufsehenerregenden Sicherheitsverletzungen immer mehr Unternehmen auf die Sicherung ihrer Software-Lieferketten konzentrieren. Das bedeutet nicht, dass Unternehmen weniger Open-Source-Software verwenden sollten, jedoch gibt es Cybersecurity-Probleme, die vielen Entwicklern mitunter nicht immer bewusst sind. Eine unlängst von Endor Labs veröffentlichte Analyse von fast 2000 Softwarepaketen ergab, dass 95 % aller Anwendungsschwachstellen auf eine transitive Abhängigkeit zurückgeführt werden können, die durch die Verwendung einer Open-Source-Komponente durch einen Entwickler entstanden ist.

Unabhängig von der Ursache eines Cybersecurity-Risikos liegt es in der Verantwortung der Cybersecurity-Teams, dieses Risiko zu mindern. Das Problem ist die historische Kluft zwischen Cybersecurity-Teams und Anwendungsentwicklern, die die Bewertung dieser Risiken zu einer großen Herausforderung macht. Die Schwierigkeit besteht darin, dass es nicht möglich ist, diese Risiken zu bewerten, ohne zuerst zu wissen, worauf sich Cybersecurity-Teams konzentrieren müssen.