Software-BOM: Kernsäule für Sicherheit in der Open-Source-Lieferkette

Ob in Web-, Mobile- oder andere Kontexten, als Fundament zur Entwicklung moderner Anwendungen nehmen Software-Bibliotheken aus der Open-Source-Community heute eine wichtigere Rolle ein als je zuvor. Wie weitreichend die Auswirkungen dieser Elemente auf die Sicherheit in der Software-Lieferkette sind, darüber sind sich allerdings nicht alle Entwickler und Business-Stakeholder im Klaren. Umso wichtiger ist es daher, nachvollziehen zu können, auf welchen Open-Source-Komponenten eine Anwendung im Einzelnen aufbaut. Genau das wird in einer Software Bill of Materials bzw. SBOM festgehalten. Wie genau Sie diese zusammenstellen und worin ihre Bedeutung im Einzelnen liegt, beleuchten wir im Folgenden.

Bedrohungen für die Sicherheit in der Software-Lieferkette sind inzwischen zu einer Problematik herangewachsen, die den privaten wie auch öffentlichen Sektor mit größter Sorge erfüllt. Wie enorm ihr Ausmaß ist, macht etwa eine aktuelle Studie der Agentur der Europäischen Union für Cybersicherheit ENISA deutlich. Danach war allein 2021 eine Zunahme der Angriffe auf Software-Lieferketten um nicht weniger als 400 % zu verzeichnen.

Ein Problem im Kontext von Open-Source-Software ist jedoch nicht nur die Bedrohungslage. Denn die immense Auswahl entsprechender Software-Komponenten lässt sich heute so einfach in den Dev-Prozess einbinden, dass daraus in zunehmendem Maße auch rechtliche Risiken entstehen.

Bevor wir hier aber zu weit ausholen, wollen wir den Fokus auf die Software-BOM und darauf richten, welche Konzepte ihr zugrunde liegen und welche Begrifflichkeiten in diesem Zusammenhang von Bedeutung sind.

Was versteht man unter einer Software-BOM?

In einerSoftware Bill of Materials, kurz SBOM, werden sämtliche Komponenten festgehalten, aus denen sich ein Software-Produkt zusammensetzt. Dies umfasst Bibliotheken aus externen Open-Source-Quellen und Pakete von Drittanbietern ebenso wie intern entwickelte Artefakte.

Wozu braucht es eine SBOM?

Erst durch eine lückenlose Bestandsaufnahme der Einzelkomponenten einer Anwendung lassen sich sicherheits- und lizenzbezogene Risiken im Zusammenhang mit ihrer Entwicklung und Nutzung zuverlässig erfassen. Noch mehr gilt dies angesichts der Dynamik, mit der sich die einer Anwendung zugrunde liegenden Komponenten und ihre Versionen im Zuge agiler Software-Entwicklung ändern. Eine SBOM, idealerweise in standardkonformer Ausfertigung, kann hier lückenlos Aufschluss über den Status quo liefern.

What ist CycloneDX?

Mit CycloneDX hat das Open Worldwide Application Security Project (OWASP) einen Standard für AppSec-Kontexte sowie die Analyse von Komponenten in der Software-Lieferkette entwickelt, der die Erfassung sämtlicher intern entwickelter und Drittanbieter-Elemente einer Anwendung erleichtert. Neben Use Cases rund um Software-Bibliotheken werden dabei auch Standards wie Software-as-a-Service-BOM (SaaSBOM) und Vulnerability Exploitability Exchange (VEX) unterstützt. Als Open-Source-Projekt mit Apache 2.0 Lizenzierung kann der Standard frei genutzt werden. Das zugehörige Repository ist unter https://github.com/CycloneDX/specification abrufbar und steht der Entwickler-Community offen für Beiträge zur Verfügung.

Sicherheitsfragen als Mandat zur Erstellung einer Software-BOM durch Entwickler

