Sicherung von Open Source im Jahr 2025 und darüber hinaus: Ein Fahrplan für den Fortschritt

Es ist über drei Jahre her, dass Log4Shell, eine kritische Schwachstelle in einer wenig bekannten Open-Source-Bibliothek, entdeckt wurde. Mit einem CVSS-Score von 10, seiner relativen Allgegenwärtigkeit und der einfachen Ausnutzung wurde es als einer der schwerwiegendsten Softwarefehler des Jahrzehnts eingestuft. Aber selbst Jahre nach dem Patch handelt es sich bei mehr als einem von zehn Downloads des beliebten Dienstprogramms um anfällige Versionen. Irgendetwas stimmt eindeutig nicht.

Ein neuer Bericht aus dem Linux Foundation bietet einige nützliche Einblicke in die systemischen Herausforderungen, denen sich das Open-Source-Ökosystem und seine Benutzer gegenübersehen. Leider gibt es keine einfachen Lösungen, aber Endbenutzer können zumindest einige der häufigeren Risiken durch branchenübliche Best Practices abmildern.

Eine katastrophale Fallstudie

Open-Source-Softwarekomponenten gibt es überall – selbst Entwickler von proprietärem Code verlassen sich auf sie, um DevOps-Prozesse zu beschleunigen. Laut eine Schätzung, 96% aller Codebasen enthalten Open-Source-Komponenten, und drei Viertel davon enthalten hochriskante Open-Source-Schwachstellen. Angesichts der bevorstehenden sieben Billionen Komponenten wurden im Jahr 2024 heruntergeladen, dies stellt ein enormes potenzielles Risiko für Systeme auf der ganzen Welt dar.

Log4j ist eine hervorragende Fallstudie dessen, was schiefgehen kann. Es zeigt eine große Herausforderung in Bezug auf die Sichtbarkeit auf, da Software nicht nur „direkte Abhängigkeiten“ enthält – also Open-Source-Komponenten, auf die ein Programm explizit verweist –, sondern auch transitive Abhängigkeiten. Letztere werden nicht direkt in ein Projekt importiert, sondern indirekt von einer Softwarekomponente verwendet. Tatsächlich sind sie Abhängigkeiten von direkten Abhängigkeiten. Google erklärte Dies war damals der Grund, warum so viele Log4j-Instanzen nicht entdeckt wurden.

„Je tiefer die Schwachstelle in einer Abhängigkeitskette liegt, desto mehr Schritte sind erforderlich, um sie zu beheben“, heißt es.

Brian Fox, CTO von Sonatype, erklärt, dass „schlechtes Abhängigkeitsmanagement“ in Unternehmen eine Hauptquelle für Cybersicherheitsrisiken bei Open-Source-Software sei.

„Log4j ist ein gutes Beispiel. Wir haben festgestellt, dass 13 % der Log4j-Downloads anfällige Versionen sind, und das drei Jahre, nachdem Log4Shell gepatcht wurde“, sagt er gegenüber ISMS.online. „Das ist auch kein Problem, das nur bei Log4j auftritt – wir haben berechnet, dass im letzten Jahr für 95 % der heruntergeladenen anfälligen Komponenten bereits eine korrigierte Version verfügbar war.“

Bei Open-Source-Risiken geht es jedoch nicht nur um potenzielle Schwachstellen in schwer zu findenden Komponenten. Bedrohungsakteure platzieren auch aktiv Malware in einigen Open-Source-Komponenten in der Hoffnung, dass diese heruntergeladen werden. Sonatype entdeckte im Jahr 512,847 2024 bösartige Pakete in den wichtigsten Open-Source-Ökosystemen, eine jährliche Steigerung von 156 %.

Systemische Herausforderungen

Log4j war in vielerlei Hinsicht nur die Spitze des Eisbergs, wie ein neuer Linux-Bericht zeigt. Er verweist auf mehrere bedeutende branchenweite Herausforderungen bei Open-Source-Projekten:

Veraltete Technologie: Viele Entwickler verlassen sich weiterhin auf Python 2, obwohl Python 3 bereits 2008 eingeführt wurde. Dies führt zu Abwärtskompatibilitätsproblemen und Software, für die keine Patches mehr verfügbar sind. Ältere Versionen von Softwarepaketen bleiben auch in Ökosystemen bestehen, da ihre Nachfolger oft neue Funktionen enthalten, was sie für Benutzer weniger attraktiv macht.

Fehlen eines standardisierten Benennungsschemas: Namenskonventionen für Softwarekomponenten seien „einzigartig, individuell und inkonsistent“, was Initiativen zur Verbesserung von Sicherheit und Transparenz einschränkt.

