Eine Software-Stückliste (SBOM) für die Sicherheit der Open-Source-Lieferkette erstellen
14. März 2022
0 Min. LesezeitMehr denn je entwickeln Programmierer Webanwendungen auf Grundlage von Open-Source-Softwarebibliotheken. Doch obwohl diese Bibliotheken die Komponenten einer Software-Stückliste (SBOM) bilden, sind sich nicht alle Entwickler und Stakeholder in Unternehmen der erheblichen Auswirkungen bewusst, die die Einbindung von Bibliotheken Dritter auf die Sicherheit der Open-Source-Lieferkette hat. Sehen wir uns deshalb die Sicherheit von SBOMs und die Bedeutung ihrer Nachverfolgung für die Anwendungen an, die Sie entwickeln.
Bedenken hinsichtlich der Sicherheit der Software-Lieferkette bereiten Unternehmen und Regierungen zunehmend Sorgen. Der Bericht Threat Landscape for Supply Chain Attacks der Agentur der Europäischen Union für Cybersicherheit (ENISA) schätzte für 2021 einen Anstieg von Angriffen auf Software-Lieferketten um 400 %.
Die heute große Auswahl an Open-Source-Software für Entwickler und der einfache Import von Softwarekomponenten erhöhen das Risiko durch Sicherheits- und Rechtsfragen – für Entwickler und in der Folge auch für Unternehmen. Deshalb ist es wichtig, Entwickler und Sicherheitsteams zu schulen und ihnen fortschrittliche Lösungen für die Sicherheit der Lieferkette bereitzustellen.
Bevor wir tiefer einsteigen, sehen wir uns zunächst einige Grundlagen zu SBOMs an und erläutern die technischen Begriffe, die in diesem Artikel verwendet werden.
Was ist eine Software-Stückliste?
Eine Software-Stückliste, kurz SBOM, ist eine vollständige Liste aller Softwarekomponenten, die in einem Unternehmen verwendet werden. Sie umfasst Open-Source-Bibliotheken von Drittanbietern, bereitgestellte Pakete von Anbietern und eigene, vom Unternehmen entwickelte Artefakte.
Warum sollte ich eine SBOM erstellen?
Eine SBOM ist im Grunde ein Verzeichnis aller Softwarekomponenten, die Sie in Ihren Anwendungen verwenden. Ohne sie haben Sie keinen Überblick über die Lizenz- und Sicherheitsrisiken der Software, die Sie entwickeln oder nutzen. Eine aktuelle, formatkonforme Software-Stückliste ist entscheidend, um mit der schnellen Softwareentwicklung Schritt zu halten, bei der sich Komponenten und ihre Versionen rasch ändern.
Was ist CycloneDX?
OWASP CycloneDX ist ein SBOM-Standard für Anwendungssicherheit und die Analyse von Lieferkettenkomponenten. Er erfasst alle Softwarekomponenten aus erster und dritter Hand. Die umfangreiche Spezifikation umfasst neben Softwarebibliotheken auch Standards wie Software-as-a-Service-Stücklisten (SaaSBOM), Vulnerability Exploitability Exchange (VEX) und mehr. Der Standard ist ein Open-Source-Projekt unter Apache-2.0-Lizenz und kann im folgenden Open-Source-GitHub-Repository gemeinsam weiterentwickelt werden: https://github.com/CycloneDX/specification.
Sicherheitsbedenken, die Entwickler dazu veranlassen, eine Software-Stückliste zu pflegen
Der Begriff Software-Stückliste ist für Entwickler eher ungewohnt. Traditionell war ihre Erstellung Aufgabe der Sicherheits- und Risikobewertungsteams eines Unternehmens. Doch das hat sich durch den enormen Anstieg von Open-Source-Softwarekomponenten geändert. Das zeigt sich etwa an der npm-Paketregistrierung, die mehr als 1.800.000 kostenlose Open-Source-Pakete umfasst.
Wenn Sie als Entwickler bezweifeln, dass Sie für alle verwendeten Softwarekomponenten eine SBOM brauchen, erinnern wir Sie an einige bekannte Sicherheitsvorfälle der letzten Jahre, die auf Open-Source-Softwarebibliotheken zurückzuführen waren:
event-stream: Das beliebte npm-Paket wurde kompromittiert, um schädlichen Code einzuschleusen.
Log4Shell: In der beliebten Java-Logging-Bibliothek Log4j wurde eine schwerwiegende Sicherheitslücke zur Remotecodeausführung entdeckt. Diese Schwachstelle bestand bereits seit sieben Jahren, bevor sie gefunden wurde!
Wenn solche Sicherheitslücken oder Sicherheitsvorfälle entdeckt werden und Ihre Anwendung eine der betroffenen Versionen verwendet: Wer ist Ihrer Meinung nach dafür verantwortlich, diese Bibliotheken zu aktualisieren und eine neue Version bereitzustellen? Genau: die Entwickler.
Selbst wenn das Sicherheitsteam unabhängig arbeitet und die Software-Stückliste selbst pflegt, schlägt es bei solchen Problemen Alarm, benachrichtigt die zuständigen Teams und fordert Entwickler auf, anfällige Versionen zu aktualisieren. Aber in einer Welt mit fortschrittlichem Workflow-Management lässt sich dieser gesamte Prozess doch automatisieren und nativ in die Workflows von Entwicklern integrieren. Natürlich. Genau darum geht es bei Snyk, das Sie kostenlos nutzen können.
Warum sollten Entwickler die rechtlichen Auswirkungen ihrer Software-Stückliste berücksichtigen?
Rechtliche Aspekte der Softwarenutzung gehören heute wahrscheinlich nicht zu den ersten Dingen, an die Entwickler denken, wenn sie mit ihrem Code experimentieren und Anwendungen erstellen. Vor einigen Jahrzehnten war das jedoch anders. Entwickler und ihre Teams achteten sehr genau auf die konkrete Lizenz der Softwarekomponenten, die sie in ihren Code einbanden. Was hat sich geändert? Damals waren Copyleft-Lizenzen wie die GNU General Public License (GPL) am weitesten verbreitet. Sie schränkten die Weitergabe von Software stark ein. Kurz gesagt: Die GPL wirkt sich auf alle nachgelagerten Komponenten aus. Jeder Code, der mit einer GPL-lizenzierten Komponente erstellt wird, fällt automatisch ebenfalls unter die GPL – ein wichtiger Punkt für Ihr Geschäftsmodell.
Etwa 20 Jahre später beobachten wir eine deutliche Abkehr von Copyleft-Lizenzen. 2015 war die MIT-Lizenz die am häufigsten verwendete Lizenz in auf GitHub erstellten Open-Source-Repositories. Zusammen mit anderen Lizenzen gehört sie zu den permissiven Lizenzen. Diese schränken die Nutzung von Software deutlich weniger ein und geben Entwicklern mehr Freiheiten.
Wir erleben eine Phase in der Geschichte von Open-Source-Software, die von enorm wachsender Verbreitung und neu beigesteuerter Software unter sehr permissiven Lizenzen geprägt ist. Haben wir uns daran gewöhnt, Open-Source-Software standardmäßig zu nutzen? Nehmen wir ihre Lizenzierung inzwischen als selbstverständlich hin?
Zwei besonders bekannte Fälle rechtlicher Probleme mit Software, bei denen die Lizenzierung der jeweiligen Projekte im Mittelpunkt stand, haben Entwickler beschäftigt:
Die Lizenz der äußerst beliebten Open-Source-JavaScript-View-Bibliothek React wurde von der eigenen Variante „BSD + Patents grant“ auf die permissive MIT-Lizenz umgestellt. Grund dafür war, dass die Apache Software Foundation das React-Projekt ablehnte und die Lizenz von Facebook als zu restriktiv kritisierte. Weltweit übten auch Entwickler Druck aus: Viele erwogen, das Projekt ganz aufzugeben und zu Alternativen wie Preact zu wechseln. Quincy Larson hat die Ereignisse in diesem nützlichen freeCodeCamp-Artikel chronologisch aufbereitet.
Elastic, das Unternehmen und gleichnamige Open-Source-Projekt hinter dem beliebten Suchtool und ELK Stack, musste sich ebenfalls mit Lizenzänderungen auseinandersetzen. Anlass waren der zunehmende Wettbewerb durch Cloud-Anbieter und dessen Auswirkungen auf das Geschäft von Elastic.
Wenn Sie als Entwickler React, Elastic oder andere Open-Source-Softwarebibliotheken nutzen, sind Sie wahrscheinlich dafür verantwortlich, bei Lizenzproblemen die Migration von einem Projekt zu einem anderen zu planen.
Was passiert außerdem, wenn Sie Anwendungen entwickeln und Software bereitstellen, deren verschachtelte Komponenten unter einer Copyleft-Lizenz stehen? Die JavaScript- und Node.js-Ökosysteme sind für die große Zahl installierter npm-Pakete bekannt. Das Geschäftsrisiko ist real. Deshalb sollten Sie als Entwickler darauf achten, projektübergreifend zu verfolgen und zu verstehen, welche Softwarelizenzen verwendet werden.
Die von Ihnen entwickelten Anwendungen und die von Ihnen verwendete Software enthalten wahrscheinlich bereits Angaben zur jeweiligen Lizenz. Wenn Sie beispielsweise ein JavaScript-Projekt entwickeln, stehen die Lizenzinformationen in der Manifestdatei package.json:
Die in dieser Datei package.json angegebene Lizenz verwendet das verbreitete SBOM-Format SPDX. So wird sichergestellt, dass sie den internationalen Standards und den Interoperabilitätsstandards verschiedener Tools entspricht.
Was ist SPDX?
Software Package Data Exchange (SPDX) ist ein gemeinschaftliches Projekt der Linux Foundation. Es stellt einen einheitlichen SBOM-Formatstandard zur Nachverfolgung von Software-Stücklisten bereit und erleichtert die Erstellung von Interoperabilitätsberichten mit verschiedenen Tools. Die SPDX-Lizenzliste enthält insbesondere eindeutige Kennungen für gängige Lizenzen und eine kanonische URL für jede Lizenz.
Die folgende Webseite mit der SPDX-Lizenzliste enthält alle Lizenzen und ihre Kennungen:
Snyk bietet Funktionen zur Prüfung von Open-Source-Software. Ähnlich wie in der obigen Tabelle lassen sich damit Berichte zur Software-Stückliste erstellen, um eine umfassende Softwareprüfung durchzuführen – vollständig interaktiv, durchsuchbar und filterbar.
Die Nutzung von Open-Source-Bibliotheken durch Entwickler standardisieren
Ausgereifte Engineering-Organisationen entwickeln sich von einer spontanen und gelegentlichen Nutzung von Open-Source-Bibliotheken hin zu einem bewussteren und geplanten Einsatz in Projekten, der Richtlinien und Best Practices folgt.
JavaScript-Entwicklungsteams möchten beispielsweise möglicherweise sicherstellen, dass Entwicklerteams eine einzige ausgewählte HTTP-Anfrageabhängigkeit standardmäßig verwenden, statt sich auf eine Vielzahl von Abhängigkeiten zu stützen, etwa die npm-Pakete request, axios, node-fetch und weitere. Dabei geht es nicht nur darum, Open-Source-Abhängigkeiten leichter zu verwalten, sondern auch API-Wissen und Fachkenntnisse zu bündeln, Probleme einfacher zu beheben und mehr.
Können Sie für ein beliebiges Entwicklungsteam realistisch die folgenden Fragen beantworten?
Welche Open-Source-Bibliotheken verwende ich in meiner Forschungs- und Entwicklungsorganisation projektübergreifend am häufigsten?
Welche der von mir verwendeten Open-Source-Bibliotheken sind als veraltet gekennzeichnet?
Welche Open-Source-Bibliotheken in meinen Projekten stehen unter Copyleft-Lizenzen wie GPL-2?
Welche Open-Source-Bibliotheken wurden vor mehr als 15 Jahren veröffentlicht und seitdem nicht aktualisiert? Sollte Sie das beunruhigen?
All diese Erkenntnisse und mehr erhalten Sie, wenn Sie eine Software-Stückliste, also eine SBOM, pflegen. Snyk stellt im Rahmen der Funktionen von Snyk Open Source ebenfalls wertvolle Informationen zum Zustand von Open-Source-Paketen bereit:
Wie hilft eine SBOM dabei, die Lieferkettensicherheit schneller sicherzustellen?
Was ist die Sicherheit der Software-Lieferkette?
Traditionelle Anliegen der Anwendungssicherheit im Lebenszyklus der Softwaresicherheitsentwicklung haben sich weiterentwickelt: Sie umfassen heute nicht mehr nur den Code der Entwickler, sondern die gesamte Tooling-Infrastruktur, mit der Software erstellt wird. Dadurch entsteht eine enorm große Angriffsfläche – vom ersten Schritt, dem IDE-Tool, mit dem Entwickler Code schreiben, über die Open-Source-Komponenten, aus denen sie ihre Anwendungen erstellen, bis hin zu CI/CD-Pipelines und der Konfiguration der Bereitstellungsinfrastruktur. Tatsächlich ließe sich argumentieren, dass sich das Risiko für die Sicherheit der Lieferkette sogar auf die Hardware-Chips im Computer erstreckt, den Sie als Entwicklungsumgebung verwenden.
Das US-Handelsministerium veröffentlichte im Rahmen der Executive Order 14028 zur Verbesserung der Cybersicherheit der Vereinigten Staaten ein Dokument, das auf The Minimum Elements For a Software Bill of Materials (SBOM) verweist. Sehen wir uns genauer an, was es mit der Lieferkette auf sich hat und was wir daraus lernen können.
Die Software-Supply-Chain umfasst grundsätzlich alle Komponenten, die Teil des gesamten Workflows sind, mit dem Sie Software entwickeln. Vielleicht denken Sie zunächst, dass zur Software-Supply-Chain lediglich die Abhängigkeiten gehören, die Sie Ihren Projekten hinzufügen. Das stimmt zwar, doch die Software-Supply-Chain geht weit darüber hinaus.
Ihre IDE ist ebenfalls ein wichtiger Bestandteil Ihres Softwareentwicklungs-Workflows, oder? Welches Risiko würde es für Ihr Unternehmen bedeuten, wenn Ihre bevorzugte IDE Hintertüren oder Malware enthielte? Was wäre, wenn eine dieser IDE-Erweiterungen oder eines dieser Plug-ins schwerwiegende Sicherheitslücken aufwiese oder sogar schädlichen Code enthielte?
Sicherheitslücken in VS-Code-Erweiterungen
Sicherheitslücken in anfälligen VS-Code-Erweiterungen sind keine rein theoretische Gefahr. Im Mai 2021 deckte Snyk Sicherheitslücken in der Supply-Chain von Visual-Studio-Code-Erweiterungen auf, die im Marketplace für VS-Code-Erweiterungen verfügbar waren und laut Downloadzahlen mehr als 2.000.000 Entwicklerinnen und Entwickler betreffen.
Diese VS-Code-Erweiterungen, etwa Open in Default Browser mit über 520.000 Downloads oder Instant Markdown mit über 120.000 Downloads, stellen eine echte Bedrohung für Entwicklerinnen und Entwickler dar. Wenn Angreifer Entwickler dazu bringen, auf einen Link zu klicken, kann dadurch eine Path-Traversal-Sicherheitslücke entstehen, über die sie Zugriff auf sensible Dateien und Informationen in der Entwicklungsumgebung erhalten. Bei schwerwiegenderen Sicherheitslücken können Angreifer sogar beliebige Befehle aus der Ferne ausführen – allein dadurch, dass Entwickler auf einen Link klicken.
Das folgende Video zeigt, warum SBOM-Sicherheit in der Software-Supply-Chain ein wichtiges Thema für Entwickler ist. Es demonstriert einen Angriff auf die VS-Code-Erweiterung Instant Markdown und zeigt, wie dabei vertrauliche SSH-Schlüssel eines Entwicklers gestohlen werden:
Sicherheitslücken in Java-IDEs
Wenn Sie denken, dass die Supply-Chain-Sicherheit das JavaScript-Ökosystem ins Chaos stürzt, möchte ich Ihnen die Zeitleiste der ENISA zu 24 Vorfällen im Bereich Supply-Chain-Sicherheit innerhalb von nur 18 Monaten (Januar 2020 bis Juli 2021) zeigen. Dazu gehören auch Fälle, in denen schädliche Vorfälle in der Supply-Chain Java-Entwickler über die NetBeans-IDE betrafen:
Eine sichere Open-Source-SBOM pflegen
Wie können Sie also Risiken für die Sicherheit der Software-Supply-Chain während des gesamten Softwareentwicklungslebenszyklus (SDLC) minimieren? Eine aktuelle SBOM zu pflegen ist nicht nur ein guter Anfang, sondern wurde aufgrund der enormen Bedrohung, die Open-Source-Softwarekomponenten für Unternehmen und Regierungen gleichermaßen darstellen, auch durch eine Executive Order der US-Regierung vorgeschrieben.
Ein wichtiger Aspekt der Sicherheit in der Open-Source-Supply-Chain ist nicht nur die Bedrohungslage durch bekannte Sicherheitslücken und potenzielle Zero-Day-Angriffe, sondern auch der allgemeine Zustand eines Pakets. Signale wie der Rhythmus von Commits und Releases eines Projekts, die Anzahl offener Issues und die Größe der am Projekt beteiligten Community tragen alle zum allgemeinen Zustandswert des Pakets bei. Sie sollten Aufschluss über den Pflegezustand des Projekts geben und darüber, ob es anfällig für schädliche Aktivitäten ist.
Snyk hat Snyk Advisor entwickelt, um genau dieses Problem bei der Bewertung des Paketzustands im Hinblick auf die Sicherheit der Open-Source-Supply-Chain zu lösen. Derzeit werden Metadaten für Ökosysteme wie JavaScript, Go und Python sowie für Docker-basierte Container-Images unterstützt. Wir empfehlen Ihnen ausdrücklich, Snyk Advisor bei der Suche nach Open-Source-Bibliotheken zu nutzen.
Eine Open-Source-SBOM mit Snyk erstellen
Snyk Open Source verwendet Paketmanifeste und Lockfiles, um einen vollständigen Abhängigkeitsgraphen zu erstellen. So lassen sich Sicherheitslücken in der Abhängigkeitshierarchie und andere Probleme wie veraltete Pakete gezielt erkennen. Das allein ist jedoch noch keine SBOM.
Gareth Rushgrove, VP of Product bei Snyk, hat über die Weiterentwicklung von SBOM-Standards mit Snyk und SPDX geschrieben. In diesem Artikel berichtet Gareth, wie Snyk verschiedene Möglichkeiten zur Zusammenarbeit mit Community-Tools erkundet, und stellt snyk2spdx vor – ein Open-Source-Projekt, das die Ausgabe der Snyk CLI in das SPDX-Format konvertiert.
Wenn Sie die Snyk API nutzen, empfiehlt Gareth außerdem, über die Snyk API das zugrunde liegende Paketmanifest und die Details zu Sicherheitslücken als Datenquelle abzurufen und anschließend in SPDX zu konvertieren.
Zusammenfassend lässt sich sagen: Eine SBOM als festen Bestandteil der Softwareentwicklung und -bereitstellung vorzuschreiben, ist angesichts der heutigen Herausforderungen für die Supply-Chain-Sicherheit wichtig. So lassen sich Fragen zu Inventar, Integrität und Herkunft beantworten.
Die folgenden Artikel empfehlen wir Ihnen, um Ihr Wissen über die Supply-Chain-Sicherheit bei Open Source und Software-Stücklisten zu vertiefen:
Die Anforderungen an die Sicherheit der Software-Supply-Chain in der Executive Order zur Cybersicherheit verstehen von Daniel Berman
Einen ausführlichen Lizenzvergleich finden Sie in der Dokumentation zu Open-Source-Lizenzen: Arten und Vergleich
Die Lizenz-Compliance in Ihrem Unternehmen mit den Lizenzrichtlinien von Snyk verwalten von Josepha Riveros
Entdecken Sie anhand der Snyk-Dokumentation eine praktische Verwaltung von Lizenzrichtlinien auf der Snyk-Plattform
Sichern Sie Ihre Open-Source-Abhängigkeiten
Die entwicklerorientierten Tools von Snyk erstellen mit einem Klick Fix-Pull-Requests für anfällige Open-Source-Abhängigkeiten und deren transitive Abhängigkeiten.