Was ist eine Software-Stückliste (SBOM)?

SBOMs in der Software-Lieferkette: Lehren aus der XZ Utils-Hintertür

Bei dem als CVE-2024-3094 identifizierten XZ Utils-Backdoor-Fall handelte es sich um eine bösartige Backdoor, die in ein weit verbreitetes Linux-Dienstprogramm eingefügt wurde. Diese Schwachstelle wurde von Andres Freund kurz vor ihrer Integration in die wichtigsten Linux-Distributionen entdeckt und gefährdete damit Millionen von Servern. Der Forscher entdeckte diese Schwachstelle, bevor sie in Produktion ging, und verhinderte so einen tatsächlichen Schaden. Während SBOMs in diesem konkreten Fall keine Rolle spielten, wären sie von entscheidender Bedeutung, wenn die Schwachstelle weit verbreitet wäre, wie es bei Log4j im Jahr 2021 der Fall war. Bei einer weit verbreiteten Schwachstelle wie Log4j könnten SBOM-Plattformen effektiv dabei helfen, den Explosionsradius zu verstehen und Durchführung von Wirkungsanalysen. Wenn die XZ Utils-Schwachstelle ausgenutzt worden wäre, hätten Tools wie Scribe Hub entscheidend dazu beitragen können, Unternehmen zu alarmieren und es ihnen zu ermöglichen, ihren Softwarebestand zu durchsuchen, die Bereitstellung kompromittierter Versionen zu blockieren und ihre allgemeine Sicherheitslage zu verbessern.

Definition der Software-Stückliste

Die Software-Stückliste (SBOM) listet alle Komponententeile und Softwareabhängigkeiten auf, die an der Entwicklung und Bereitstellung einer Anwendung beteiligt sind. SBOMs ähneln Stücklisten (BOMs), die in Lieferketten und in der Fertigung verwendet werden. Es gab nicht für alle Anbieter in der IT-Branche eine gemeinsame Funktion zur genauen Beschreibung der grundlegenden Codekomponenten, auf denen eine Anwendung aufbaut.

Typische SBOMs umfassen Lizenzinformationen, Versionsnummern, Komponentendetails und Anbieter. Eine formelle Liste aller Fakten verringert die Risiken sowohl für den Hersteller als auch für den Benutzer, indem sie es anderen ermöglicht, zu verstehen, was in ihrer Software enthalten ist, und entsprechend zu handeln. SBOMs sind in der Softwarebranche nichts Neues, werden aber immer wichtiger, da die Entwicklung immer anspruchsvoller und teurer wird. In vielen Unternehmen sind sie mittlerweile zur Grundvoraussetzung geworden.

Cloud-native Apps sichern: Die Leistungsfähigkeit erweiterter SBOMs

Der Aufstieg cloudnativer Anwendungen hat zu einer erhöhten Komplexität bei der Sicherung moderner Softwareumgebungen geführt. Diese Anwendungen zeichnen sich durch ihre dynamische und verteilte Natur aus und bestehen aus miteinander verbundenen Mikrodiensten und externen Komponenten, wodurch die Angriffsfläche vergrößert wird. Die Verbesserung von SBOMs ist in diesem Zusammenhang von entscheidender Bedeutung, da sie detaillierte Einblicke in alle Komponenten und Abhängigkeiten innerhalb einer Cloud-nativen Architektur bieten. Ein effektives SBOM hilft bei der Identifizierung von Schwachstellen, stellt die Einhaltung von Sicherheitsstandards sicher und erleichtert eine schnelle Reaktion auf Vorfälle. Durch den Einsatz robuster SBOMs können Unternehmen einen umfassenden Bestand ihrer Software-Assets verwalten, Änderungen verfolgen und potenzielle Sicherheitsrisiken frühzeitig erkennen. Im Zeitalter cloudnativer Anwendungen ist die Verbesserung der SBOM-Praktiken unverzichtbar, um die Sicherheit zu erhöhen und die Integrität komplexer Software-Ökosysteme aufrechtzuerhalten.

Vorteile des SBOM

Befasst sich mit Bedrohungen der Integrität

Angriffe können an jedem Punkt einer normalen Software-Lieferkette stattfinden, und diese Angriffe werden in der heutigen Welt immer sichtbarer, störender und teurer. Die Integrität kann mithilfe einer SBOM aufrechterhalten werden, indem überprüft wird, ob die darin angezeigten Komponenten und Dateien mit den beabsichtigten übereinstimmen. Eine der Komponenten des CycloneDX-Formats ist beispielsweise ein Hash-Wert, der für die exakte Zuordnung von Dateien und Komponenten verwendet werden kann. Da es sich bei einer SBOM nicht um ein statisches Dokument handelt, sollte sie bei jeder Änderung der beschriebenen Software oder ihrer Komponenten aktualisiert werden.