Unter Entwicklern dürfte sich das Konzept der Software-BOM nicht unbedingt größter Beliebtheit erfreuen, fiel ihre Ausfertigung traditionell doch eher in den Aufgabenkatalog der Funktionsbereiche Sicherheit und Risikomanagement. Angesichts der immensen Zunahme an Open-Source-Komponenten, die heute verfügbar sind, ist diese Aufteilung jedoch nicht mehr zielführend. Deutlich macht dies etwa ein Blick auf die npm Package-Registry: Allein darin findet man nicht weniger als rund 1,8 Millionen frei verfügbare bzw. Open-Source-Pakete.

Vor diesem Hintergrund seien Entwickler, die womöglich noch an der Sinnhaftigkeit einer Software-BOM zweifeln, nur kurz an zwei der der prominentesten Beispiele für besonders schwerwiegende Security Incidents im Zusammenhang mit Open-Source-Bibliotheken der jüngeren Vergangenheit erinnert:

1. event-stream: Bei diesem nicht gerade selten genutzten Vertreter aus der npm-Registry wurde eine Kompromittierung bekannt, durch die Schadcode über das Paket verbreitet wurde.

2. Log4Shell: Für großes Aufsehen sorgte diese höchst bedenkliche Schwachstelle in der populären und weit verbreiteten Java-Logging-Bibliothek Log4j, über die sich Remote-Code ausführen ließ. Bestanden hatte sie dabei tatsächlich schon 7 Jahre lang, bevor sie überhaupt entdeckt wurde.

Bedenken sollten Entwickler hierbei außerdem: Werden Schwachstellen in den von ihnen genutzten Bibliotheken bekannt, muss sich ihrer auch jemand annehmen. Oder genauer: Upgrades der anfälligen Versionen im Programmcode vornehmen – eine Aufgabe, der sie sich dann logischerweise selbst widmen müssen.

Und daran wird sich auch nicht viel ändern, selbst wenn sich bei ihnen noch immer nur das Security-Team um die Software-BOM kümmern sollte. Denn stellt es entsprechende Probleme fest, wird es bei den jeweils zuständigen Dev-Teams Alarm schlagen und eben diese zum Upgrade der anfälligen Versionen anweisen. Um diese Aufgaben umhin kommt man also ohnehin nicht. Daher stellt sich vielmehr die Frage, ob sich all diese Prozesse nicht auch automatisieren und so nahtloser in Dev-Workflows integrieren lassen. Genau hier kommt Snyk ins Spiel. Nicht nur, dass die Lösung all dies möglich macht, sie ist zum Einstieg sogar kostenlos nutzbar – registrieren Sie sich dazu einfach hier.

Rechtliche Fallstricke: Für Entwickler so präsent wie nie zuvor

Rechtsfragen rund um die Nutzung von Software-Code finden in der Anwendungsentwicklung heute womöglich nicht immer allzu große Beachtung. Noch vor einigen Jahrzehnten sah dies noch völlig anders aus: Im Entwicklerteam achtete man sehr genau darauf, welches Lizenzmodell den Software-Komponenten zugrunde lag, die man in seinen Code einbrachte. Denn damals unterlagen die meisten Lizenzen noch dem Copyleft-Prinzip, das eine Reihe bedeutender Restriktionen hinsichtlich der Verbreitung von Software vorsieht. Insbesondere zu nennen ist hier die GNU General Public License, bei der es im Kern darum geht, dass mit ihr eine Art Kaskadeneffekt einher geht: Jeder Code, der eine unter ihr lizenzierte Komponente beinhaltet, unterliegt automatisch ebenfalls der GPL. Ein aus geschäftlicher Sicht also nicht gerade unerheblicher Faktor.

Rund 20 Jahre darauf wurde das Copyleft-Modell weitgehend durch andere Ansätze abgelöst. So gilt seit ca. 2015 für den Großteil der auf GitHub verfügbaren Open-Source-Repositories die sogenannte MIT-Lizenz. Diese gehört zur Kategorie freizügiger bzw. „permissive“ Lizenzen, bei denen zahlreiche der bei anderen Modellen geltenden Restriktionen wegfallen. Entwickler erhalten damit deutlich weiter reichende Freiheiten im Hinblick auf die Nutzung entsprechend lizenzierter Open-Source-Tools.

