Senken Sie das Risiko für Ihre Supply-Chain mit einer Software-Stückliste (SBOM)

Heute freuen wir uns, im Rahmen unserer kontinuierlichen Arbeit an unserer Lösung für Software-Supply-Chain-Sicherheit einige neue Funktionen vorzustellen. Diese entwicklerorientierten Tools helfen Ihnen, die Supply-Chain Ihrer App besser zu verstehen, potenzielle Risiken zu erkennen und die notwendigen Schritte zu unternehmen, um ihnen zuvorzukommen.

Der Aufstieg von SBOMs als wichtiger Bestandteil der Supply-Chain-Sicherheit

Moderne Anwendungen werden eher zusammengesetzt als entwickelt. Kostenlose und Open-Source-Software macht mehr als 70 % moderner Software aus. Die Verwendung von Open Source in Ihrer App kann zwar die Markteinführungszeit verkürzen, aber auch Komplexität und Risiken in Ihrer Supply-Chain mit sich bringen.

Als Reaktion auf die jüngsten regulatorischen Leitlinien, die Unternehmen dabei unterstützen sollen, sich selbst zu schützen, nehmen viele Teams die Erstellung von Software-Stücklisten (SBOMs) in ihren SDLC auf.

Zur Erinnerung: Eine SBOM ist ein Verzeichnis der Komponenten, aus denen Ihre Anwendung besteht, einschließlich ihrer Abhängigkeiten. Sie können sich das als ähnlich zur „Stückliste“ in der Fertigung vorstellen, die Käufern Auskunft über die Teile eines bestimmten Produkts gibt. Standardisierte SBOM-Formate wie CycloneDX und SPDX machen dieses Verzeichnis sowohl für Menschen lesbar als auch für nachgelagerte Tools nutzbar.

Für AppSec-Teams ist dieser Einblick in die Zusammensetzung über das gesamte Unternehmen hinweg ein wichtiger Schritt, um die Risiken von Supply-Chain-Angriffen zu verstehen und zu mindern und gleichzeitig regulatorische Vorgaben einzuhalten.

Doch wie setzen Sie diese Praktiken um? Und welche Auswirkungen haben sie auf die Entwickler-Workflows?

In der Vergangenheit konnte eine Verbesserung der Sicherheitslage die Entwicklungsteams ausbremsen. Wir sind jedoch fest davon überzeugt, dass Entwickler nicht zwischen Innovation und Sicherheit wählen müssen. Mit Snyk erstellen Sie ganz einfach eine SBOM für Ihre Anwendungen. So erhalten Sie Einblick in deren Bausteine (z. B. Open-Source-Komponenten, Bibliotheken und Frameworks) und erfahren, wie sie zusammenarbeiten.

Snyk ist jetzt allgemein verfügbar (GA) und bietet entwicklerorientierte CLI-Tools, mit denen Sie SPDX- oder CycloneDX-SBOMs lokal oder über Ihre CI/CD-Pipelines erstellen können.

snyk sbom --format spdx2.3+json --all-projects

Mit der ebenfalls jetzt allgemein verfügbaren (GA) Project SBOM API können Sie über einen einzigen API-Endpunkt eine SBOM für jedes Open-Source- oder Container-Projekt erstellen, das Sie in Snyk importiert haben.

Beispiel für ein Paket in einer SBOM

1{
2"bom-ref": "35-curl@7.52.1-5",
3"type": "library",
4"name": "curl",
5"version": "7.52.1-5",
6"purl": "pkg:deb/debian/curl@7.52.1-5?distro=stretch"
7}

Mit SBOMs Risiken erkennen und Maßnahmen ergreifen

Die Erstellung einer SBOM ist ein wichtiger Schritt, um Transparenz zu schaffen und Compliance-Anforderungen zu erfüllen. Sie ist jedoch nur ein Teil der Lösung. SBOM-Artefakte bieten nachgelagerten Nutzern oft keine umsetzbaren Erkenntnisse.

