Die Softwareentwicklung startet selten bei Null. Entwickler-Teams greifen auf bestehenden “Legacy”-Code zurück, arbeiten mit Dritt-Zulieferern zusammen und verlassen sich auf Open-Source-Software(OSS)-Komponenten, die auf GitHub & Co. zur freien Verfügung stehen. In heutigen kommerziellen Anwendungen macht OSS bis zu 80-90% des Codes aus. 

Umso erstaunlicher ist daher die Betriebsblindheit von Unternehmen, wenn es um die Dokumentation der OSS-Codebausteine geht. Im Rahmen von Software-Audits werteten die Analysten von Revenera mehr als 2,6 Milliarden Codezeilen aus und entdeckten dabei 230.000 kritische Fälle. Damit findet sich alle 11.500 Codezeilen ein Compliance-Verstoß oder eine Software Vulnerability. 83% der in den Audits aufgedeckten Risiken war den Entwickler-, Sicherheits- und Compliance-Teams der Unternehmen im Vorfeld der Untersuchung unbekannt.

Open Source Audits: Wissenslücke bei der Verwendung von OSS (Quelle: Bitsea / Revenera)

Sicherheitsfrage: Der Datenschutz-Gau bei Equifax

Unwissenheit schützt nicht vor Strafe. Und wer nicht weiß, welche OSS-Komponenten an welcher Stelle in seiner Software verbaut sind, kann kaum deren Sicherheit garantieren. Fast 90% der Cyberangriffe zielen auf die Anwendungsebene ab, darunter Software-Schwachstellen und fehlerhafte Codes. Sobald also eine Vulnerability mit hohem Sicherheitsrisiko veröffentlicht wird, beginnt ein Wettlauf mit der Zeit. Sicherheits-Teams müssen den gesamten Softwarecode einer jeden Anwendung schnellstmöglich auf die betreffende Schwachstelle scannen und die Lücke patchen. Andernfalls riskieren sie einen schmerzhaften und oft kostspieligen Cyberangriff inklusive Data Breach.

Der Exploit einer Schwachstelle bei der US-Wirtschaftsauskunftei Equifax gilt hier immer noch als Paradebeispiel mangelnder Open-Source-Governance. Apache Struts ist ein Open-Source-Framework, das in gängigen Webanwendungen zum Einsatz kommt. Ein Patch für die Schwachstelle stand schon nach kurzer Zeit bereit. Trotzdem versäumte es Equifax, die Sicherheitslücke zu schließen. Dem Finanzdienstleister fehlte schlichtweg eine Übersicht der betroffenen Anwendungen. Ein halbes Jahr später drangen Hacker in die IT-Systeme ein und erbeuteten hochsensible Daten von rund 143 Millionen Menschen – darunter Kreditkarten- und Sozialversicherungsnummern. Die Führungsebene wurde entlassen und der Aktienwert von Equifax rutschte in den Keller. Ganz zu schweigen von den 700 Mio. US-Dollar Schadensersatz. 

Compliance am Beispiel von GPL & BMW

Das Sicherheitsbewusstsein in Sachen Open-Source ist angesichts solcher Vorfälle (darunter Solar Winds, Heartbleed) deutlich gewachsen. Anders sieht es jedoch bei der Compliance aus. Eine Ansicht hält sich dabei hartnäckig: Open-Source ist frei verfügbar. Das stimmt, allerdings ist diese Freiheit in den allermeisten Fällen an bestimmte Verpflichtungen gebunden. So gut wie jeder Code hat einen Autor (Urheber), der sein Werk unter eine Lizenz stellen kann. Die meisten Autoren in der Open-Source-Gemeinschaft wollen, dass ihr Code wiederverwendet wird und sind sehr freizügig. Es gibt jedoch auch restriktive OSS-Lizenzen. 

Ein gutes Beispiel ist hier GNU General Public License. Entwickler können GPL-lizenzierten Quellcode kostenfrei und legal nutzen, kopieren, weiterverbreiten und ändern. Allerdings müssen alle Entwicklungen, die auf GPL basieren, ebenfalls offengelegt werden. Bei kommerziellen Anwendungen stehen Unternehmen hier verständlicherweise vor einem Dilemma. Als ein Mitglied der Open-Source-Community beispielweise entdeckte, dass Teile der Fahrzeugsoftware des BMW i3 unter GPL stehen, musste der Automobilhersteller notgedrungen den Quellcode der verwendeten OSS weitergeben. Letztendlich landete der Code sogar auf GitHub  – einschließlich potenzieller Sicherheitslücken und Angriffspunkte. 

Es gibt eine Vielzahl von OSS-Lizenzen mit unterschiedlichsten Verpflichtungen. Manchmal fehlen Angaben gänzlich. In anderen Fällen herrscht Unklarheit, wie die Lizenz auszulegen ist. Wie beispielsweise lässt sich entscheiden, ob eine OSS-Komponente tatsächlich „for good and not for evil“ genutzt wird? Doch egal wie frei, streng oder kurios die Vorgaben auch sein mögen, Unternehmen müssen sie zunächst kennen, um sie erfüllen zu kommen. 

Lizenz-Wechsel: Von frei zu un-frei  

