Im Jahr 2022 schlug die Open-Source-Sicherheit zurück

Von Matt Asay

Mitwirkender, InfoWorld |

Anfang Dezember jährte sich der Sicherheitszusammenbruch bei Log4j zum ersten Mal. Seitdem ist die Softwarewelt auf Hochtouren, um sicherzustellen, dass so etwas nie wieder passiert. Endlich sehen wir eine gewisse Dynamik, da die Lücken in der Software-Lieferkettensicherheit geschlossen werden.

Log4j war ein lähmendes Ereignis für viele Unternehmen, die Schwierigkeiten hatten zu verstehen, ob und wo sie das beliebte Open-Source-Protokollierungsdienstprogramm überhaupt in ihren Umgebungen ausführen. Aber Log4j zwang die Branche auch dazu, sich mit der transitiven Natur von Software-Supply-Chain-Exploits auseinanderzusetzen und mit der Leichtigkeit, mit der Exploits Softwareabhängigkeiten überwinden können. Für die Sicherheitsteams war es kein schöner Abschluss des Jahres 2021.

Auch die Sicherheitsanbieter haben sich nicht mit Ruhm bekleckert. Anfangs sahen wir eine Schar opportunistischer Vermarkter von Sicherheitssoftware, die sich beeilten, ihre Produkte als direkte Lösungen zu positionieren. Aber laut Dan Lorenc, CEO und Gründer des Software-Supply-Chain-Security-Startups Chainguard: „Die meisten Scanner nutzen Paketdatenbanken, um zu sehen, welche Pakete in Containern installiert sind.“ Außerhalb dieser Systeme installierte Software ist nicht ohne weiteres identifizierbar und daher für Scanner unsichtbar.“

Mit anderen Worten: Sicherheitsanbieter verkauften Gedanken und Gebete, keine echten Lösungen.

Nicht alle reagierten so ausdruckslos. Diese Herausforderung für die Sicherheit der Software-Lieferkette hängt ganz speziell mit Open Source zusammen. Die Realität ist, dass moderne Anwendungen größtenteils mit Open-Source-Frameworks erstellt werden, deren Sicherheitsherkunft eher unbekannt ist. Es kann einfach keine Unternehmenslösung geben, die alle Open-Source-Anwendungen absichert – in diese Richtung funktioniert sie nicht. Die Antwort, so scheint es, muss von der Open-Source-Community selbst kommen. Im Jahr 2022 war es soweit.

Es gab eine unglaubliche Menge an Aktivitäten rund um die Sicherheit der Software-Lieferkette und unzählige Beispiele dafür, wie die Open-Source-Community im Jahr 2022 ihre Kreise zieht.

Einiges davon ist willkommen, aber weitgehend hohle öffentliche Signale von Beamten, wie die Durchführungsverordnung des Weißen Hauses zur Sicherung der Software-Lieferkette und der Securing Open Source Software Act von 2022 des US-Senats. Das ist schön, aber bei der Softwaresicherheit geht es nicht um öffentliche Proklamationen . Glücklicherweise wurde im vergangenen Jahr wirklich viel Arbeit geleistet, um Entwickler mit den Werkzeugketten auszustatten, mit denen sie die Sicherheit der Lieferkette weiter hinten im Softwareentwicklungslebenszyklus angehen können.

Es überrascht nicht, dass die Linux Foundation und die Cloud Native Computing Foundation maßgeblich daran beteiligt waren, dies in wichtigen Open-Source-Projekten zu ermöglichen. Beispielsweise hat das SPDX SBOM-Format Eingang in große Plattformen wie Kubernetes gefunden. Die Open Source Security Foundation hat mehr als 100 Mitglieder und viele Millionen Dollar an Fördermitteln für weitere Standards und Tools. Speichersichere Sprachen wie Rust werden vom Linux-Kernel unterstützt, um eine ganze Klasse von Schwachstellen im Zusammenhang mit Softwareartefakten abzuwehren.

