Software Bill of Materials (SBOM) erklärt: Warum SBOMs für die Cybersicherheit unverzichtbar sind

SBOMs sind wertvoll für:

• Einhaltung gesetzlicher Vorschriften

• Kompatibilität zwischen älteren Softwarepaketen und OSS-Updates

• Schutz von Kunden vor Cyberangriffen auf die Software-Lieferkette

• Sicherheitsmaßnahmen bei Fusionen, an denen Software und Lizenzen beteiligt sind

Unterschied zwischen SBOM und CBOM

Die Cybersecurity Bill of Materials (CBOM) von 2018 deckt Software und Hardware in einer Executive Order ab. Eine SBOM dokumentiert nur die Softwarekomponenten im Code sowie deren Versionsverlauf, Patches, Lizenzen, Updates und Änderungen.

Warum sind SBOMs für die Cybersicherheit wichtig?

Cyberangriffe auf die Software-Lieferkette nehmen zu. Mehr als die Hälfte dieser Angriffe geht auf etablierte Advanced Persistent Threat (APT)-Cybercrime-Gruppen zurück. Ihr Ziel ist es, das Vertrauen von Nutzern und Anbietern in ihre Systeme auszunutzen.

Die Lieferkette ist anfällig, weil es an Transparenz bei Cybervorfällen mangelt. Entwickler wissen möglicherweise nicht von bestehenden Schwachstellen, wodurch auch Nutzer gefährdet sein können. Open-Source-Bibliotheken sind von anderen Softwarekomponenten abhängig. Die Schwachstelle Log4Shell ist ein Beispiel für eine Komponente – in diesem Fall eine Protokollierungsbibliothek –, die viele Entwickler nie überprüfen, weil sie keine direkte Software-Abhängigkeit ist, sondern eine transitive Abhängigkeit, von der andere Komponenten abhängen.

Entwicklungsteams erkennen zwar bereits die Notwendigkeit von Application Security, doch SBOMs schaffen zusätzliche Transparenz in Software-Lieferketten und hinsichtlich potenzieller Schwachstellen. Wenn Nutzer wissen, wo sich Schwachstellen in einem Softwareprodukt verbergen könnten – und welche Softwarekomponenten verwendet werden, insbesondere wenn sieOpen Source sind –, können sie Sicherheitstools gezielter einsetzen, um potenzielle Angriffe zu erkennen und abzuwehren.

Kommt es zu einem Cyberangriff, lässt sich mithilfe der SBOM feststellen, welche Software anfällige Komponenten enthält und welche Risiken bestehen. So können Nutzer gemeinsam mit Entwicklern einen Patch oder eine andere Lösung zur Risikominderung erarbeiten.

Executive Order 14028 zu SBOMs

Noch vor Log4Shell zeigten andere Cybervorfälle wie der SolarWinds-Lieferkettenangriff und der Vorfall bei Equifax im Zusammenhang mit Apache Struts, wie anfällig Regierungsbehörden sowie große Unternehmen und Betriebe in der gesamten kritischen Infrastruktur sind. Sie machten auch deutlich, wie abhängig alle Organisationen von der Software-Lieferkette sind und dass eine einzige ausgenutzte Schwachstelle weitreichende Folgen haben kann.

Die Executive Order 14028 verpflichtet Regierungsbehörden, darunter das National Institute of Standards and Technology (NIST), die National Security Agency (NSA), das Office of Management and Budget (OMB), die Cybersecurity & Infrastructure Security Agency (CISA) und den Director of National Intelligence (DNI), Standards und Best Practices zur Verbesserung der Sicherheit in der Software-Lieferkette zu entwickeln. Die Leitlinien umfassen:

• Kriterien zur Bewertung der Softwaresicherheit

• Kriterien zur Bewertung der Sicherheitspraktiken der Entwickler und Anbieter selbst

• Innovative Tools oder Methoden zum Nachweis der Einhaltung sicherer Vorgehensweisen

Bis Februar 2022 werden NIST und die anderen Behörden Leitlinien für Best Practices in der Software-Lieferkette veröffentlichen. Sehen Sie sich in der Zwischenzeit unsere Liste mit Best Practices für die Sicherheit der Lieferkette an, die Sie schon heute umsetzen können.

Wann sollten Sie eine Software Bill of Materials verwenden?

Für jede neue Version einer Softwarekomponente sollte eine neue SBOM erstellt werden. Ebenso sollte die SBOM bei jeder Änderung an einer Komponente entsprechend aktualisiert werden.

Die NTIA-Mindestanforderungen an eine SBOM umfassen folgende Angaben:

• Name des Autors

• Name des Anbieters

• Name der Komponente

• Hash der Komponente

• Versionszeichenfolge

• Kennung

• Beziehung

Um diese Mindestanforderungen zu erfüllen, wurden SBOM-Standards entwickelt, die ein gemeinsames, toolübergreifendes Format bieten. Diese Standards sind:

