Cybersicherheitsherausforderungen bei Open-Source-Software mit der Linux Foundation angehen

Snyk hat sich kürzlich mit der Linux Foundation zusammengetan, um einen Bericht zum Stand der Sicherheit im Bereich Open-Source-Software (OSS) zu erstellen. Grundlage des Berichts waren über 550 Umfrageantworten und 15 Interviews mit OSS-Maintainer:innen und Cybersicherheitsexpert:innen.

Nach der Veröffentlichung des Berichts veranstalteten Expert:innen von Snyk gemeinsam mit der Linux Foundation ein Webinar, um einige der zentralen Erkenntnisse zu diskutieren: Cybersicherheitsherausforderungen bei Open-Source-Software angehen: Expert:innenrunde. Zu den Teilnehmenden des Webinars gehörten: Mic McCully (Field Strategist, Snyk), Matt Jarvis (Director of Developer Relations, Snyk) und Steve Hendrick (VP of Research, Linux Foundation).

Lesen Sie weiter und erfahren Sie, wie sich die Sicherheit und Nachhaltigkeit von Open-Source-Software verbessern lassen.

Schwachstellen in der Software-Supply-Chain

Da Software-Supply-Chains immer komplexer werden, gewinnt die Sicherheit von Open-Source-Software zunehmend an Bedeutung. Die meiste Software umfasst heute beispielsweise zahlreiche indirekte oder transitive Abhängigkeiten, die sich aus Sicht der Anwendungssicherheit nur schwer visualisieren und bewerten lassen.

Wenn Entwickler ein Open-Source-Paket einbinden, verweist dieses Paket sehr häufig auf weitere Open-Source-Projekte. So entsteht eine Hierarchie, in der die Pakete auf den unteren Ebenen oft als indirekte oder transitive Abhängigkeiten bezeichnet werden.

Dem aktuellen Bericht zufolge weist ein durchschnittliches OSS-Projekt 49 Schwachstellen auf, die sich über 79 direkte Abhängigkeiten erstrecken. Die Zahlen variieren jedoch je nach Ökosystem: In JavaScript-Projekten gibt es deutlich mehr Schwachstellen als in Python-, Go-, Java- und .NET-Projekten.

Noch aufschlussreicher ist, wo sich diese Schwachstellen in den Paketen befinden. Der Bericht zeigt, dass über 40 % dieser Sicherheitsprobleme in indirekten Abhängigkeiten auftreten. Entwicklungsteams ist daher häufig nicht bewusst, dass sie anfälligen Code in ihre Projekte einbinden.

Wie wir bei Snyk gesehen haben, können diese Schwachstellen tief verschachtelt sein. Manche Probleme in der Software-Supply-Chain gehen oft auf Abhängigkeiten zurück, die vier oder fünf Ebenen tief liegen.

Der Bedarf an SBOMs und OSS-Sicherheitsrichtlinien

Da Sicherheitsprobleme oft tief in komplexen Abhängigkeitsstrukturen verborgen sind, gewinnt die Idee,

eine Software-Stückliste (Software Bill of Materials, SBOM) zu erstellen, zunehmend an Bedeutung. SBOMs sind formelle Verzeichnisse der Komponenten einer Software und ihrer Supply-Chain-Beziehungen, die für mehr Transparenz sorgen sollen.

Tatsächlich müssen wir wissen, was in einer Komponente steckt. Wir müssen verstehen, wie gut sie sich einsetzen lässt und ob wir ihr vertrauen können. Bei transitiven Abhängigkeiten kann es sehr schwierig sein, diese Informationen zu erhalten.

Ein Grund, warum viele Unternehmen keine SBOMs erstellen, ist der insgesamt geringe Stellenwert der Open-Source-Sicherheit. Tatsächlich ergab die Umfrage für den Bericht, dass nur 49 % der Unternehmen über eine Sicherheitsrichtlinie verfügen, die Open-Source-Sicherheit berücksichtigt.

Ohne eine OSS-Richtlinie können Sie Risiken nicht wirksam managen. Sie wissen nicht genau, was bei Schwachstellen zu tun ist, und Ihre Sicherheitslage leidet darunter.

Wie überprüfen Unternehmen die Sicherheit von OSS-Paketen?

Der Bericht ergab, dass 44 % der Unternehmen ihre Entwickler:innen den Quellcode auf Schwachstellen untersuchen lassen. Dafür kommen jedoch fast ein Dutzend verschiedene Tooltypen zum Einsatz. Zu den beliebtesten zählen Static Application Security Testing (SAST) und Software Composition Analysis (SCA).