Die vielleicht bemerkenswerteste einzelne Technologie, die im vergangenen Jahr einen Durchbruch erlebte, ist Sigstore, das Code-Signatur-Tool, das bei Google und Red Hat geboren wurde und de facto zum „Wachssiegel“ geworden ist, das jetzt in Open-Source-Software-Registern eingebettet ist Werkzeugketten. Kubernetes, npm und PyPi gehören zu den Plattformen und Registern, die Sigstore als Signaturstandards übernommen haben. Wichtig ist, dass alle diese Sigstore-Signaturen in ein öffentliches Transparenzprotokoll aufgenommen werden. Dies ist ein wichtiger neuer Impuls für das Sicherheitsökosystem, um die Verbindung zwischen Softwaresignierung, Software-Stücklisten (SBOMs) und der gesamten Toolchain für die Sicherheitsherkunft der Softwarelieferkette herzustellen .

Jeder, der sich in den letzten 20 Jahren – oder sogar in den letzten beiden – mit Open Source beschäftigt hat, wird nicht überrascht sein, dass kommerzielle Interessen rund um diese beliebten Open-Source-Technologien zu florieren beginnen. Wie es zum Standard geworden ist, wird kommerzieller Erfolg meist mit „Cloud“ geschrieben. Hier ist ein prominentes Beispiel: Am 8. Dezember 2022 veröffentlichte Chainguard, das Unternehmen, dessen Gründer während ihrer Zeit bei Google Sigstore mitentwickelt haben, Chainguard Enforce Signing, das es Kunden ermöglicht, Sigstore-as-a-Service zu nutzen, um digitale Signaturen für Software-Artefakte in ihren eigenen zu generieren Organisation mithilfe ihrer individuellen Identitäten und Einmalschlüssel.

Diese neue Funktion hilft Unternehmen dabei, die Integrität von Container-Images, Code-Commits und anderen Artefakten mit privaten Signaturen sicherzustellen, die jederzeit validiert werden können, wenn ein Artefakt verifiziert werden muss. Es erlaubt auch eine Trennlinie, bei der Open-Source-Softwareartefakte offen in einem öffentlichen Transparenzprotokoll signiert werden; Unternehmen können jedoch ihre eigene Software mit demselben Ablauf signieren, jedoch mit privaten Versionen, die nicht im öffentlichen Protokoll enthalten sind. Der Weg von Chainguard ähnelt dem von GitHub: Entwickler können unbegrenzt öffentliche Repositories erstellen, müssen aber für private Team-Repositories bezahlen.

Man kann nur vermuten, über welche wichtigen Entwicklungen in der Software-Lieferkettensicherheit wir nächstes Jahr um diese Zeit sprechen werden, aber es gibt viele Gründe zu der Annahme, dass dies einer der sich am schnellsten entwickelnden und aufregendsten Bereiche der Sicherheit bleiben wird (und dass Sicherheit auch weiterhin bestehen wird). einer der wichtigsten Bereiche in der Software). Es wurde viel getan, um die Softwaresicherheit zu verbessern; es bleibt noch viel mehr übrig.

Dan Lorenc, CEO von Chainguard und Mitschöpfer von Sigstore, gibt als erster zu, wie weit noch zu gehen ist, insbesondere im Bereich SBOMs, wo es für Entwickler viel Leerraum zwischen Theorie und Realität gibt. Wenn Entwickler keine einfachen Methoden haben, um Sicherheit in Softwareartefakte zu Beginn des Softwareentwicklungslebenszyklus zu integrieren, führt er scherzhaft dazu, dass das Ergebnis „Schätzstücklisten“ sind.

Lorenc weist auf die durch Sigstore ermöglichte Software-Signatur und die allgemeine Zunahme großer Projekte hin, die von Open-Source-Organisationen (Industrie und Regierung gleichermaßen) gefördert werden. Er sieht darin einen Beweis dafür, dass ein Großteil der Macht zur Lösung dieser Sicherheitsherausforderung in der Software-Lieferkette dort liegt, wo sie hingehört: in den Händen von Entwicklern mit den richtigen Tools.

Lesen Sie als nächstes Folgendes:

Matt Asay leitet die Entwicklerbeziehungen bei MongoDB. Die hier geäußerten Ansichten stammen von Matt und spiegeln nicht die seines Arbeitgebers wider.

Urheberrecht © 2022 IDG Communications, Inc.