• SPDX: Software Product Data Exchange ist ein offener Standard zur Übermittlung von Informationen über Komponenten, Lizenzen und Sicherheit in Softwarepaketen. SPDX standardisiert mehrere Services, jeweils mit einer eigenen SBOM.

• SWID: Software Identification Tags sind Standards, die einen Lebenszyklus definieren. Die Tags werden während der Softwareinstallation zum Endpunkt hinzugefügt. Es gibt vier Arten: Corpus-Tags für die Phase vor der Installation; Primary-Tags, die den Produktnamen angeben und als global eindeutige Kennung gelten; Patch-Tags, die auf die angewendeten Software-Patches hinweisen; und Supplemental-Tags für zusätzliche Informationen.

• OWASP Cyclone DX: Ein schlanker SBOM-Standard zur Analyse von Lieferkettenkomponenten und für Application Security.

• VEX: Vulnerability Exploitability Exchange liefert zusätzliche Produktinformationen. Dazu gehören Angaben zu Schwachstellen in Komponenten sowie Empfehlungen zu deren Behebung.

SBOMs und die Integrität der Software

SBOMs dienen dazu, die Integrität der Software-Lieferkette zu bestimmen und auf Grundlage der erfassten Informationen Risiken zu bewerten. Auf hoher Ebene erfassen SBOMs die Softwarekomponenten in der Lieferkette. Die Anwendung der Standards stellt jedoch sicher, dass SBOMs die Compliance-Standards für OSS erfüllen. So identifiziert der SPDX-Standard beispielsweise die Lizenzen dieser Komponenten und dient dazu, die Einhaltung von Lizenzbedingungen sicherzustellen.

Supply Chain Levels for Software Artifacts (SLSA) ist eine Reihe von Standards und Kontrollen, die dazu beitragen soll, die Integrität von Open-Source-Softwareartefakten in der Lieferkette zu wahren. SLSA wurde von Google eingeführt und erfüllt die Empfehlungen von NIST zur Sicherheit der Lieferkette. SLSA ergänzt SBOMs beim Schutz der großen Menge an Open-Source-Software, die während des gesamten Entwicklungsprozesses zum Einsatz kommt.

Mit SBOMs Abhängigkeiten und Schwachstellen finden

Der wichtigste Sicherheitszweck von SBOMs ist es, Schwachstellen und Risiken in der gesamten Software-Lieferkette zu erkennen. Die Daten zu Schwachstellen ändern sich ständig, wenn Komponenten hinzugefügt oder geändert werden, und können so neue Exploits ermöglichen. SBOMs sind im Grunde statisch, während sich die Daten, auf denen sie basieren, laufend verändern und weiterentwickeln.

Eine SBOM ist ein Tool für Softwarekunden, mit dem sie Schwachstellen analysieren und überprüfen können, ob Entwickler Abhängigkeiten aktualisieren, um Risiken zu senken. Allerdings sind nicht alle Schwachstellen gleich riskant – manche stellen überhaupt kein Risiko dar. Um dieses Problem anzugehen, empfiehlt die NTIA zwei Schritte:

• Auf Entwicklungs- und Lieferantenseite muss ermittelt werden, welche Auswirkungen die Schwachstelle hat, insbesondere ob bestimmte Bereiche der Software betroffen sind.

• Informationen zur Schwachstelle müssen über SBOM-Daten klar kommuniziert werden. Dabei ist zu bestätigen, dass die Schwachstelle kein zusätzliches Risiko darstellt.

SBOMs für die Sicherheit der Lieferkette

SBOMs erhöhen die Sicherheit der Software-Lieferkette auf folgende Weise:

• Bessere Transparenz über das Softwareprodukt und die Beziehungen zwischen den Systemen

• Austausch von Informationen zu Schwachstellen

• Bessere Kommunikation entlang der Lieferkette – von Entwicklern bis zu Nutzern –, die das Erkennen von Sicherheitsrisiken erleichtert

• Detaillierte Aufzeichnungen zu Compliance-Standards und Audits

Die SBOM ist ein Sicherheits-Tool, das sich weiterentwickelt und besseren Schutz sowie eine bessere Risikoerkennung in der gesamten Software-Lieferkette bietet. Genauere und detailliertere Informationen zu jeder Softwarekomponente ermöglichen es, Schwachstellen früh im Softwareentwicklungszyklus zu entdecken und so Gegenmaßnahmen zu ergreifen, bevor Schaden entsteht.

Snyk kann die Erstellung einer SBOM automatisieren und Organisationen dabei helfen, die verwendeten Open-Source-Komponenten und Abhängigkeiten einfacher nachzuverfolgen. Snyk kann diese einzelnen Komponenten außerdem auf potenzielle Schwachstellen prüfen und konkrete Empfehlungen zu deren Behebung geben.