Eine neue Hoffnung für Softwaresicherheit

Von Matt Asay

Mitwirkender, InfoWorld |

Die Log4j-Schwachstelle im Dezember 2021 machte die Software-Lieferkette als einen massiv vernachlässigten Sicherheitsbereich deutlich. Es zeigte, wie eng unsere Software-Artefakte miteinander verbunden sind und dass unsere Systeme nur so sicher sind wie ihre schwächsten Glieder. Es bestärkte auch die Vorstellung, dass wir vielleicht denken, Sicherheit sei etwas, das wir kaufen können, in Wirklichkeit geht es aber darum, wie wir als Entwicklungsteams funktionieren.

Seitdem sprinten wir, um uns zu verbessern.

Am bemerkenswertesten ist vielleicht, dass das von Google als Open Source bereitgestellte Sigstore-Projekt de facto zur Signaturmethode für Softwareartefakte wurde und von allen wichtigen Sprachökosystemen übernommen wurde, darunter Java, Python, Node, Ruby und mehr. Es wurde zu einem der am schnellsten angenommenen Open-Source-Sicherheitsprojekte in der Geschichte und verlieh Entwicklern ein „Wachssiegel“ der Authentizität, um die Herkunft und Herkunft ihrer Softwarebausteine ​​zu bestimmen.

Also, sind wir schon da?

Nicht wirklich. Noch nicht. Das per Dekret des Weißen Hauses im Mai 2021 eingeführte Software-Bill-of-Materials-Konzept (SBOM) scheint weiterhin in weiter Ferne zu liegen. Dieses Konzept einer Lingua Franca für Entwickler zum Austausch von Zutatenlisten in Softwarepaketen hat mehrere neue Formate (SPDX, CycloneDX), was die Sache komplizierter macht. Schlimmer noch: Es war nicht klar, wie SBOMs tatsächlich in die Arbeitsabläufe der Entwickler passen würden und welche konkreten Vorteile ein Entwickler dadurch gewinnen würde.

Was all dies zusammenführt – und die Entwicklung einer kohärenten Strategie rund um Software-Signatur, SBOMs und Entwickler-Workflow dringlicher macht –, ist eine Regulierung, die eine strengere Verantwortung für die Integrität der Softwaresicherheit erfordern würde.

Bereits im April veröffentlichte die Cybersecurity and Infrastructure Agency (CISA) eine Bitte um Stellungnahme zu einem neu vorgeschlagenen Zertifikatsformular für die sichere Softwareentwicklung, das den CEOs von Softwareunternehmen die Pflicht auferlegt, zu bestätigen, dass ihre Software in sicheren Umgebungen erstellt wurde und dass dies der Fall ist Es wurden nach Treu und Glauben angemessene Anstrengungen unternommen, um vertrauenswürdige Lieferketten für Quellcodes aufrechtzuerhalten.

Was gilt als „angemessen“?

Bisher scheinen „angemessene“ Anstrengungen die Richtlinien zu sein, die in den Vulnerability Scanning Requirements for Containers von FedRAMP und im Secure Software Development Framework des National Institute of Standards and Technology festgelegt sind. Die weitaus differenziertere und zwischen den Zeilen lesbare Interpretation der neuen Selbstbescheinigungsanforderungen findet sich jedoch in den Klauseln, die den in die Software integrierten Code von Drittanbietern abdecken. Kurz gesagt, Softwareanbieter werden für die nicht finanzierten und nicht gepflegten populären Open Source-Quellen haftbar gemacht, die sie in ihren Lieferketten verwenden.

Warte was? Verantwortlich für den Code eines zufälligen Projektbetreuers? Anscheinend ja. Ist das „vernünftig“?

Diese schwindelerregende Vielfalt an Überlegungen für CISOs ist Gegenstand zahlreicher Twitter-Memes geworden:

Dies ist, wenn nötig, eine etwas schockierende Überprüfung der uneingeschränkten Einführung von Open Source. Ich schlage nicht vor, dass Unternehmen Open Source nicht nutzen sollten, ganz im Gegenteil. Ich möchte Sie daran erinnern, dass es kein kostenloses Mittagessen gibt, auch nicht, wenn es als kostenlose (und Open-Source-)Software verpackt ist. Jemand muss dafür zahlen, dass die Betreuer den Überblick behalten, und jemand muss den Entwicklern dabei helfen, die ganze eingehende Open-Source-Software zu verstehen.

Chainguard könnte so jemand sein.