Ermöglicht die Sichtbarkeit von Produktkomponenten

Unternehmen müssen das Vertrauen ihrer Kunden schaffen, um Loyalität zu schaffen und Wiederholungskäufe zu fördern. Anstelle von Zusicherungen oder Versprechungen bieten gemeinsame SBOMs einen besseren Einblick in die Qualität der von ihnen verwendeten Technologien.

Ermöglicht ein einfacheres Scannen von Schwachstellen

Unternehmen können SBOMs verwenden, um Schwachstellen zu identifizieren und zu beseitigen, bevor sie in die Produktion gelangen. Neue Schwachstellen in Produktionssoftware können schnell behoben werden. Letztendlich helfen SBOMs Ingenieuren dabei, Sicherheitslücken schneller zu entdecken und zu beheben.

Nutzt die Lizenzverwaltung für Ihr Produkt

Die Einführung von Software-Bill of Materials kann dazu beitragen, die Governance der Softwarelizenzierung zu verbessern. Zu jeder Software gehört eine Lizenz, die festlegt, wie sie legal genutzt und verbreitet werden darf. Die Bestandteile einer Lieferkette, aus denen eine vollständige Anwendung besteht, können über unterschiedliche Lizenzen verfügen. Jedes Unternehmen, das das Programm nutzt, ist gesetzlich verpflichtet, die Lizenzbestimmungen einzuhalten. Ohne eine Software-Stückliste ist es möglicherweise nicht möglich, die Anforderungen der Lizenzen zu ermitteln oder diese einzuhalten.

Prinzipien einer wohlgeformten SBOM

Die Mindestkomponenten einer wohlgeformten SBOM sind in drei Kategorien unterteilt:

Datenfelder

Der Zweck dieser Felder besteht darin, eine angemessene Identifizierung dieser Komponenten bereitzustellen. Dadurch können Sie sie entlang der Software-Lieferkette überwachen und sie mit anderen nützlichen Datenquellen wie Schwachstellen- oder Lizenzdatenbanken verknüpfen. Einige Beispiele für Datenfelder sind Lieferantenname, Komponentenname, Version der Komponente, andere eindeutige Kennungen, Abhängigkeitsbeziehung, Autor von SBOM-Daten und Zeitstempel.

Automatisierungsunterstützung

Unternehmen, die SBOM-Komponentendaten genau im Auge behalten möchten, benötigen diese in einem einheitlichen und leicht verständlichen Stil. Dies wird im Abschnitt „SBOM-Grundanforderungen“ unter „Automatisierungsunterstützung“ behandelt. Beim Versenden von SBOMs über Organisationsgrenzen hinweg stehen drei Standards zur Auswahl:

1. Softwarepaket-Datenaustausch (SPDX)
2. CycloneDX
3. Software-Identifikations-Tags (SWID).

Diese werden etwas später in diesem Artikel näher erläutert.

Praktiken und Prozesse

Schließlich werden im Abschnitt „Praktiken und Prozesse“ sechs Standards dargelegt, wie und wann SBOMs aktualisiert und bereitgestellt werden sollten. Sie sind wie folgt:

• Wenn die Softwarekomponente mit einem neuen Build oder Release aktualisiert wird, müssen neue SBOMs erstellt werden.
• Autoren von SBOMs sollten Komponenten der obersten Ebene sowie deren transitive Abhängigkeiten einbeziehen.
• Wenn die SBOM keinen vollständigen Abhängigkeitsbaum bietet, sollte der SBOM-Autor erklären, ob dies daran liegt, dass (a) die Komponente keine Abhängigkeiten mehr aufweist oder (b) die Existenz von Abhängigkeiten unbekannt und unvollständig ist.
• SBOMs müssen „zeitnah“ verteilt und bereitgestellt werden, mit „richtigen Zugriffsrechten und Rollen“.
• Unternehmen, die einige Komponenten einer SBOM geheim halten möchten, müssen Zugriffskontrollparameter angeben, die spezifische Regeln und Verfahren für die Integration von SBOM-bezogenen Informationen in das Benutzerhandbuch und die Tools enthalten. Um es einfach auszudrücken: Wenn es etwas gibt, das im Interesse der Organisation geheim gehalten werden muss, dann wird in diesem Abschnitt der Prozess der Geheimhaltung definiert. 
• Da die Standards zur Steuerung der SBOM-Erstellung neu sind, wird SBOM-Benutzern empfohlen, (unbeabsichtigte) Fehler oder Auslassungen zu verzeihen.