Ein begrenzter Pool an Mitwirkenden:

„Einige weit verbreitete OSS-Projekte werden von einer einzigen Person betreut. Bei der Überprüfung der 50 wichtigsten Nicht-NPM-Projekte hatten 17 % der Projekte einen Entwickler und 40 % hatten einen oder zwei Entwickler, die für mindestens 80 % der Commits verantwortlich waren“, sagt David Wheeler, Direktor für Open Source Supply Chain Security bei OpenSSF, gegenüber ISMS.online.

„Bei einem Projekt mit nur einem Entwickler besteht ein höheres Risiko, dass es später aufgegeben wird. Darüber hinaus besteht ein höheres Risiko, dass es vernachlässigt wird oder bösartiger Code eingefügt wird, da möglicherweise regelmäßige Updates oder Peer-Reviews fehlen.“

Cloudspezifische Bibliotheken: Dies könnte zu Abhängigkeiten von Cloud-Anbietern, möglichen Sicherheitslücken und einer Abhängigkeit von einem bestimmten Anbieter führen.

„Die wichtigste Erkenntnis ist, dass Open Source für die Software, die die Cloud-Infrastruktur antreibt, immer wichtiger wird“, sagt Fox von Sonatype. „Die Nutzung von Open Source hat ein rasantes Wachstum erlebt, und dieser Trend wird sich fortsetzen. Gleichzeitig haben wir keine finanzielle oder sonstige Unterstützung für Open-Source-Betreuer gesehen, die dieser Nutzung gerecht wird.“

Speicherunsichere Sprachen: Die speichersichere Sprache Rust wird zunehmend verwendet, viele Entwickler bevorzugen jedoch immer noch C und C++, die häufig Schwachstellen in der Speichersicherheit aufweisen.

Wie ISO 27001 helfen kann

As Red Hat-Mitarbeiter Herve Beraud bemerkt, hätten wir Log4Shell kommen sehen müssen, da das Dienstprogramm selbst (Log4j) keinen regelmäßigen Sicherheitsüberprüfungen unterzogen wurde und nur von einem kleinen Team von Freiwilligen gewartet wurde, ein Risiko, das oben hervorgehoben wurde. Er argumentiert, dass Entwickler sorgfältiger über die von ihnen verwendeten Open-Source-Komponenten nachdenken müssen, indem sie Fragen zu RoI, Wartungskosten, Rechtskonformität, Kompatibilität, Anpassungsfähigkeit und natürlich dazu stellen, ob sie regelmäßig auf Schwachstellen getestet werden.

Experten empfehlen außerdem Tools zur Software Composition Analysis (SCA), um die Transparenz von Open-Source-Komponenten zu verbessern. Diese helfen Unternehmen dabei, ein Programm zur kontinuierlichen Evaluierung und Patches aufrechtzuerhalten. Besser noch: Erwägen Sie einen ganzheitlicheren Ansatz, der auch das Risikomanagement für proprietäre Software abdeckt. Der ISO 27001-Standard bietet einen strukturierten Rahmen, der Unternehmen dabei hilft, ihre Open-Source-Sicherheitslage zu verbessern.

Hierzu gehört die Hilfe bei:

• Risikobewertungen und -minderungen für Open-Source-Software, einschließlich Schwachstellen oder fehlender Unterstützung
• Pflege eines Inventars von Open-Source-Software, um sicherzustellen, dass alle Komponenten aktuell und sicher sind
• Zugriffskontrollen, sodass nur autorisierte Teammitglieder Open-Source-Software verwenden oder ändern können
• Sicherheitsrichtlinien und -verfahren zur Verwendung, Überwachung und Aktualisierung von Komponenten
• Lieferantenbeziehungsmanagement, um sicherzustellen, dass Anbieter von Open-Source-Software die Sicherheitsstandards und -praktiken einhalten
• Kontinuierliches Patchmanagement zur Behebung von Sicherheitslücken in Open-Source-Software
• Incident-Management-Prozesse, einschließlich der Erkennung und Reaktion auf Schwachstellen oder Verstöße, die sich aus Open-Source-
• Förderung einer Kultur der kontinuierlichen Verbesserung, um die Wirksamkeit von Sicherheitskontrollen zu steigern
• Schulung und Sensibilisierung der Mitarbeiter für die mit Open-Source-Software verbundenen Risiken

Es gibt noch viel mehr, was getan werden kann, darunter staatliche Bug-Bounty-Programme, Bildungsbemühungen und Gemeinschaftsfinanzierung durch Technologiegiganten und andere große Unternehmensnutzer von Open Source. Dieses Problem wird nicht über Nacht gelöst werden, aber zumindest hat sich etwas getan.