Chainguard ist ein Unternehmen, das von ehemaligen Google-Mitarbeitern hinter dem Sigstore-Projekt geführt wird. Es wird versucht, alles in einer zusammenhängenden Toolchain für Entwickler zusammenzufassen. Die frühen Bemühungen des Startups konzentrierten sich auf Schritte, um den Build-Prozess zu sperren und Funktionen wie Signaturen, Herkunft und SBOMs nativ in Software-Lieferketten und den Software-Build-Prozess zu integrieren. Letztes Jahr stellten sie mit Wolfi die erste Community-Linux-(Un-)Distribution vor, die speziell auf Grundprinzipien der Lieferkettensicherheit basiert. Sie haben auch Chainguard Images auf den Markt gebracht, bei denen es sich um Basisimages für eigenständige Binärdateien, Anwendungen wie Nginx und Entwicklungstools wie Go- und C-Compiler handelt.

Kürzlich hat Chainguard ein weiteres großes Update seiner Enforce-Plattform eingeführt und diese Bausteine ​​zum Sperren von Build-Systemen auf eine Toolchain erweitert, die zwischen Entwicklern und Sicherheitsteams angesiedelt ist.

Entwickler, Sicherheitsexperten und sogar Prüfer müssen wissen, welche Softwarepakete bereitgestellt werden, wo und von wem sie bereitgestellt werden. SBOMs sollen bei der Beantwortung dieser und weiterer Fragen helfen, aber je komplexer eine Umgebung ist, desto schwieriger ist dies umzusetzen. Cluster führen oft Hunderte von Workloads mit Hunderten von Container-Images aus, während jedes Container-Image Hunderte, wenn nicht Tausende von Paketen enthält. Wir befinden uns noch so am Anfang der SBOMs, dass die meisten Pakete nicht mit SBOMs ausgeliefert werden; Sie müssen generiert werden.

Chainguard zielt auf beide Enden des Problems ab. Erstens hat das Unternehmen als Sigstore-Betreuer Softwaresignaturen, Bescheinigungen und Zertifikatsmanager in alle wichtigen Programmiersprachen und Register eingeführt, sodass eine einheitliche und konsistente Art und Weise gewährleistet ist, wie diese Open-Source-Projekte SBOMs erstellen. Mit der aktuellen Enforce-Version erstellt die Plattform mithilfe von Syft automatisch eine SBOM, sodass Entwickler keine zusätzlichen Schritte ausführen müssen, um umfassende Paketinformationen für jedes Image anzuzeigen.

Die größte Herausforderung für die neuen regulatorischen Anforderungen zur Selbstbescheinigung besteht darin, dass Container-Images tendenziell hinter Upstream-Updates zurückbleiben, sodass Lieferketten immer noch Images mit bekannten Schwachstellen ausführen. Außerdem verwenden die meisten CVE-Scanner (Common Vulnerabilities and Exposures) heute Paketdatenbanken, um zu sehen, welche Pakete in Containern installiert sind. Außerhalb dieser Systeme installierte Software ist für die Scanner jedoch unsichtbar.

Indem Chainguard es Entwicklern erleichtert, SBOMs für Pakete, die diese noch nicht haben, entweder aufzunehmen oder automatisch zu erstellen, stellt es einen Datenkorpus mit viel höherer Genauigkeit für die Schwachstellenerkennung bereit. Darüber hinaus kann das neue Schwachstellenscanning von Enforce Teams darüber informieren, ob und wo genau sie ein Artefakt mit einem CVE ausführen.

Das alles kommt gerade noch rechtzeitig. Kein Entwickler möchte der Erste sein, der herausfinden muss, wie man SBOMs verwendet. Dennoch haben sie keine Wahl: Die Kombination aus FedRAMP- und Selbstbescheinigungsanforderungen führt zu einem unmittelbaren Bedarf an konsistenter Transparenz in Softwarepaketen und automatisierten Prozessen zum Auffinden und Beseitigen von Schwachstellen.

Wenn Sie an die US-Bundesregierung verkaufen möchten, werden SBOMs bald eine Voraussetzung sein. Aber es gilt nicht nur für diejenigen, die an die Regierung verkaufen. Es ist davon auszugehen, dass das neue Selbstbescheinigungsmodell zur Zuweisung der rechtlichen Haftung für unsichere Software SBOMs wahrscheinlich in der gesamten Technologiebranche zum gängigen Sicherheitsstandard machen wird – oder zumindest für Softwareunternehmen, die in künftigen Sammelklagen nicht genannt werden möchten.

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.

Copyright © 2023 IDG Communications, Inc.