Als Entwickler oder AppSec-Fachkraft müssen Sie SBOMs und deren Inhalte außerdem testen, um potenzielle Probleme zu erkennen und schneller darauf reagieren zu können. Wenn sich die SBOM-Erstellung in Ihrem Unternehmen zunehmend durchsetzt und Sie damit beginnen, SBOMs von Zulieferern (z. B. SaaS-Anbietern) zu erhalten, müssen Sie wahrscheinlich verschiedene Formate testen, die mit unterschiedlichen Tools erstellt wurden.

Möglicherweise möchten Sie sogar eine Plattform entwickeln, um dies für alle Teams Ihres Unternehmens zu verwalten.

Für Anfang des dritten Quartals planen wir die Beta-Version unserer SBOM-Testfunktion. Mit dieser API können Sie CycloneDX- und SPDX-SBOMs auf bekannte Schwachstellen und Lizenzprobleme in unserer führenden Schwachstellendatenbank prüfen.

Mit der jetzt allgemein verfügbaren (GA) Package Issues API stellen wir Ihnen außerdem Tools zur Verfügung, mit denen Sie anhand der Package-URL (purl) Schwachstellen auf Paketebene abfragen können. Die API unterstützt verschiedene Programmier- und Betriebssystem-Ökosysteme. Teams können mit dieser granularen Low-Level-API Tests flexibel an ihre Anforderungen anpassen.

Beispiel: Probleme für ein Paket abrufen

Sie können ein einzelnes Paket mit einer GET-Anfrage und einer URL-kodierten purl abfragen:

https://api.snyk.io/rest/orgs/{{orgId}}/packages/pkg%3Adeb%2Fdebian%2Fcurl%407.52.1-5%3Fdistro%3Dstretch/issues?version=2023-05-10

Beispiel für eine zurückgegebene Schwachstelle (gekürzt)

1...
2"id": "SNYK-DEBIAN9-CURL-2936242",
3"type": "issue",
4"attributes": {
5"key": "SNYK-DEBIAN9-CURL-2936242",
6"title": "Out-of-bounds Write",
7"type": "package_vulnerability",
8"created_at": "2022-06-28T02:25:54.487787Z",
9"updated_at": "2023-02-14T13:32:10.421029Z",
10"description": "## NVD Description\n**_Note:_** _Versions mentioned in the description apply only to the upstream `curl` package and not the `curl` package as distributed by `Debian:9`._\n_See `How to fix?` for `Debian:9` relevant fixed versions and status._\n\nWhen curl < 7.84.0 does FTP transfers secured by krb5, it handles message verification failures wrongly. This flaw makes it possible for a Man-In-The-Middle attack to go unnoticed 
11...

Den Mehrwert von SBOMs steigern

Transparenz über die Zusammensetzung einer Anwendung ist für sich genommen wertvoll. SBOM-Artefakte enthalten jedoch in der Regel nur begrenzte Informationen.

Diese Informationen eignen sich zwar als Eingabe für Schwachstellentests, lassen aber vieles offen: Nutzer der Artefakte müssen die SBOM weiterhin selbst auswerten, um die benötigten Erkenntnisse zu gewinnen.

Wenn wir SBOMs erstellen und sie zusammen mit ihren Komponenten testen können, warum lassen sich diese Informationen dann nicht von Anfang an in das Artefakt aufnehmen? Mit Parlay, Snyks neuestem Beitrag zur Open-Source-Community, wollen wir genau dieses Problem lösen.

Die führenden Formate CycloneDX und SPDX bieten in ihren Schemata bereits Erweiterungsmöglichkeiten. So lässt sich eine SBOM um zusätzliche Metadaten wie Schwachstellen und Herkunftsnachweise ergänzen.

Das ist besonders für nachgelagerte Nutzer wie AppSec-Teams von Vorteil: Sie erhalten eine Momentaufnahme der Anwendung samt umfangreichen Daten, mit denen sie Aktionen automatisieren oder fundierte Entscheidungen treffen können.

Lesen Sie diesen Blog und erfahren Sie mehr über die Möglichkeiten, die dieses Projekt eröffnet. Alle Details, die Sie verpasst haben, finden Sie in der Aufzeichnung auf Abruf von SnykLaunch.