Open-Source-Sicherheit im Jahr 2022

Die Schwachstelle in der Java-Bibliothek Log4j (Log4Shell) war ein lähmendes Ereignis für viele Unternehmen, die nicht wussten, ob und wo sie das beliebte Open-Source-Protokollierungsprogramm überhaupt in ihren Umgebungen einsetzten. Die Lücke zwang die Branche dazu, sich mit der transitiven Natur von Software-Lieferketten-Exploits auseinanderzusetzen. Sie mussten - wenn auch recht schmerzhaft - erkennen, wie einfach es für Exploits ist, über Software-Abhängigkeiten hinweg zu springen. Für die Sicherheitsteams war das Jahr 2021 kein schöner Abschluss.

Auch die Anbieter von Sicherheitslösungen haben sich nicht mit Ruhm bekleckert. Zunächst sahen wir eine Reihe von opportunistischen Vermarktern von Sicherheitssoftware, die ihre Produkte als direkte Lösungen präsentierten. Doch wie Dan Lorenc, CEO und Gründer des Software-Supply-Chain-Security-Startups Chainguard, erklärt, war dem häufig nicht so: "Die meisten Scanner verwenden Paketdatenbanken, um zu sehen, welche Pakete in Containern installiert sind. Software, die außerhalb dieser Systeme installiert ist, lässt sich nicht ohne Weiteres identifizieren und ist somit für Scanner unsichtbar." Mit anderen Worten: Die Sicherheitsanbieter verkauften Produkte, aber keine echten Lösungen.

Nicht alle waren so unbedarft in ihrer Antwort. Diese Herausforderung für die Sicherheit der Software-Lieferkette hat ganz konkret mit Open Source (OS) zu tun. Die Realität ist, dass moderne Anwendungen größtenteils mit Open-Source-Frameworks erstellt werden, deren sicherheitstechnischer Hintergrund nicht ganz klar ist. Eine Unternehmenslösung, die alle Open-Source-Anwendungen schützt, ist nicht möglich - sie funktioniert nicht in dieser Richtung. Die Antwort, so scheint es, muss von der Open-Source-Community selbst kommen. Im Jahr 2022 war das der Fall.

Lesetipp: Log4j – ist Open Source das Problem?

Eine massive Reaktion der OS-Community

Log4j führte zu einer unglaublichen Menge an Aktivitäten rund um die Sicherheit der Software-Lieferkette. Einiges davon sind willkommene, aber größtenteils hohle öffentliche Signale von offizieller Seite, wie die Durchführungsverordnung des Weißen Hauses zur Sicherung der Software-Lieferkette und der Securing Open Source Software Act of 2022 des US-Senats. Das ist zwar nett, aber bei der Softwaresicherheit geht es nicht um öffentliche Proklamationen.

Doch glücklicherweise hat sich im vergangenen Jahr eine Menge getan, um Entwickler mit entsprechenden Tools auszustatten. Damit sind sie in der Lage, die Sicherheit der Lieferkette auch noch weiter hinten im Lebenszyklus der Softwareentwicklung zu gewährleisten.

Es überrascht nicht, dass die Linux Foundation und die Cloud Native Computing Foundation in wichtigen Open-Source-Projekten stark daran beteiligt waren, dies zu erreichen. So hat beispielsweise das SPDX-SBOM-Format seinen Weg in wichtige Plattformen wie Kubernetes gefunden. Die Open Source Security Foundation hat mehr als 100 Mitglieder und finanziert mit vielen Millionen Dollar weitere Standards und Tools. Speichersichere Sprachen wie Rust werden vom Linux-Kernel unterstützt, um eine ganze Klasse von Schwachstellen im Zusammenhang mit Software-Artefakten abzuwehren.

Die wohl bemerkenswerteste Technologie, die im vergangenen Jahr einen Aufschwung erlebt hat, ist Sigstore. Dabei handelt es sich um ein Tool zur Codesignierung, das bei Google und Red Hat entstanden ist. Die Signierung ist nun in Open-Source-Software-Registrierungen und Toolchains integriert. Kubernetes, npm und PyPi gehören zu den Plattformen und Registries, die Sigstore als Signierstandard übernommen haben. Wichtig ist, dass all diese Sigstore-Signaturen in ein öffentliches Transparenzprotokoll einfließen. Dies ist ein wichtiges neues Herzstück für das Sicherheitsökosystem, um die Punkte zwischen Software-Signierung, Software-Stücklisten (SBOMs) und der gesamten Toolchain für die Sicherheit der Software-Lieferkette zu verbinden.