Compliance ist nicht nur eine Frage der Transparenz, sondern auch eine Frage der Kontinuität. Denn Lizenzen können sich ändern. Tatsächlich zeichnet sich bei OSS ein Trend ab: Autoren wechseln von einer sehr freizügigen Lizenz in eine sehr restriktive. Die Gründe dafür sind vielfältig. Oft resultiert die Änderung aus dem Gefühl heraus, die OSS-Lizenz sei „missbraucht“ worden. Die Suchmaschine Elasticsearch beispielsweise wechselte nach Problemen mit der Finanzierung auf eine nicht-freie Lizenz. Bis dahin erlaubte die OSS-Lizenz den großen Cloud-Hostern wie AWS, den Code als gehostete Lösung in ihre Services zu integrieren. Von den damit erwirtschafteten Gewinnen kam jedoch nichts beim Hauptentwickler Elastic an. Um solche Änderungen bei OSS-Lizenzen im Auge zu behalten ist ein kontinuierliches Monitoring and Management maßgeblich. 

Exportkontrolle: Andere Länder, andere Regelungen

Sicherheitslücken und Compliance-Verstöße sind längst nicht die einzigen Risiken bei der unkontrollierten und undokumentierten Verwendung von OSS. Unterschätzt und hochkomplex ist die Exportkontrolle. Grundsätzlich kann die Lieferung von Waren in andere Länder genehmigungspflichtig sein. Ziel ist es beispielsweise, die Verbreitung von Massenvernichtungswaffen zu verhindern. Nach europäischem wie nationalem Recht fallen auch Technologien, Software und Datenverarbeitungsprogramme in diese Kategorie, da sie das Know-how für die Entwicklung und Fertigung stellen.  

Befindet sich in einer Software eine OSS-Komponente, die einer Exportbeschränkung unterliegt, und wird dieses Software-Produkt trotzdem exportiert, sind strafrechtliche Konsequenzen unausweichlich. Tatsächlich haftet in diesem Fall der Geschäftsführer bzw. CEO persönlich. Aus der Lizenz selbst geht zwar der Urheber, seine Herkunft und damit die Ausfuhrgesetze hervor. Schließlich gibt es Tausende von OSS-Komponenten in einer Software. Und es gibt unterschiedliche Einfuhr- und Ausfuhrbeschränkungen für jedes einzelne Land. Die Komplexität ist enorm. 

Generative AI: Kopie oder Originalwerk?

Eine neue Dimension erreicht das OSS-Management mit der rasanten Verbreitung von KI. Die Generative AI(GenAI)-Anwendung Copilot zum Beispiel hilft Entwicklern beim automatischen Schreiben von Codes und greift für das ML-Training auf den in GitHub bereit gestellten Code zurück. Doch während GitHub Informationen über Autoren, Urheberrecht und Lizenzen enthält, vernachlässigt die KI-Lösung diese Informationen. Tatsächlich wird nicht einmal ersichtlich, woher der Code im Detail stammt. 

Gegen den Anbieter OpenAI liegt in den USA bereits Klage vor. Wie die Gerichte entscheiden werden, ist abzuwarten. Der Fall rührt bereits jetzt an wichtigen Fragen rund um die zukünftige Nutzung von KI im Allgemeinen und OSS im Speziellen. Was darf eine KI? Wie lässt sich Compliance in GenAI integrieren? Was gilt als reine Kopie? Und wo beginnt die Schaffung eines neuen Werks/Produkts (Stichwort: Schöpfungshöhe)?

Best Practices für Open-Source-Nutzung

So viel zu den Risiken von Open-Source Software. Was aber können Unternehmen tun, um die Sicherheit und die Compliance ihrer Anwendungen über die komplette Software Supply Chain zu verbessern? Unternehmen und Entwickler sollten hier früh Grundsteine legen und zentrale Best Practices in ihre Workflows integrieren. Dazu gehören: 

• Software Composition Analysis (SCA), um Schwachstellen frühzeitig im Software-Entwicklungszyklus (SDLC) zu identifizieren und zu beheben. 
• Das Erstellen einer Software Bill of Material (SBOM) für jede Anwendung, um alle eingesetzten Komponenten (OSS und Dritt-Anbieter), einschließlich ihrer Abhängigkeiten, festzuhalten.
• Automatisierte Tracking- und Analysetools, um alle Komponenten nachzuverfolgen – unabhängig davon, ob sie aus dem Unternehmen selbst oder aus einer externen Quelle stammen. 
• Interne Trainings und Management-Schulungen, um das Sicherheitsbewusstsein von Entwicklerteams im Umgang mit Open-Source zu schärfen. 
• Open Source Program Office (OSPO), um Open-Source Compliance- und Sicherheitsrichtlinie konsequent und abteilungsübergreifend durchzusetzen.  

Darüber hinaus lohnt es sich für Unternehmen, mit der Open-Source-Community und dem damit verbundenen Ökosystem in Kontakt zu bleiben. Open-Source-Software lebt von der Zusammenarbeit und dem engen Austausch zwischen Entwicklern und Anwendern. Wer hier proaktiv zur Gemeinschaft beiträgt und eine faire Nutzung von OSS vorlebt, kann bei schwer zu erfüllenden oder kontroversen Lizenzvorgaben auch Rat bei rechtlichen Fragen und Best Practices einholen.