Was jeder Cybersecurity-Experte zum Thema Open Source wissen sollte
Fred Bals, Verfasser des OSSRA-Berichts
Boris Cipot, Senior Security Engineer, Synopsys Software Integrity Group
Die Ergebnisse des aktuellen 2024 „Open Source Security and Risk Analysis“ (OSSRA) Berichts belegen, dass Open-Source-Komponenten und -Bibliotheken das Rückgrat so gut wie jeder Anwendung in praktisch allen Branche bilden. Geprüft wurden über 1.000 kommerzielle Anwendungen in 17 Industriezweigen (darunter Automobilindustrie, Unternehmenssoftware, Finanzdienstleister und Gesundheitswesen), und alle enthalten Open Source. Die meisten davon in einem Bereich von 99 % bis 100 %
Durchschnittlich wurden 526 Open-Source-Komponenten in jeder einzelnen Anwendung gefunden – ein praktisches Beispiel dafür, warum manuelle Tests, die für eine niedrige Anzahl von Komponenten machbar sein mögen, in großem Maßstab nicht mehr praktikabel. Die Analysen zeigen außerdem, dass risikoreiche Schwachstellen und Lizenzprobleme mindestens ebenso weit verbreitet sind wie Open Source selbst.
Das spiegelt sich auch in der Realität deutscher Unternehmen wider. Die meisten nutzen Open Source, um von möglichen Kosteneinsparungen zu profitieren. Dabei kommt Open Source entweder als Komponente bei der Produktentwicklung oder in fertigen Softwarelösungen zum Einsatz, die mit kommerziellen Angeboten konkurrieren. Leider verfügen längst nicht alle Firmen über eine konsequent verfolgte Open-Source-Strategie, die dem hohen Nutzungsgrad entspricht. Und das hat Folgen. Etwa nicht gepatchte und anfällige Anwendungen. Oftmals wird Open Source auch rechtlich missbräuchlich genutzt. Beides schadet dem Ruf eines Unternehmens und hat finanzielle Konsequenzen. Tatsächlich befolgen Firmen nicht durchgängig den Best Practices, die sich für den Einsatz von Open Source empfehlen. Hat die
Nutzung von OSS einen relativ hohen Reifegrad erreicht, dann wissen die Nutzer, welche Open- Source-Komponenten sie verwenden und wo sie eingesetzt werden. Im Übrigen ist das eine der Voraussetzungen, um OSS insgesamt besser, stabiler und sicherer zu machen. OSS beruht auf einem Modell von Geben und Nehmen. Aber vielen Firmen fehlt es immer noch an einem grundlegenden Verständnis von Open Source – etwa dazu, dass Komponenten eventuell nicht weiterentwickelt werden, oft über Jahre hinweg. Dementsprechend gibt es keine Garantie, dass Schwachstellen und Sicherheitsprobleme weiterhin behoben werden
können (und schon gar nicht automatisch). Ohne entsprechende Strategie bewegen Firmen sich auf unsicherem Terrain.
Ältere Open-Source-Komponenten sind überall – inklusive ihrer Schwachstellen
84 % aller untersuchten Anwendungen, deren Risiko bewertet wurde (insgesamt 933), enthielten mindestens eine bekannte Open-Source-Sicherheitslücke, 74 % sogar hochriskante Schwachstellen. Dies markiert einen deutlichen Anstieg gegenüber den letztjährigen OSSRA- Befunden: da waren es noch 48 %. Über die Ursachen für diesen Anstieg lassen sich nur Vermutungen anstellen. Eine mögliche Erklärung liegt in der angeschlagenen Weltwirtschaft, die sich auch auf verfügbare Ressourcen in Sachen Patchen und Problembeseitigung ausgewirkt haben mag. Aufschlussreicher ist aber die Tatsache, dass 91 % der Anwendungen Open-Source- Komponenten enthielten, die 10 Versionen oder mehr hinter der aktuellen verfügbaren Version zurücklagen. Die offensichtliche Schlussfolgerung aus diesem dramatischen Befund: Die Mehrheit der Entwickler verzichtet darauf, die von ihnen verwendeten Komponenten zu aktualisieren. Das bestätigen sowohl der OSSRA-Bericht als auch ein früherer Report von Veracode: 79 % der untersuchten Fälle wiesen ältere Open-Source-Komponenten auf, die nie aktualisiert wurden. Viele Entwicklerteams haben in Sachen Open Source nach wie vor eine „plug-in and forget“- Mentalität – bis akute Probleme auftreten oder eine medienwirksame Sicherheitslücke wie Log4Shell sie zum Handeln zwingt.
Das Problem ist offensichtlich allgegenwärtig, und anfällige Bibliotheken von Drittanbietern werden in der OWASP-Top-Ten-Liste der höchsten Sicherheitsrisiken für Webanwendungen aufgeführt. Laut OWASP ist eine Anwendung anfällig, wenn Sie nicht wissen, welche Versionen Sie verwenden, wenn Sie nicht mehr unterstützte oder veraltete Komponenten verwenden oder wenn Sie keine regelmäßigen Fixes/Upgrades für Open Source einspielen.
Wer ältere, anfällige Versionen von Open-Source-Software verwendet, der riskiert gravierende Folgen. Platz 2 der 10 der wichtigsten im OSSRA-Bericht 2024 gefundenen Schwachstellen
belegt beispielsweise eine XSS-Schwachstelle (Cross-Site-Scripting) in den jQuery-Versionen 1.2 bis 3.5.0. Das Problem wurde vor fast vier Jahren (!) mit jQuery 3.5.0. behoben, aber ein Drittel der untersuchten Anwendungen verwendet immer noch eine anfällige jQuery-Version. Beim Ausnutzen dieser Schwachstelle, werden etwa manipulierte Daten verwendet, um in ein System einzudringen oder sensible Daten (Passwörter, Kreditinformationen) offengelegt. Laut OSSRA war jQuery die Komponente, die am ehesten Schwachstellen aufwies. Und das, obwohl für jede der im Bericht aufgeführten jQuery-Schwachstellen bereits Patches verfügbar waren.
Acht der zehn wichtigsten Schwachstellen lassen sich zudem einer CWE-Säule , CWE-707, zuordnen. Hier werden Sicherheitsanforderungen gelistet, die bei Nichtbeachtung zu Cross-Site Scripting-Angriffen und SQL-Injection führen können. XSS ist so weit verbreitet wie gefährlich und steht mit den meisten der 10 im OSSRA-Bericht genannten Schwachstellen in Verbindung. Das Ziel der meisten XSS-Angriffe ist im Übrigen nicht der Host selbst, sondern die jeweiligen Benutzer der Webanwendung. Immer mehr Unternehmen greifen auf webbasierte Anwendungen zurück, um mit Kunden zu interagieren. Ein idealer Nährboden für XSS- Schwachstellen in kritischen Branchen.
Lizenzkonflikte durch Code Snippets
Auch was potenzielle Lizenzkonflikte sprechen die OSSRA-Daten eine deutliche Sprache. Über die Hälfte (53 %) der geprüften Anwendungen enthielten Open Source mit Lizenzkonflikten. Hier drohen Rechtsstreitigkeiten und weitreichende Auseinandersetzungen beim Thema geistiges Eigentum. Open-Source-Lizenzen schreiben die Verpflichtungen für den Endbenutzer fest, einschließlich der Frage, wie die Komponente verwendet und weitergegeben werden darf, (wenn eine Open-Source-Komponente in einer Software verwendet wird). Entweder fehlt es an ausreichendem Wissen oder Willen auf Entwicklerseite, sich klarzumachen, dass extrahierte Codeschnipsel nicht ohne Lizenzbedingungen zu haben sind. Also den Verpflichtungen, die mit dem größeren Code-Stück verbunden sind, aus dem das Snippet stammt.
Ein ungewollter Verursacher des Problems ist eines der beliebtesten Repositories für Codeschnipsel, “ Stack Overflow „. Die Website lizenziert automatisch alle öffentlich zugänglichen Benutzerbeiträge unter der Creative Commons ShareAlike-Lizenz – einschließlich der auf Stack Overflow geposteten Codeschnipsel. Die CC-SA-Lizenz kann situativ so interpretiert werden, dass sie einen ähnlichen „viralen“ Effekt hat (d. h. jedes Werk, das von einem Copyleft-lizenzierten Werk abgeleitet ist, muss auch unter denselben Copyleft- Bedingungen lizenziert werden) wie die GNU Public License. Aus rechtlicher Sicht ist das problematisch. Laut OSSRA sind besagte CC-SA-Lizenzen die Hauptursache für Lizenzkonflikte, wobei CC-SA 3.0 und 4.0 allein 33 % der gefundenen Lizenzkonflikte verursachen.
Wachsende Risiken durch KI-basierte Coding-Tools
Auch deutsche Firmen beteiligen sich am KI-Hype. Etliche von ihnen befinden sich aber noch in einer Testphase, um Nutzen und Risiken gegeneinander abzuwägen. Bedenken bestehen sowohl was die juristischen Implikationen anbelangt als auch beim Thema Sicherheit – und das nicht unberechtigt. Einige Anbieter von KI-Tools werben bereits damit, dass sie kein Open Source für ihre „Antworten“ verwenden und nehmen für sich in Anspruch, proprietäre oder originelle Antworten zu liefern. Die Frage ist allerdings, wie sicher sind diese Antworten und wie lassen sie sich sicher verwenden. Es empfiehlt sich jedenfalls auch diesen vorgeschlagenen Code mit Technologien wie SAST und SCA zu überprüfen, um etwaige Sicherheitsprobleme oder rechtliche Konflikte aufzudecken. Keinesfalls sollte man dem Code blind vertrauen, denn auch über die Zeit betrachtet, kann sich die Sicherheitslage verschlechtern oder der Code „halluzinieren“.
Traditionell implementieren Entwickler eine Software auf Basis von drei Methoden: selbst geschriebener Code, eingekaufter Code und Open Source Code. Aktuell richtet sich die Aufmerksamkeit auf ein neues Werkzeug – die generative KI und ihr Potenzial, die Softwareentwicklung zu verbessern. Doch seinen Vorläufern nicht ganz unähnlich birgt auch KI- generierter Code Risiken, von denen viele erst noch aufgedeckt werden müssen.
Es ist eine irreführende Annahme, dass KI „sauberen“ Code produziert. Die aktuelle Generation von KI-basierten „Code Completion Tools“ wie sie GitHub Copilot verwendet trainierte, lernintensive große Sprachmodelle (die sogenannten Large Language Models oder LLMs). Sie werden aus Code erstellt, der von Internet-Websites, aus Foren, Repositories und Open-Source- Projekten stammt. Wenn KI auf Basis von vorhandenem Code lernt, ist es nur zu wahrscheinlich, dass der von ihr generierte oder empfohlene Code vererbte Sicherheitslücken und Schwachstellen aus unsicheren Codierungspraktiken aufweist – was potenziell zu Sicherheitslücken führt. Das bestätigt auch eine Umfrage unter Cybersicherheitsexperten aus dem Jahr 2023: Mehr als die Hälfte der Befragten räumte Sicherheitsprobleme mit KI- generiertem Code ein.
Codeschnipsel, die ohnehin schon schwer zu identifizieren sind und Lizenzkonflikte verursachen, werden in KI-erzeugtem Code leicht reproduziert. Wenn ein KI-generiertes Snippet aus einer Open-Source-Komponente mit einem restriktiven Lizenztyp stammt, besteht für jeden, der diesen Code verwendet, ein rechtliches und Compliance-Risiko. In einer derzeit noch verhandelten Sammelklage gegen GitHub, Microsoft und OpenAI, wird der Vorwurf erhoben, dass Copilot sowohl gegen das Urheberrecht als auch gegen die Softwarelizenzbestimmungen verstoßen habe und Code ohne Namensnennung, Urheberrechtsvermerk oder Einhaltung der ursprünglichen Lizenzbedingungen vorschlage.
Für Softwareentwickler ist es vermutlich sicherer, auf den Einsatz von KI-gestützten Kodierungswerkzeugen zu verzichten, bis die Frage gerichtlich geklärt oder eine behördliche Entscheidung getroffen ist. Wie so oft sieht die Realität anders aus. Etliche Entwickler verwenden bereits KI-gestützte Kodierungstools und werden das wohl auch weiterhin tun. Das übergreifende Thema des OSSRA-Berichts 2024 ist die Frage, die Entwicklern und Unternehmen gestellt wird: „Wissen Sie, was in Ihrem Code steckt?“ Angesichts der Zunahme von KI- generiertem Code ist diese Frage wohl bedeutsamer als je zuvor.