Eine weitere gängige Methode, mit der Unternehmen die Sicherheit von OSS-Paketen überprüfen, ist deren sorgfältige Bewertung vor der Einführung. Sie achten auf OSS-Projekte mit guten Bewertungen, einer aktiven Community, die regelmäßig neue Codeänderungen veröffentlicht, und einer öffentlich zugänglichen Sicherheitsrichtlinie. Dennoch können diese Komponenten Schwachstellen in ihren transitiven Abhängigkeiten aufweisen, wenn die Maintainer des Projekts die OSS-Sicherheit nicht proaktiv gewährleisten.

Was wir branchenweit zunehmend beobachten, sind neue Wege, Open-Source-Nutzern Informationen zu Sicherheit und Vertrauenswürdigkeit bereitzustellen. Angefangen haben wir mit GitHub Stars, inzwischen gibt es jedoch OpenSSF Scorecards und andere Quellen mit detaillierten Informationen.

Die Auswirkungen von Log4Shell in der Java-Community

Der Bericht brachte auch interessante Erkenntnisse zur weit verbreiteten Log4Shell-Schwachstelle in der Java-Community zutage. Besonders bemerkenswert: 79 % der von Log4Shell betroffenen Projekte weisen mehr als eine Log4Shell-Schwachstelle in ihrer Codebasis auf, und 60 % der Fälle wurden in indirekten Abhängigkeiten gefunden.

Log4Shell hat eindrücklich gezeigt, dass Open-Source-Projekte zum Opfer ihres eigenen Erfolgs werden können. Wenn eine Open-Source-Bibliothek wie Log4j in einer so großen Bandbreite von Projekten eingesetzt wird, können Sicherheitsprobleme enorme Auswirkungen haben. Dadurch rückte der Bedarf an SCA-Scannern stark in den Fokus.

Schwachstellen in Open-Source-Software lassen sich immer schwerer beheben

Software-Supply-Chains werden immer komplexer, und für viele Unternehmen wird es zunehmend schwieriger, den Überblick über die Sicherheit zu behalten. Dadurch lassen sich auch Schwachstellen in Open-Source-Software immer schwerer beheben. Tatsächlich ist die Zeit bis zur Behebung von Schwachstellen von 49 Tagen im Jahr 2018 auf 110 Tage im Jahr 2021 gestiegen.

Innerhalb von drei Jahren hat sich die Zeit bis zur Behebung mehr als verdoppelt. Gleichzeitig sind zwei weitere Entwicklungen zu beobachten: 1) Die Nutzung und Entwicklung von Software hat rasant zugenommen. 2) Wir investieren deutlich mehr Zeit und Aufmerksamkeit in die Sicherheit.

Eine weitere Herausforderung angesichts längerer Behebungszeiten ist der Ressourcenmangel. Einige Unternehmen beheben kritische Probleme tatsächlich schneller als zuvor, doch Schwachstellen mit niedriger Priorität werden aufgrund knapper Ressourcen für Anwendungssicherheit zu langsam angegangen. Deshalb nennen Unternehmen SAST- und SCA-Tools als die beiden wichtigsten Methoden, um Sicherheitsprobleme zu beheben.

SAST- und SCA-Scanning-Tools lassen sich in CI/CD-Pipelines und den Entwicklungsprozess integrieren, um die Erkennung und Behebung vieler Schwachstellen in Open-Source-Software zu automatisieren. So können Unternehmen einige der Herausforderungen bewältigen, die ihnen der Mangel an Ressourcen für Anwendungssicherheit bereitet.

Es besteht ein sehr starker Zusammenhang zwischen der Automatisierung der Deployment-Pipeline und der Zeit, die zur Behebung von Sicherheitsproblemen benötigt wird. Denn bei einer vollständig automatisierten CI/CD-Pipeline gibt es viele Ansatzpunkte, um Sicherheitsprüfungen zu integrieren.

Der Stand der Open-Source-Sicherheit im Jahr 2022

In diesem Gespräch zwischen Snyk und der Linux Foundation wurden einige zentrale Erkenntnisse aus dem Bericht vorgestellt, doch es gibt noch viel mehr zu entdecken. Laden Sie den vollständigen Bericht herunter und erfahren Sie mehr über die Komplexität und Risiken der heutigen Software-Supply-Chain-Landschaft: Der Stand der Open-Source-Sicherheit 2022.