Nicht zuletzt auch aufgrund dieser Entwicklung erlebt Open-Source-Software heute einen so immensen Zulauf – und nimmt die Zahl an immer neuen Projekten mit ebenso freizügigen Lizenzmodellen laufend zu. So scheint es aber auch, dass die Nutzung von Open-Source-Software heute gewissermaßen als Selbstverständlichkeit gesehen wird und die Frage danach, ob und welche Lizenzen dahinter stehen, fast gänzlich aus der Wahrnehmung verschwunden ist.

Die Realität ist jedoch, dass Rechtsfragen in diesem Kontext heute noch genauso von Bedeutung für Entwickler sind wie in der Vergangenheit. Deutlich machen dies zwei besonders prominente Fälle von Open-Source-Projekten, bei denen Änderungen der innerhalb dieser angewandten Lizenzierung weitreichende Auswirkungen für Entwickler hatten:

1. Die React-Bibliothek, in der Dev-Community ob ihrer Möglichkeiten zur Umsetzung JavaScript-basierter UIs äußerst beliebt, wurde ursprünglich unter einem Modell namens „BSD+Patents“ lizenziert, das ihr Herausgeber Facebook dann durch eine freizügige MIT-Lizenz ersetzte. Der Entscheidung vorangegangen war eine Verfügung der Apache Software Foundation, nach der unter ihrem Dach keine entsprechend lizenzierten Open-Source-Produkte mehr genutzt werden durften. In der Folge wuchs zudem der Druck vonseiten der Entwickler-Community, in der man zunehmend erwog, dem React-Projekt ganz den Rücken zu kehren und stattdessen auf Alternativen wie Preact zu setzen. Eine interessante Chronologie der Ereignisse rund um diesen Fall hat freeCodeCamp-Gründer Quincy Larson in diesem Artikel zusammengefasst.

2. Elastic, bekannt für die gleichnamige Open-Source-Suchmaschine sowie das Projekt ELK Stack, sah sich ebenfalls zu Anpassungen an seinem Lizenzmodell gezwungen. Mit zunehmendem Konkurrenzdruck durch Cloud-Anbieter waren die Gründe hier allerdings etwas anders gelagert.

Was bedeutet es nun für Entwickler, wenn in den von ihnen genutzten Open-Source-Bibliotheken Lizenzprobleme wie diese aufkommen? Nun, sehr wahrscheinlich werden sie es sein, die ggf. ihren gesamten Code auf die Migration zu einem anderen Projekt abstimmen müssen.

Noch komplizierter wird es aber, wenn sich nach Auslieferung einer Anwendung herausstellt, dass sich innerhalb einer der in ihr verschachtelten Komponenten eine Copyleft-Lizenz verbirgt. So sind etwa Komponenten aus dem JavaScript- und Node.js-Ökosystem besonders bekannt dafür, dass mit ihnen eine Vielzahl weiterer npm-Pakete installiert wird. Entsprechende Risiken sind also keinesfalls zu unterschätzen. Umso wichtiger ist es daher, dass Entwickler sämtliche in Ihren Projekten genutzte Software-Lizenzen dokumentieren und klar nachvollziehen können.

Hierbei nützlich zu wissen: Bisweilen findet sich bereits direkt in der jeweiligen Open-Source-Software ein Hinweis auf die ihr zugrunde liegende Lizenz. Bei JavaScript-Projekten etwa finden sich Informationen zur Lizenz in der Manifest-Datei package.json, wie im nachfolgenden Screenshot gezeigt:

