Die kürzliche Entdeckung einer Hintertür im Datenkomprimierungsdienstprogramm XZ Utils – das in fast allen großen Linux-Distributionen vorhanden ist – ist eine deutliche Erinnerung daran, dass Unternehmen, die Open-Source-Komponenten verwenden, letztendlich die Verantwortung für die Sicherheit der Software tragen.

XZ Utils wird wie Tausende andere Open-Source-Projekte von Freiwilligen betrieben und in diesem Fall von einem einzigen Betreuer verwaltet. Solche Projekte verfügen oft nur über geringe oder gar keine Ressourcen für die Bewältigung von Sicherheitsproblemen, was bedeutet, dass Unternehmen die Software auf eigenes Risiko nutzen. Das bedeutet, dass Sicherheits- und Entwicklungsteams Maßnahmen zum Management von Open-Source-Risiken genauso umsetzen müssen, wie sie es mit intern entwickeltem Code tun, sagen Sicherheitsexperten.

„Obwohl es unwahrscheinlich ist, dass ein Unternehmen [alle] Risiken in der Lieferkette wirksam verhindern kann, können sich Unternehmen durchaus auf eine Strategie konzentrieren, um die Wahrscheinlichkeit zu verringern, dass ein Angriff auf die Lieferkette erfolgreich ist“, sagt Jamie Scott, Gründungsproduktmanager bei Endor Labs.

Open Source ist nicht dasselbe wie Outsourcing: „Open-Source-Betreuer von Software sind Freiwillige.“ Auf Branchenebene müssen wir sie als solche behandeln. Wir besitzen unsere Software; Wir sind für die Software verantwortlich, die wir wiederverwenden.“

Gut gemeint, mit unzureichenden Ressourcen ausgestattet

Bedenken hinsichtlich der Sicherheit von Open-Source-Software sind keineswegs neu. Aber es braucht oft Entdeckungen wie die Log4Shell-Sicherheitslücke und für Hintertür in XZ Utils um wirklich deutlich zu machen, wie anfällig Unternehmen für Komponenten in ihrem Code sind. Und oft stammt der Code aus gut gemeinten, aber hoffnungslos unterfinanzierten Open-Source-Projekten, die nur minimal gepflegt werden.

XZ Utils zum Beispiel ist im Wesentlichen ein Ein-Personen-Projekt. Einer anderen Person ist es gelungen schleichen Sie die Hintertür in das Dienstprogramm ein über einen Zeitraum von fast drei Jahren hinweg, indem nach und nach genügend Vertrauen beim Projektbetreuer gewonnen wurde. Wenn nicht Ende März ein Microsoft-Entwickler bei der Untersuchung seltsamer Verhaltensweisen im Zusammenhang mit einer Debian-Installation darauf gestoßen wäre, wäre die Hintertür möglicherweise auf Millionen von Geräten weltweit gelandet – darunter auch auf Geräten großer Unternehmen und Regierungsbehörden. Wie sich herausstellte, hatte die Hintertür nur minimale Auswirkungen, da sie Versionen von XZ Utils betraf, die nur in Unstable- und Beta-Versionen von Debian, Fedora, Kali, Open SUSE und Arch Linux vorhanden waren.

Der nächste derartige Open-Source-Code-Kompromiss könnte weitaus schlimmer sein. „Das Beängstigendste für Unternehmen ist, dass ihre Anwendungen auf Open-Source-Softwareprojekten wie XZ Utils basieren“, sagt Donald Fischer, Mitbegründer und CEO von Tidelift. „XZ Utils ist ein Paket von Zehntausenden, die täglich von typischen Unternehmensorganisationen verwendet werden“, sagt er.

Den meisten dieser Unternehmen mangele es an ausreichendem Einblick in die Sicherheit und Belastbarkeit dieses Teils ihrer Software-Lieferkette, um Risiken bewerten zu können, stellt er fest.

Eine kürzlich Harvard Business School Die Studie schätzte den nachfrageseitigen Wert von Open-Source-Software auf erstaunliche 8.8 Billionen US-Dollar. Betreuer sind der Kern dieses Ökosystems und viele von ihnen fliegen alleine, sagt Fischer. Eine letztes Jahr von Tidelift durchgeführte Umfrage ergab, dass 44 % der Open-Source-Projektbetreuer sich selbst als alleinige Betreuer ihrer Projekte bezeichnen. Sechzig Prozent identifizierten sich als unbezahlte Hobbyisten, und der gleiche Prozentsatz gab an, dass sie ihre Rolle als Projektbetreuer entweder aufgegeben haben oder darüber nachgedacht haben, sie aufzugeben. Viele Betreuer beschrieben ihre Bemühungen als stressige, einsame und finanziell wenig lohnende Arbeit, sagt Fischer.

