Open Source Software ist mittlerweile allgegenwärtig. Unabhängig von der Branche baut jedes Unternehmen auf Software, um seine geschäftlichen Anforderungen zu erfüllen. Und die meisten von Unternehmen entwickelten und genutzten Anwendungen enthalten in ihrem Code Open-Source-Elemente. Mit der industriellen Umstellung auf cloudnative Anwendungen und durch die wachsende Komplexität steigt das Risiko auch im Bereich Softwaresicherheit. Unternehmen sollten innerhalb des gesamten Lebenszyklus der Softwareentwicklung (SLDC) Best Practices für Open-Source-Abhängigkeiten implementieren und die richtigen Tools auswählen, um ihr Open-Source-Risiko zu managen. Zwei entscheidende Schritte, um Code vor solchen Risiken zu schützen, sind die Schulung der Entwickler und die Implementierung eines leistungsstarken Tools für die Software Composition Analysis (SCA).

Der OSSRA Report 2022 fasst wichtige Informationen über die breite Akzeptanz von Open Source Software und die damit verbundenen Sicherheitsrisiken zusammen. Der Bericht hat dazu insgesamt 17 verschiedene Branchen unter die Lupe genommen, von denen vier – Computerhardware und Halbleiter, Cybersicherheit, Energie und Cleantech sowie das Internet der Dinge – in 100 % aller geprüften Codebasen Open-Source-Komponenten aufwiesen. In den übrigen Branchen liegt der Open-Source-Anteil bei 93 % bis 99 %.

Der Bericht konstatiert weiterhin, dass Lizenzkonflikte zwar zurückgegangen sind – sie wurden in 53 % der Codebasen gefunden, verglichen mit 65 % im Jahr 2020 –, dass aber die Zahl der ungeprüften Abhängigkeiten zugenommen hat. Das heißt, wenn Entwickler Open-Source-Abhängigkeiten einführen, sind sie sich oftmals nicht bewusst, dass transitive Abhängigkeiten auch Lizenzbedingungen enthalten. So enthalten beispielsweise einige Versionen der beliebten Komponente node.js eine Abhängigkeit, die Code nutzt, der unter der CC-SA 3-Lizenz lizenziert ist. Das kann zu unerwünschten Anforderungen an die jeweiligen Lizenznehmer führen und eine rechtliche Prüfung auf mögliche IP-Probleme hin erfordern.

Lizenzkonflikte und hochriskante Schwachstellen gehen zurück. Das ist ein ermutigender Befund. Dennoch bleibt die Tatsache bestehen, dass über die Hälfte der geprüften Codebasen Lizenzkonflikte und fast die Hälfte hochriskante Schwachstellen aufweisen. Noch beunruhigender ist, dass von den 2.097 geprüften Codebasen, die auch eine Risikobewertung durchlaufen haben, 88 % veraltete Versionen von Open-Source-Komponenten enthalten. Das heißt, es waren ein Update oder ein Patch verfügbar, wurden aber nicht eingespielt.

Es gibt berechtigte Gründe dafür, Software nicht zwangsläufig auf dem neuesten Stand zu halten. Aber wenn ein Unternehmen kein genaues und aktuelles Open-Source-Inventar führt, geraten nicht aktualisierte Komponenten leicht in Vergessenheit. Oft bis sie für einen hochriskanten Exploit anfällig werden.

Genau das ist bei Log4j passiert. Natürlich stellt der Exploit selbst eine Gefahr dar. Das daraufhin entstehende Durcheinander beim Versuch, die Schwachstelle zu beheben, hatte aber vor allem einen Grund: Unternehmen wussten nicht, wo sich Log4j in ihren Systemen und Anwendungen befinden könnte. Etliche Unternehmen mussten erst mühsam herausfinden, ob sie überhaupt vorhanden sein könnte.

 

Legen Sie vor einer Krise Best Practices für Open-Source-Abhängigkeiten fest 

Ein umfassendes Programm für das Management von Open Source Software einzurichten, ist für die meisten Firmen eine Herausforderung. Es gibt aber einige Best Practices, die den Einstieg erleichtern.

Wer bei der nächsten Zero-Day-Schwachstelle nicht in Panik geraten will, braucht Software-Governance, um Unternehmensressourcen und Daten zu schützen. Dazu gilt es, eine Strategie zu entwerfen, Genehmigungsverfahren einzuführen sowie eine gründliche Softwareprüfung bestehender OSS-Abhängigkeiten durchzuführen.

 

1. Legen Sie eine Strategie fest

Eine Open-Source-Richtlinie zu erstellen, minimiert die rechtlichen, technischen und geschäftlichen Risiken, wenn Open Source Software eingesetzt wird. Eine Open-Source-Softwarerichtlinie und ein Governance-Programm konzentrieren sich auf zwei Bereiche: Zum einen auf die Verwendung von Open Source Code im Entwicklungsprozess, zum anderen auf die interne Nutzung von Open Source Software – etwa um den IT-Betrieb und -Support zu erleichtern. Einige Unternehmen richten sogar ein eigenes Büro ein, um alles zu verwalten, was mit Open Source Software zu tun hat.