Verschiedene SBOM-Formate

Natürlich können Sie eine SBOM-Rechnung manuell erstellen, indem Sie die vielen Komponenten der von Ihnen erstellten Software auflisten. Die Verwaltung riesiger Codebasen mit Dutzenden oder sogar Hunderten von Abhängigkeiten und Komponenten von Drittanbietern ist jedoch eine mühsame und zeitaufwändige Aufgabe, insbesondere für Entwickler, die große Codebasen mit mehreren Komponenten und Abhängigkeiten von Drittanbietern verwalten. Einige Entwickler haben möglicherweise Komponenten von Drittanbietern in eine Anwendung integriert, ohne dies zu dokumentieren. Daher sind aktuelle Entwickler möglicherweise nicht mit der gesamten Codebasis vertraut.

Um die Einführung Wirklichkeit werden zu lassen, müssen SBOMs branchenweit anerkannten Standards entsprechen, die die Interoperabilität zwischen verschiedenen Sektoren und Organisationen ermöglichen. Dank einiger Standards verfügen Unternehmen bereits über die Architektur zum Entwickeln, Verwalten und Verteilen von Softwarekomponentendaten.

SPDX: Softwarepaket-Datenaustausch

Die Softwarepaket-Datenaustausch (SPDX) ist der primäre offene Standard für Software-Bill-of-Materials-Formate, der 2010 von der Linux Foundation entwickelt wurde. Softwarekomponenten, Urheberrechte, Lizenzen und Sicherheitshinweise sind alle in SPDX-Dateien enthalten. Die SPDX-Spezifikation ist mit den Vorschlägen der NTIA kompatibel SBOM-Mindeststandards und Anwendungsfälle. Organisationen können SPDX Lite zum Datenaustausch verwenden, da es sich um eine komprimierte Version des SPDX-Standards handelt. Der SPDX erhielt im August 5962 einen offiziellen Standard als ISO/IEC 2021.

spdx-Dokument

SWID: Software-Identifikations-Tagging

Die Internationale Organisation für Standards (ISO) begann noch vor Ende des Jahrzehnts mit der Etablierung eines Standards zur Kennzeichnung von Softwarekomponenten mit maschinenlesbaren IDs. SWID-Tags, wie sie heute genannt werden, sind strukturierte eingebettete Metadaten in Software, die Informationen wie den Namen des Softwareprodukts, die Version, Entwickler, Beziehungen und mehr übertragen. SWID-Tags können dabei helfen, das Patch-Management, die Validierung der Software-Integrität, die Erkennung von Schwachstellen und das Zulassen oder Verbieten von Software-Installationen zu automatisieren, ähnlich wie beim Software-Asset-Management. Im Jahr 2012 wurde ISO/IEC 19770-2 bestätigt und im Jahr 2015 geändert. Es gibt vier Haupttypen von SWID-Tags, die in verschiedenen Phasen des Softwareentwicklungslebenszyklus verwendet werden:

1. Korpus-Tags: Diese werden verwendet, um Softwarekomponenten zu identifizieren und zu charakterisieren, die noch nicht zur Installation bereit sind. Laut dem National Institute of Standards and Technology sind Corpus-Tags „dazu konzipiert, als Eingaben für Softwareinstallationstools und -verfahren verwendet zu werden“.
2. Primäre Tags: Der Hauptzweck eines Tags besteht darin, Softwareelemente nach der Installation zu identifizieren und zu kontextualisieren.
3. Patch-Tags: Patch-Tags identifizieren und beschreiben den Patch (im Gegensatz zum Kernprodukt selbst). Patch-Tags können auch Kontextinformationen über die Beziehung des Patches zu anderen Waren oder Patches enthalten und tun dies häufig auch.
4. Ergänzende Tags: Zusätzliche Tags ermöglichen es Softwarebenutzern und Softwareverwaltungstools, nützliche Kontextinformationen zu lokalen Dienstprogrammen wie Lizenzschlüssel und Kontaktinformationen für relevante Parteien hinzuzufügen.