„Der XZ-Utils-Hack verdeutlicht deutlich die Risiken unzureichender Investitionen in die Gesundheit und Widerstandsfähigkeit der Open-Source-Software-Lieferkette, auf die sich Unternehmen verlassen“, sagt Fischer. „Unternehmen müssen sich darüber im Klaren sein, dass die meisten der am häufigsten verwendeten Open-Source-Pakete von Freiwilligen gepflegt werden, die sich selbst als unbezahlte Bastler bezeichnen. Diese Betreuer sind keine Unternehmenslieferanten, aber von ihnen wird erwartet, dass sie wie diese arbeiten und liefern.“

Gefahr: Transitive Abhängigkeiten

A Studie, die Endor durchgeführt hat Im Jahr 2022 wurde festgestellt, dass 95 % der Open-Source-Schwachstellen in sogenannten transitiven Abhängigkeiten oder sekundären Open-Source-Paketen oder -Bibliotheken vorliegen, von denen ein primäres Open-Source-Paket abhängen könnte. Häufig handelt es sich dabei um Pakete, die Entwickler nicht direkt selbst auswählen, sondern automatisch von einem Open-Source-Paket in ihrem Entwicklungsprojekt verwendet werden.

„Wenn Sie beispielsweise einem Maven-Paket vertrauen, gibt es im Durchschnitt weitere 14 Abhängigkeiten, denen Sie implizit vertrauen“, sagt Scott. „Diese Zahl ist in bestimmten Software-Ökosystemen wie NPM sogar noch größer, wo man im Durchschnitt 77 andere Softwarekomponenten für jede Komponente importiert, der man vertraut.“

Eine Möglichkeit, mit der Minderung von Open-Source-Risiken zu beginnen, bestehe darin, auf diese Abhängigkeiten zu achten und bei der Auswahl der Projekte selektiv vorzugehen, sagt er.

Unternehmen sollten Abhängigkeiten überprüfen, insbesondere die kleineren, einmaligen Pakete, die von Ein- oder Zwei-Personen-Teams betreut werden, fügt hinzu Dimitri Stiliadis, CTO und Mitbegründer von Endor. Sie sollten feststellen, ob Abhängigkeiten in ihrer Umgebung über angemessene Sicherheitskontrollen verfügen oder ob eine einzelne Person den gesamten Code festschreibt. ob sie Binärdateien in ihren Repositorys haben, von denen niemand weiß; oder ob überhaupt jemand das Projekt aktiv pflegt, sagt Stiliadis.

„Konzentrieren Sie Ihre Bemühungen auf die Verbesserung Ihrer Reaktionseffektivität – grundlegende Kontrollen wie die Pflege eines ausgereiften Softwareinventars bleiben eines der wertvollsten Programme, die Sie haben können, um Softwarerisiken schnell zu identifizieren, einzuschätzen und darauf zu reagieren, sobald sie identifiziert sind“, Scott berät.

Tools zur Analyse der Softwarezusammensetzung, Schwachstellenscanner, EDR/XDR-Systeme und SBOMs können Unternehmen außerdem dabei helfen, anfällige und kompromittierte Open-Source-Komponenten schnell zu identifizieren.

Die Bedrohung anerkennen

„Die Eindämmung der Gefährdung beginnt mit dem gemeinsamen Verständnis und der Anerkennung in der C-Suite und sogar auf Vorstandsebene, dass etwa 70 % der Bestandteile eines durchschnittlichen Softwareprodukts Open-Source-Software sind, die in der Vergangenheit von meist unbezahlten Mitwirkenden erstellt wurde“, sagt Fischer von Tidelift.  

Neue Vorschriften und Richtlinien in der Finanzdienstleistungsbranche, der FDA und NIST werden die Art und Weise beeinflussen, wie Software in den kommenden Jahren entwickelt wird, und Unternehmen müssen sich jetzt darauf vorbereiten. „Die Gewinner hier werden schnell von einer reaktiven Strategie zu einer proaktiven Strategie für das Management von Open-Source-bezogenen Risiken wechseln“, sagt er.

Fischer empfiehlt Unternehmen, ihre Sicherheits- und Technikteams damit zu beauftragen, herauszufinden, wie neue Open-Source-Komponenten in ihre Umgebung gelangen. Sie sollten auch Rollen für die Überwachung dieser Komponenten definieren und proaktiv diejenigen entfernen, die nicht zur Risikobereitschaft des Unternehmens passen. „Das Reagieren auf Probleme im Spätstadium ist in den letzten Jahren zu einer ineffektiven Methode geworden, um mit dem Ausmaß des Risikos für das Unternehmen umzugehen Die US-Regierung gibt ein Signal „Diese Ära geht zu Ende“, sagt er.

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• PlatoData.Network Vertikale generative KI. Motiviere dich selbst. Hier zugreifen.
• PlatoAiStream. Web3-Intelligenz. Wissen verstärkt. Hier zugreifen.
• PlatoESG. Kohlenstoff, CleanTech, Energie, Umwelt, Solar, Abfallwirtschaft. Hier zugreifen.
• PlatoHealth. Informationen zu Biotechnologie und klinischen Studien. Hier zugreifen.
• Quelle: https://www.darkreading.com/application-security/xz-utils-scare-exposes-hard-truths-in-software-security