Der erste Schritt zur Erstellung einer Open-Source-Richtlinie besteht darin, die wichtigsten Stakeholder zu ermitteln. Das sind diejenigen, die von der Richtlinie direkt betroffen sind, wie z. B. Entwickler, bis hin zu Führungskräften, die die Richtlinie genehmigen müssen und die Risiken bei der Verwendung von Open Source Software tragen. Zu den Stakeholdern zählen aber auch IT-Mitarbeiter, Teamleiter, Rechtsexperten, die zur Compliance mit Open-Source-Lizenzen beraten, und Softwarearchitekten. Alle wichtigen Stakeholder sollten so früh wie möglich in den Prozess einbezogen werden.

Die strategische Richtlinie sollte die Unternehmensziele hinsichtlich der Integration von Open Source Software umreißen, den Umfang der derzeit verwendeten Open Source Software ermitteln und die angestrebte Nutzung definieren. Die Richtlinie sollte zusätzlich festlegen, welche Open-Source-Lizenzen abgedeckt sind und wie sich die Nutzung von Open Source Software für die interne Entwicklung und die ausgelieferte Software unterscheiden. Man sollte weiterhin einen Beschaffungs- und Auswahlprozess für OSS einrichten. Im Idealfall legt ein solcher Prozess ausdrücklich fest, welche Websites, Repositories und Methoden bei der Beschaffung von Open Source Software zugelassen sind und wie Sie entscheiden, ob ein bestimmtes Paket für die Aufgabe geeignet ist. Außerdem sollte man festgelegen, wer Open Source Software herunterladen darf, woher diese stammt und ob eine Genehmigung erforderlich ist, bevor sie heruntergeladen, verwendet oder weitergegeben werden darf.

 

2. Etablieren Sie einen Genehmigungsprozess 

Sie sollten einen Genehmigungsprozess einziehen, mit dem Sie feststellen können, ob ein Softwarepaket den Anforderungen und Qualitätsstandards des Unternehmens entspricht. Dabei sollten Sie Kriterien berücksichtigen wie die Codequalität, den Grad der Unterstützung, Projektreife, Reputation der Mitwirkenden und Schwachstellentrends.

Ein Genehmigungsprozess, der diese Kriterien berücksichtigt, schützt Teams davor, dass verschiedene Versionen desselben Softwarepakets im Code des jeweiligen Unternehmens verstreut sind. Jede einzelne davon ist möglicherweise nicht ordnungsgemäß gepatcht und aktualisiert worden. Wenn ein Genehmigungsprozess funktionieren soll, müssen die Anfragen schnell bearbeitet werden. Eine Liste der vorab genehmigten Open-Source-Programme zu erstellen, kann diesen Prozess unterstützen.

Es gibt auch Organisationen, die auf einen datenbasierten und agilen Ansatz setzen: neu entdeckte Komponenten enthalten vordefinierte Metriken. Diese müssen gewisse Kriterien berücksichtigen, bevor das Tool die Komponente zulässt.

 

3. Entwerfen Sie einen Audit-Prozess, um Open Source Software aufzuspüren 

Ein Audit stellt nicht nur sicher, dass die internen Richtlinien eingehalten werden, sondern bietet auch einen vollständigen Überblick darüber, welche Open Source Software Sie verwenden. Dies hilft, Komponenten zu identifizieren und zu lokalisieren. Das ist besonders wichtig, um die Compliance von Open-Source-Lizenzen aufrechtzuerhalten und im Falle, dass eine Schwachstelle offengelegt wird.

Open-Source-Scans sollte man während des gesamten SDLC durchführen. Aber Sie sollten sicherstellen, dass immer, wenn eine Anwendung in einen Release Candidate integriert wird, der Open Source Software verwendet, ein abschließender Scan läuft. Insbesondere wenn ein Unternehmen auf Komponenten von Drittanbietern baut.

Um anfällige Komponenten in Ihren Anwendungen zu lokalisieren, müssen Sie zunächst ALLE Open-Source-Komponenten darin identifizieren. Dazu müssen Sie sämtliche Versionen und Forks des Codes berücksichtigen, Komponenten in Quell- und Binärform erkennen, kommerzielle Software analysieren, in die häufig Open Source eingebettet ist, und nicht nur das betrachten, was in Paketmanagern deklariert wurde. Diese Aufgabe zu automatisieren, erspart es einem Team, manuelle und oft ungenaue Open-Source-Verzeichnisse zu führen. Außerdem lassen sich verwundbare Komponenten so schnell ausfindig machen, und Sie wissen sofort, wenn neue Schwachstellen gemeldet werden. Ein vollständiges Inventar ist der erste Schritt. Denn sie können nur das patchen, von dem sie wissen, dass es existiert.

Nach dem Abschluss eines Audits sollte man damit fortfahren, einen Plan zu erstellen, um Lücken zu schließen und Compliance zu erlangen. Zu diesen Aufgaben kann es beispielsweise gehören, den Quellcode bereitzustellen oder verfügbar zu machen, die erforderlichen Hinweise in Ihren Code oder Ihre Dokumentation aufzunehmen und die Endbenutzer-Lizenzvereinbarung zu aktualisieren. Im Falle, dass Compliance nicht umsetzbar ist, sollten Sie nach Alternativen suchen, zum Beispiel in Form alternativer Bibliotheken.

Auch nach dem Software-Release ist es wichtig, die enthaltenen Open-Source-Komponenten weiterhin zu überprüfen. Hier bieten sich Tools mit einer eingebauten »Monitoring«-Funktion an, ohne dass die Software in Produktion jeden Tag gescannt werden muss. Bei einer neuen Schwachstelle in der betreffenden Open-Source-Komponente werden Teams automatisch benachrichtigt.

Stanislav Sivak, Synopsys