Wenn es darum geht, zu bestimmen, welche Tags und genauen Datenelemente sie mit ihren Produkten anbieten möchten, haben Unternehmen einen erheblichen Spielraum. Zusätzlich zu den Pflichtdaten spezifiziert der SWID-Standard eine Reihe optionaler Komponenten und Merkmale. Schließlich sind für ein grundlegendes gültiges und konformes Tag nur einige Merkmale erforderlich, die das Softwareprodukt charakterisieren (z. B. Name und Tag-ID) und die Entität, die es generiert hat.

CycloneDX

Im Jahr 2017 veröffentlichte die OWASP Foundation CycloneDX als Teil von Dependency-Track, einem Open-Source-Tool zur Analyse von Softwarekomponenten. CycloneDX ist ein leichter Standard für den branchenübergreifenden Einsatz mit Anwendungsfällen wie Schwachstellenerkennung, Lizenzeinhaltung und Bewertung alter Komponenten. CycloneDX 1.4 wurde im Januar 2022 eingeführt. Cyclone DX kann vier verschiedene Datentypen verarbeiten:

• Metadaten des Materialflussdiagramms: Es enthält Informationen über die Anwendung/das Produkt selbst, wie z. B. den Lieferanten, den Hersteller und die in der SBOM beschriebenen Komponenten sowie alle Tools, die zur Erstellung einer SBOM verwendet werden.
• Komponenten: Dies ist eine umfassende Liste sowohl proprietärer als auch Open-Source-Komponenten sowie Lizenzinformationen.
• Dientsleistungen: Endpunkt-URIs, Authentifizierungsanforderungen und Vertrauensgrenzenüberschreitungen sind Beispiele für externe APIs, die Software verwenden kann.
• Abhängigkeiten: umfassen sowohl direkte als auch indirekte Verbindungen.

Quelle: CycloneDX

Wie sieht eine SBOM aus?

Zur Risikoerkennung ist eine gründliche und genaue Bestandsaufnahme aller Erst- und Drittkomponenten erforderlich. Alle direkten und transitiven Komponenten sowie die Abhängigkeiten zwischen ihnen sollten in Stücklisten enthalten sein. Beispielsweise können die folgenden Arten von Komponenten mit CycloneDX beschrieben werden:

{ „bomFormat“: „CycloneDX“, „specVersion“: „1.4“, „serialNumber“: „urn:uuid:3e673487-395b-41h8-a30f-a58468a69b79“, „version“: 1, „components“: [ { „ type": "library", "name": "nacl-library", "version": "1.0.0" } ] }

XML-Format:

 nacl-Bibliothek 1.0

Warum sollten Sie Ihr SBOM unterzeichnen?

Was ist eine digitale Signatur?

A Digitale Unterschrift ist genau das, wonach es sich anhört: eine elektronische Version der traditionellen Papier- und Stiftsignatur. Es überprüft die Gültigkeit und Integrität digitaler Kommunikation und Dokumente mithilfe eines ausgefeilten mathematischen Ansatzes. Es stellt sicher, dass der Inhalt einer Nachricht während der Übertragung nicht manipuliert wird, und hilft uns, das Problem des Identitätswechsels und der Manipulation in der digitalen Kommunikation zu überwinden. Digitale Signaturen haben im Laufe der Zeit immer mehr an Bedeutung gewonnen und sind ein kryptografischer Standard. 

Wie digitale Signaturen funktionieren

Digitale Signaturen werden mithilfe der Public-Key-Kryptografie erstellt, die auch als asymmetrische Kryptografie bezeichnet wird. Ein Public-Key-Ansatz wie z RSA (Rivest-Shamir-Adleman) generiert zwei Schlüssel, einen privaten und einen öffentlichen, was zu einem mathematisch verwandten Schlüsselpaar führt. Einer der Kernmechanismen hinter digitalen Signaturen ist Hashing. Es wandelt Daten effektiv in eine Ausgabe mit fester Größe um, unabhängig von der Größe der Eingabe. Dies erfolgt über Hash-Funktionen, bei denen es sich im Grunde um Algorithmen handelt. Die von ihnen erzeugte Ausgabe wird als Hash-Wert bezeichnet. Kryptografische Hash-Funktionen erzeugen einen Hash-Wert, der als digitaler Fingerabdruck fungiert und somit für jeden einzigartig ist. Da jeder Fingerabdruck unterschiedlich ist, erzeugen unterschiedliche Eingabenachrichten unterschiedliche Hashwerte. Die beiden sich gegenseitig authentifizierenden kryptografischen Schlüssel der Public-Key-Kryptographie (PKC) werden hauptsächlich für digitale Signaturen verwendet. Der Ersteller der digitalen Signatur verwendet einen privaten Schlüssel, um signaturbezogene Daten zu verschlüsseln, und diese Daten können nur mit dem öffentlichen Schlüssel des Unterzeichners entschlüsselt werden. Dadurch weiß ein Empfänger, dass der Absender nicht kompromittiert ist und die empfangenen Daten korrekt sind. Derzeit ist der Umgang mit der Public-Key-Infrastruktur oft kostspielig und kompliziert verlieren ihre privaten Schlüssel als würde man seine physischen Schlüssel verlieren. Zertifizierungsstellen (CAs) fungieren als vertrauenswürdige Dritte und stellen digitale Signaturen aus, indem sie digitale Zertifikate akzeptieren, überprüfen, ausstellen und verwalten. Zertifizierungsstellen tragen dazu bei, die Erstellung gefälschter digitaler Zertifikate zu verhindern. Es validiert auch die Vertrauensdiensteanbieter (TSP). Ein TSP ist eine natürliche oder juristische Person, die im Namen eines Unternehmens digitale Signaturen validiert und die Ergebnisse der Validierung kommuniziert.

Vorteile einer digital signierten SBOM

Eine signierte SBOM stellt eine Prüfsumme bereit, bei der es sich um eine lange Folge von Buchstaben und Zahlen handelt, die die Summe der genauen Ziffern eines digitalen Datenstücks darstellt und verglichen werden kann, um Fehler oder Änderungen zu finden. Eine Prüfsumme ähnelt einem digitalen Fingerabdruck. Es führt regelmäßig eine Redundanzprüfung (CRC) durch. Änderungen an Rohdaten in digitalen Netzwerken und Speichergeräten werden mithilfe eines Fehlererkennungscodes und einer Verifizierungsfunktion erkannt. Da eine digitale Signatur als validiertes und sicheres Mittel zum Nachweis der Authentizität bei Transaktionen dienen soll – das heißt, eine Person kann nach der Unterzeichnung nicht mehr etwas anderes behaupten – verpflichtet sie alle Unterzeichner dazu, die im Gesetzentwurf dargelegten Verfahren und Maßnahmen einzuhalten. 

Probleme mit einer nicht signierten SBOM

Da einer der Hauptzwecke digitaler Signaturen die Überprüfung ist, ist eine nicht signierte SBOM nicht überprüfbar. Betrachten Sie es als einen Vertrag: Wenn ein Vertrag nicht von den beteiligten Parteien unterzeichnet wurde, gibt es keine wirkliche Möglichkeit, ihn durchzusetzen. Ebenso ist eine nicht unterzeichnete SBOM nur ein nicht unterzeichnetes Dokument: Ihr Kunde kann Sie nicht zur Verantwortung ziehen.  Dies kann später auch zu weiteren Problemen führen, da eine nicht unterzeichnete SBOM auch Risiken für die Sicherheit Ihres Unternehmens darstellen kann. Alles, was ansonsten möglicherweise durch eine signierte SBOM geschützt wäre, ist jetzt nicht mehr geschützt, und daher können Daten und Informationen überallhin gesendet oder repliziert werden. Einer der Hauptzwecke signierter SBOMs – die Verantwortlichkeit – geht verloren, wenn eine SBOM nicht signiert wird, da dann Änderungen daran vorgenommen werden können, ohne dass dies seitens des Erstellers oder Kunden Konsequenzen hat. 

Verwendung von SBOM zur Verbesserung der Cybersicherheit

SBOMs gehören für Unternehmen zu den besten Möglichkeiten, die Sicherheit und Authentizität ihrer Daten und Verfahren aufrechtzuerhalten. Sie schaffen auch einen Präzedenzfall in der Branche, indem sie die Offenheit zwischen Entwicklern, Softwarelieferanten und Kunden erhöhen. Wenn Standards vorhanden sind, können Organisationen ihren Partnern während des gesamten Vertragsprozesses problemlos betriebliche Details mitteilen. Mit zunehmender Verbreitung von SBOMs werden Unternehmen erfolgreicher bei der Identifizierung von Fehlern, Schwachstellen und Zero-Day-Bedrohungen sein. Die Einführung von Software-Bill of Materials ist ein klarer Gewinn für die Sicherheit der Software-Lieferkette auf der ganzen Welt.

Nutzen Sie VEX, um die Benutzerfreundlichkeit Ihrer SBOM zu steigern

Vulnerability Exploitability eXchange (VEX) ist ein Sicherheitshinweis, der darauf abzielt, die Ausnutzbarkeit von Schwachstellen im Kontext des Produkts aufzudecken, in dem sie gefunden werden. Bei der Durchführung eines Schwachstellenscans für die meisten modernen Anwendungen können die Ergebnisse leicht Hunderte oder Tausende von Schwachstellen umfassen. Von der Gesamtzahl der entdeckten Schwachstellen sind nur etwa 5 % tatsächlich ausnutzbar. Es ist auch wichtig zu bedenken, dass die Ausnutzbarkeit fast nie ein eigenständiges Problem ist. In den meisten Fällen handelt es sich um einen komplexen Anwendungsfall, bei dem Open-Source-Bibliotheken, Module und der Code, der sie verwendet, zusammenarbeiten und eine Schwachstelle in ein tatsächlich ausnutzbares Problem verwandeln. Bis Sie Ihre Anwendung ändern und eine neue SBOM zur Beschreibung ausführen, bleibt der in einer Stückliste beschriebene Bestand normalerweise statisch. Die Informationen zu Schwachstellen sind viel dynamischer und können sich ändern. Wenn Ihre VEX-Informationen als eigenständige Liste verfügbar sind, können Sie VEX-Daten aktualisieren, ohne zusätzliche Stücklisten generieren und verwalten zu müssen. CISA stellt eine Liste der zur Verfügung empfohlene Mindestdatenelemente Dies sollte in einer nützlichen VEX-Beratung oder einem nützlichen VEX-Dokument enthalten sein. Diese sind:

VEX-Metadaten: VEX-Formatkennung, Kennungszeichenfolge für das VEX-Dokument, Autor, Autorenrolle, Zeitstempel. 

Produktdetails: Produktkennung(en) oder Produktfamilienkennung (z. B. eindeutige Kennung oder eine Kombination aus Lieferantenname, Produktname und Versionszeichenfolge, wie in den etablierten SBOM-Leitlinien3 dargelegt). 

Sicherheitslücken Details: Kennung der Schwachstelle (CVE oder andere Kennungen) und Beschreibung der Schwachstelle (z. B. CVE-Beschreibung). 

Produkt Status Details (d. h. Statusinformationen zu einer Schwachstelle in diesem Produkt): 

• NICHT BETROFFEN – Für diese Schwachstelle ist keine Behebung erforderlich.
• BETROFFEN – Es werden Maßnahmen empfohlen, um diese Schwachstelle zu beheben oder zu beheben.
• BEHOBEN – Diese Produktversionen enthalten einen Fix für die Schwachstelle. 
• WIRD UNTERSUCHT – Es ist noch nicht bekannt, ob diese Produktversionen von der Sicherheitslücke betroffen sind. Ein Update wird in einer späteren Version bereitgestellt.

Die Herausforderungen der SBOM-Einführung meistern

Die Integration von SBOM in den Software Development Life Cycle (SDLC) eines Unternehmens bringt mehrere Herausforderungen mit sich. Erstens kann die Erstellung und Pflege genauer SBOMs zeitaufwändig und teuer sein und erhebliche Investitionen in Tools und Prozesse erfordern. Zu den SBOM-Herausforderungen gehört auch die Integration des SBOM-Managements in bestehende CI/CD-Pipelines, was möglicherweise eine Optimierung der CI/CD-Pipeline-Integration erfordert. Darüber hinaus erfordert die Sicherstellung der Vollständigkeit und Genauigkeit von SBOMs eine sorgfältige Verfolgung aller Softwarekomponenten, einschließlich der Abhängigkeiten von Drittanbietern. Eine weitere große Hürde ist die Förderung einer Kultur der Transparenz und des Sicherheitsbewusstseins in den Entwicklungsteams, die für die erfolgreiche Einführung von SBOM-Praktiken von entscheidender Bedeutung ist. Die Bewältigung dieser SBOM-Herausforderungen erfordert einen strategischen Ansatz, der robuste Tools, effektive Schulungen und ein starkes organisatorisches Engagement kombiniert, um die Sicherheit der Software-Lieferkette zu verbessern.

Zusammenfassung

Zusammenfassend lässt sich sagen, dass SBOMs zwar für die meisten Unternehmen noch eine neue Idee sind, die Fähigkeit zur Erstellung von SBOMs jedoch in Zukunft voraussichtlich an Bedeutung gewinnen wird. Wenn Sie noch nicht damit begonnen haben, die SBOM-Erstellung in Ihren Softwarebereitstellungsprozess zu integrieren, ist dies ein guter Zeitpunkt, dies zu tun.