1{
2  "name": "snyk",
3  "version": "1.0.0-monorepo",
4  "description": "snyk library and cli utility",
5  "files": [
6    "help/cli-commands",
7    "dist",
8    "bin",
9    "pysrc",
10    "config.default.json",
11    "SECURITY.md",
12    "LICENSE",
13    "README.md"
14  ],
15  "author": "snyk.io",
16  "license": "Apache-2.0",

Die in dieser package.json Datei beispielhaft angegebene Lizenz unterstützt zudem SPDX, ein standardisiertes SBOM-Format für Interoperabilität über verschiedene Tools hinweg.

Was ist SPDX?

Software Package Data Exchange bzw. SPDX ist ein Standard, der ein einheitliches Format zum SBOM-Tracking bietet. Ins Leben gerufen wurde es von der Linux Foundation, um Interoperabilität beim Reporting der für Software-BOMs nötigen Daten über eine Vielzahl von Tools hinweg zu ermöglichen. Umgesetzt wird dies über eine Liste aller Lizenzen, die den Standard unterstützen, in der jede einzelne anhand einer ID sowie einer kanonischen URL identifiziert wird.

Der nachfolgende Screenshot zeigt ein Beispiel für eine mit SDPX erstellte Software-BOM. Eine vollständige Liste der von SPDX abgedeckten Lizenzen finden Sie hier.

Auch Snyk bietet umfassende Unterstützung für diesen Standard. Dies zudem mit weiteren Reporting-Features für Software-BOMs für komplett interaktive Software-Audits, die von diversen Suchfunktionen bis hin zu smarten Filtern reichen.

Standardisierung der Nutzung von Open-Source-Bibliotheken im Dev-Team

Eine zielführende Methodik rund um Open-Source-Bibliotheken beinhaltet, nicht einfach für alles die „nächstbeste“ zu nutzen. Vielmehr gilt es, hierfür projektspezifische Policies und Best-Practice-Frameworks zu etablieren.

So wäre es für Dev-Teams mit JavaScript-Fokus etwa sinnvoll, einen Standard für die Nutzung einer bestimmten Abhängigkeit für HTTP-Anfragen zu definieren. Dadurch wird vermieden, dass etwa aus dem npm-Paket request, axios, node-fetch und anderen ein kaum mehr zu durchblickendes Geflecht aus Abhängigkeiten entsteht. Neben der deutlich einfacheren Handhabung bietet dies zudem noch diverse weitere Vorteile. So wird etwa Know-how rund um APIs gebündelt, Probleme lassen sich leichter beheben und vieles mehr.

Hinzu kommt, dass sich essenzielle Fragen rund um Open-Source-Bibliotheken zuverlässig beantworten lassen, so etwa:

• Welche Open-Source-Bibliotheken finden innerhalb der Projekte der R&D-Organisation am meisten Anwendung?

• Welche der jeweils genutzten Bibliotheken werden vom Herausgeber als „eingestellt“ geführt?

• Welche der in den verschiedenen Projekten genutzten Open-Source-Bibliotheken unterliegen Copyleft-Lizenzen wie GPLv2?

• Welche Open-Source-Bibliotheken sind seit mehr als 15 Jahren öffentlich verfügbar und wurden seither nicht mehr aktualisiert? Und geht damit ein Risiko einher?

Insights wie diese kann eine adäquat ausgefertigte Software-BOM liefern. Darüber hinaus aber auch noch deutlich mehr: Die Features von Snyk Open Source etwa geben überdies auch Aufschluss darüber, wie es um den Health-Status von Open-Source-Paketen bestellt ist.

Die SBOM als Enabler für Sicherheit in der Software-Lieferkette

Was bedeutet Sicherheit in der Software-Lieferkette?

Im SDLC betreffen Fragen rund um die Anwendungssicherheit längst nicht mehr nur in Eigenregie entwickelten Code. Vielmehr geht es dabei um die gesamte Tooling-Infrastruktur, auf die sich Entwickler stützen. Denn die Angriffsfläche erstreckt sich heute von der ersten Codezeile, die Entwickler in der IDE schreiben, über sämtliche ihren Anwendungen zugrunde liegenden Open-Source-Komponenten bis hin zu den CI/CD-Pipelines und Konfigurationen der Infrastruktur, auf der das Deployment erfolgt. Tatsächlich könnte man sogar noch weiter gehen. Denn de facto stellen selbst Chips der Computer, die Entwickler in ihrer Dev-Umgebung nutzen, einen potenziellen Risikofaktor für die Sicherheit in der Software-Lieferkette dar.

Einen guten Richtungsgeber in diesem Kontext bildet der Anforderungskatalog, den das US-Handelsministerium als Reaktion auf die jüngst von Präsident Joe Biden erlassene Verordnung zur Stärkung der Cybersicherheit des Landes herausgegeben hat. Dieser sieht eine Reihe von Mindestanforderungen für eine Software Bill of Materials (SBOM) vor. Neben dieser lohnt aber auch noch ein näherer Blick auf die Software-Lieferkette als solche.

Im Prinzip setzt sich die Software-Lieferkette aus allen Komponenten zusammen, die den Workflow zur Auslieferung eines fertigen Software-Produkts ermöglichen. Auch wenn man geneigt sein mag, in ihr nur die Abhängigkeiten zu betrachten, geht die Software-Lieferkette tatsächlich noch viel weiter.

So ist die IDE etwa ein logischerweise unverzichtbares Element innerhalb des Dev-Workflows. Was aber, wenn die in Ihrem Team favorisierte IDE-Lösung Schwachstellen aufweist oder womöglich sogar mit Malware infiziert ist? Oder aber es sind Erweiterungen oder -Plug-ins in diesen IDEs, von denen entsprechende Gefahren ausgehen.

Schwachstellen in VS Code-Erweiterungen

Tatsächlich sind derartige Schwachstellen mitnichten ein theoretisches Konstrukt. Erst im Mai 2021 konnte Snyk Schwachstellen in Visual Studio Code Erweiterungen auf dem Marktplatz der Lösung aufdecken, von denen gemäß der Download-Zahlen mehr als 2 Millionen Entwickler betroffen waren.

Anfällig war etwa die Erweiterung Open in Default Browser, die 520.000 Downloads verzeichnete, sowie Instant Markdown, die es immerhin auf 120.000 Downloads brachte. Die von ihnen ausgehende Bedrohung war dabei durchaus bedenklich, denn ausnutzen ließen sich die Schwachstellen durch nicht mehr als einen Klick auf einen Link. Hierdurch konnten Angreifer dann ein Path Traversal auslösen, das ihnen Zugang zu sensiblen Dateien und Informationen innerhalb der Dev-Umgebung des Betroffenen eröffnete. Bei noch schwerwiegenderen Ausprägungen der festgestellten Schwachstellen wurde so jedoch auch die Remote-Ausführung von Code möglich.

Nachfolgend wird gezeigt, wie sich über einen Exploit gegen die Instant-Markdown-Erweiterung sensible SSH-Schlüssel aus der Umgebung des betroffenen Entwicklers ausschleusen lassen. Deutlich wird dadurch einmal mehr, dass sich Risiken für die Software-Lieferkette buchstäblich bis vor die Haustür von Entwicklern ziehen – und eine Software-BOM unbedingt dieses Ende abdecken muss.

Schwachstellen in IDEs für Java-Entwickler

Man ahnt es ja quasi bereits: In punkto Bedrohungen für die Software-Lieferkette steht das Ökosystem rund um JavaScript weit oben auf der Liste. Das zeigt etwa auch das nachfolgende Schaubild aus dem bereits zitierten Bericht der ENISA. In zeitlicher Abfolge sind darin 24 Security Incidents im Zusammenhang mit der Java-IDE NetBeans dargestellt, die von Januar 2020 bis Juli 2021 gemeldet wurden – also einem Zeitraum von gerade einmal 18 Monaten.

Mehr Sicherheit durch gute SBOM-Pflege

Vor diesem Hintergrund wird umso deutlicher, wie wichtig es ist, Sicherheit in der Software-Lieferkette über das gesamte SDLC hinweg zu adressieren. Genau hierfür bildet eine Software-BOM einen entscheidenden ersten Ansatzpunkt – und wurde nicht zuletzt auch deshalb per Verordnung von der US-Regierung vorgeschrieben. Denn erst durch eine stets aktuelle Sicht auf sämtliche Open-Source-Komponenten lassen sich die verschiedensten Bedrohungen klar erfassen, die von ihnen für den privaten und öffentlichen Sektor gleichermaßen ausgehen.

Betrachtet werden sollte in diesem Kontext jedoch nicht nur die Bedrohungslandschaft rund um bekannte Schwachstellen und potenzielle Zero-Day-Angriffe allein. Denn nicht weniger wichtig ist, wie es um den Health-Status eines Open-Source-Pakets insgesamt bestellt ist. Dies etwa im Hinblick auf die Commit- und Release-Frequenz und darauf, wie viele Probleme im jeweiligen Projekt noch offen sind. Relevant ist hier außerdem auch die Zahl der Entwickler, die aktiv zu ihm beitragen. Aspekte wie diese geben Aufschluss darüber, wie gut die Projekt-Maintenance ist und inwieweit Anfälligkeiten gegenüber böswilligen Aktivitäten bestehen.

Fragestellungen wie diese lassen sich mit dem Snyk Advisor so präzise wie unkompliziert adressieren. Denn neben einer Aufschlüsselung der Einzelfaktoren für die Sicherheit eines Open-Source-Pakets liefert das Tool auch direkt eine Gesamtbeurteilung in Form eines Health-Score. Unterstützt werden dabei von JavaScript, Go und Python bis hin zu Docker-basierten Container-Images verschiedenste Ökosysteme – alles also, was Entwickler im Open-Source-Kontext benötigen.

Direkter zur Open-Source-SBOM mit Snyk

Snyk Open Source analysiert Manifest-Dateien aus Paketen sowie Lockfiles auf Abhängigkeiten und überführt diese in eine umfassende Ansicht der hierarchischen Struktur. So wird es möglich, Schwachstellen punktgenau auszumachen und andere Risiken etwa im Zusammenhang mit Paketen zu identifizieren, deren Support-Ende erreicht wurde. Eine Software-BOM im eigentlichen Sinne ist dies jedoch noch nicht.

Vielmehr unterstützen wir ihre Umsetzung anhand einer Reihe von Innovationen rund um SPDX- und SBOM-Standards, die Snyk Product VP Gareth Rushgrove in diesem Artikel erläutert. Dabei geht es insbesondere darum, wie wir die Tools der Community enger in unsere Lösungen einbinden. So etwa auch mit unserem Open-Source-Projekt snyk2spdx, mit dem sich Daten aus der Snyk CLI in das SPDX-Format konvertieren lassen.

Erläutert wird darin außerdem das Potenzial der Snyk API in diesem Kontext. Denn damit ist es möglich, Manifest-Dateien sowie Details zu Schwachstellen aus Paketen abzurufen und die Daten SPDX-konform zu konvertieren.

All dies hilft dabei, die Umsetzung einer Software-BOM von der Entwicklung bis zur Delivery nahtlos ins gesamte SDLC zu integrieren. Zentrale Problemstellungen im Kontext der Sicherheit in den Software-Lieferketten von heute lassen sich so adäquat adressieren – von Klarheit über Art und Umfang genutzter Komponenten über ihre Integrität bis hin zu ihrem Ursprung.

Für weitere Insights rund um die Themen Sicherheit in der Lieferkette im Open-Source- und SBOM-Kontext unbedingt zu empfehlen sind außerdem die folgenden Artikel:

• Wissenswertes zur Verordnung des US-Präsident zur Stärkung der Cybersicherheit von Daniel Berman

• Deep Dive: Open-Source-Lizenzen: Typen und Gegenüberstellung

• Policy-gestütztes Compliance-Management für Open-Source-Lizenzen mit Snyk von Josepha Riveros

• Dokumentation zu Policy-Management für Software-Lizenzen mit der Snyk Plattform