Da Bedrohungsakteure auf IT- Lieferketten abzielen, war eine verbesserte Cybersicherheit zuletzt der wichtigste Treiber für die Einführung des Software-Bill-of-Materials- (SBOM-)Frameworks in der Industrie.
Mit einer einfachen Liste der Komponenten, aus denen ein Softwareprodukt besteht, erhöhen SBOMs die Transparenz zwischen Käufern und Verkäufern von Software, schaffen die nötige Transparenz zur Identifizierung von Schwachstellen und ermöglichen eine schnelle Reaktion auf Vorfälle. SBOMs adressieren direkt Ineffizienzen im Softwareentwicklungsprozess, die zu einer Transparenzlücke zwischen Kunden führen, die auf die Funktionalität der Software angewiesen sind, und dem Wissen des Entwicklers oder Lieferanten über deren Erstellung und Quellkomponenten.
SBOMs schützen mit einem granularen Inventar der Softwarekomponenten auch vor Lizenz- und Compliancerisiken im Zusammenhang mit SLAs. Angesichts der potenziellen Wirksamkeit der Einführung von SBOMs gibt es keinen Nachteil darin, Praktiken der Software-Lieferkette zu standardisieren, wenn dadurch kritische IT-, Geschäfts- und Drittanbieterrisiken gemindert und das Geschäftsergebnis eines Unternehmens verbessert wird.
Dieser Artikel befasst sich mit Software-Bill-of-Materials, Dateidaten, bestehenden Standards, Vorteilen, Anwendungsfällen und der Bedeutung von SBOMs für die Cybersicherheit.
Direkt zu:
- Was ist ein Software Bill of Materials (SBOM)?
- Was enthält eine SBOM-Datei?
- Notwendigkeit der Standardisierung
- Der Vulnerability-Exploitability eXchange (VEX)
- Vorteile der Einführung von SBOMs
- So erstellen Sie eine SBOM
- Proof of Concept: SBOM im Gesundheitswesen
- Was SBOMs für die Cybersicherheit bedeuten
Was ist ein Software Bill of Materials (SBOM)?
Ein Software Bill of Materials (SBOM) ist ein maschinenlesbares Inventar der Komponenten, Abhängigkeiten, Metadaten und hierarchischen Beziehungen eines bestimmten Softwareprodukts. In einer Welt aus Open-Source- und proprietären Komponenten schaffen SBOMs Transparenz, indem sie risikobehaftete Elemente oder später als angreifbar eingestufte Komponenten identifizieren.
Beim SBOM-Framework geht es um die von Entwicklern und Lieferanten identifizierten Softwareeinheiten, die als Komponenten bezeichnet werden, sowie um die zugehörigen Daten, die als Attribute bezeichnet werden. Ein Softwareprodukt als Ganzes ist die primäre Komponente und enthält häufig mehrere vorgelagerte Komponenten; für jede davon enthält die SBOM einen Eintrag, sodass eine gemeinsame Datei entsteht.
Nährwertkennzeichnung für Softwarekäufer
Ähnlich wie beim Blick auf ein Nährwertetikett im Supermarkt können Unternehmen den Quellcode eines Produkts mithilfe von SBOMs bewerten, bevor sie es kaufen. Wenn der Arzt eines Kunden diesem später von einer neuen Allergie oder einem gesundheitlichen Problem berichtet, liegt es am Patienten, zurückzublicken und die betreffenden Lebensmittel wegzuwerfen.
Bei Softwarekomponenten werden ausnutzbare Schwachstellen regelmäßig identifiziert und müssen vorrangig behoben werden. Ohne ein Nährwertetikett-Pendant für eingesetzte Software wäre es für Unternehmen schwierig, verwundbare Systeme zu adressieren. Bedrohungsinformationen können IT-Umgebungen auf die neueste Malware untersuchen, sind aber nur eine Sicherheitsebene gegen Zero-Day-Bedrohungen.
Weiterlesen: Fehler in der Python-Paketverwaltung entdeckt
Das Problem mit Software-Lieferketten
Da jede Software Schwachstellen enthält, ist es für die Wahrung der Integrität von IT-Umgebungen zunehmend entscheidend, die Komponenten des gekauften, verwendeten oder entwickelten Codes zu verstehen.
Eine absolut risikofreie Strategie für das Softwaremanagement gibt es nicht; deshalb müssen Unternehmen nach einem risikobewussten Ansatz streben. Im neuen Jahrtausend bedeuten die zunehmende Verbreitung der agilen Programmiermethodik kürzere Entwicklungszyklen und häufigere Anwendungsbereitstellungen, was auch ein erhöhtes Risiko instabiler Releases mit sich bringt. Werden Open-Source- und proprietäre Softwarekomponenten in Lösungen kombiniert, ist die Software-Lieferkette verständlicherweise komplex.
Angesichts des enormen Entwicklungsvolumens müssen Unternehmen bei der Verwaltung von Risiken durch Drittanbieter offensiver vorgehen.
Anwendungsfälle für SBOMs
Die wichtigsten Anwendungsfälle für SBOMs sind ihr Einsatz im Management von Schwachstellen in der Lieferkette und in Prozessen zur Gewährleistung der Produktintegrität.
Schwachstellenmanagement
Da Schwachstellen existieren, entstehen und fortbestehen, müssen nachgelagerte Unternehmen die Risiken von Softwarelieferanten berücksichtigen. Das Komponentenverzeichnis von SBOMs erleichtert die Identifizierung bestimmter Schwachstellen erheblich. Mit der Einführung von VEX-Dateien können Unternehmen den Ausnutzbarkeitsstatus einer Schwachstelle präzise bestätigen und kritische Schwachstellen umgehend beheben.
Produktintegrität
Mehr Transparenz bedeutet besser informierte Käufer und Verkäufer sowie Produkte mit hoher Gewissheit über ihre Wirksamkeit. Die Gewährleistung der Herkunft und Integrität von Softwarekomponenten ist entscheidend für die Verbesserung des Cybersicherheitsökosystems. SBOMs verschaffen Unternehmen mehr Transparenz und Kontrolle bei der Softwarelizenzierung und der Nachverfolgung von Berechtigungen.
Außerdem lesen: So schützen Sie sich vor gängigen IT-Sicherheitslücken
Was enthält eine SBOM-Datei?
Obwohl einige Formate an Bedeutung gewinnen, gibt es keine allgemein akzeptierte SBOM-Struktur. Die National Telecommunication and Information Administration (NTIA) räumt ein, dass die derzeit vorgeschlagenen grundlegenden Komponentenattribute bewusst einfach gehalten sind und Raum für Weiterentwicklungen sowie branchenspezifische Anpassungen lassen. Die NTIA Software Component Transparency Framing Working Group erklärte:
“Dies ist einer der Hauptgründe dafür, eine derart grundlegende Informationsmenge als Ausgangspunkt festzulegen, anstatt zunächst einen umfangreicheren Attributsatz zu verlangen, dessen Erfassung und Pflege möglicherweise mehr Zeit und Ressourcen erfordern würde.“
Die vorgeschlagenen grundlegenden Komponentenattribute
| Name des Autors | Der Autor der SBOM (z. B. Entwickler, Lieferant, GRC, Drittanbieter) |
|---|---|
| Zeitstempel | Datum und Uhrzeit der erstmaligen Erstellung sowie der letzten Aktualisierung |
| Name des Lieferanten | Identifizierende Informationen zu den Entwicklern und Lieferanten einer Komponente |
| Komponentenname | Name der Komponente oder Liste mehrerer Komponentennamen |
| Versionszeichenfolge | Versionsinformationen der Komponente mit einem Versionsschema |
| Komponenten-Hash | Kryptografische Hashes oder digitale Signaturen der Komponentendaten |
| Eindeutige Kennung | Zusätzliche Daten zur Position der Komponente in der eindeutigen Hierarchie |
| Beziehung | Listet das Vorhandensein vor- oder nachgelagerter Abhängigkeiten auf |
Für manche Attributdaten sind möglicherweise mehrere Angaben erforderlich, etwa Lieferantennamen, während andere Felder vom Autor der SBOM aufgrund seiner eingeschränkten Sichtbarkeit möglicherweise nicht ausgefüllt werden können. Im letzteren Fall sollte der Autor angeben, ob die Felddaten unbekannt sind, nicht existieren, teilweise bekannt oder bekannt sind.
Weitere mögliche Attribute sind Nutzungsinformationen, Lizenzierung, End-of-Life-Daten, Hinweise von Drittanbietern, Komponentengruppen und die Auswirkungen von Komponenten auf nachgelagerte Systeme. In jedem Fall ist die kryptografische Authentifizierung von SBOMs unerlässlich, um ihre Authentizität zu überprüfen.
Die Bedeutung von Komponentenbeziehungen
Unabhängig davon, ob es sich um Open-Source-, proprietäre oder kombinierte Software handelt: Die Komponenten, die in heutige Software einfließen, und ihre Beziehungen wirken sich auf das Geschäftsergebnis von Unternehmen aus. Ausgehend von der primären Komponente können Entwickler und Lieferanten Beziehungen zu vorgelagerten Komponenten definieren, die sich auf die Historie der Produktlieferkette beziehen.
Außerdem lesen: Cyberangriffe durch mehrere Akteure führen zu hohen Verlusten
In der folgenden Grafik liefert die NTIA ein konzeptionelles Beispiel für die Darstellung von Beziehungen bei einer Softwareanwendung. In diesem Beispiel enthält die SBOM vier Komponenten: die primäre Komponente und drei vorgelagerte Komponenten. Auch wenn über diese vier hinaus weitere Komponenten existieren können, müssen sich SBOM-Autoren auf das vorhandene Wissen stützen. Wie im Flussdiagramm und in der Tabelle zu sehen ist, können SBOMs eine Momentaufnahme der Komponentendetails und ihrer Beziehungen in der Software-Lieferkette erfassen.
Notwendigkeit der Standardisierung
SBOMs müssen branchenweit akzeptierte Formate verwenden, die Interoperabilität zwischen verschiedenen Branchen und Unternehmen ermöglichen, damit ihre Einführung Realität wird. Da bereits einige Standards existieren, verfügen Unternehmen über ein Rahmenwerk, um Daten zu Softwarekomponenten schnell zu verfassen, zu pflegen und auszutauschen.
SPDX: Software Package Data Exchange
Software Package Data Exchange (SPDX), 2010 von der Linux Foundation entwickelt, ist der führende offene Standard für SBOM-Formate. SPDX-Dateien enthalten Softwarekomponenten, Urheberrechte, Lizenzen und Sicherheitsreferenzen.
Die SPDX-Spezifikation entspricht dem von der NTIA vorgeschlagenen Mindeststandard für eine SBOM sowie den Anwendungsfällen für Schwachstellenscans, Lizenz-Compliance und mehr. Mit SPDX Lite können Unternehmen eine kompakte Teilmenge des SPDX-Standards zum Datenaustausch nutzen. Im August 2021 wurde SPDX als ISO/IEC 5962 zu einem offiziellen Standard.
SWID: Software Identification Tagging
Gegen Ende der 2010er-Jahre begann die International Organizations for Standards (ISO) mit der Entwicklung eines Standards zur Kennzeichnung von Softwarekomponenten mit maschinenlesbaren IDs. Software Identification (SWID) Tags, wie sie heute genannt werden, sind strukturierte, eingebettete Metadaten in Software, die Produktname, Version, Entwickler, Beziehungen und mehr übermitteln.
Wie das Software Asset Management (SAM) können SWID Tags die Automatisierung von Patch-Management, der Validierung der Softwareintegrität, der Erkennung von Schwachstellen sowie der Freigabe oder Blockierung von Softwareinstallationen unterstützen. ISO/IEC 19770-2 wurde 2012 bestätigt und 2015 aktualisiert.
OWASP CycloneDX
Die OWASP Foundation entwickelte CycloneDX 2017 als Teil ihrer Open-Source-Lösung zur Analyse von Softwarekomponenten, Dependency-Track. Mit Anwendungsfällen wie der Identifizierung von Schwachstellen, der Lizenz-Compliance und der Analyse veralteter Komponenten ist CycloneDX ein schlanker Standard für den branchenübergreifenden Einsatz. Die vierte Version von CycloneDX (1.3) wurde im Mai 2021 veröffentlicht.
Weiterlesen: OWASP benennt erstmals seit Jahren eine neue Top-Schwachstelle
Der Vulnerability-Exploitability eXchange (VEX)
Der von der NTIA entwickelte Vulnerability-Exploitability eXchange (VEX) liefert eine Aussage über den Status bestimmter Schwachstellen in Softwareprodukten. Durch die Ausstellung eines VEX informieren Softwareanbieter Kunden über bestimmte Schwachstellen, die möglicherweise nicht ausnutzbar sind. Beispiele für verschiedene Status nicht ausnutzbarer Schwachstellen sind:
| Schwachstellenstatus | Beschreibung |
|---|---|
| Behoben | Die Produktversion behebt eine bestimmte Schwachstelle |
| Bekannt, betroffen | Maßnahmen zur Behebung dieser Schwachstelle erforderlich |
| Bekannt, nicht betroffen | Keine Maßnahmen erforderlich |
| Untersuchung läuft | Auswirkungen der Schwachstelle unbekannt; Schwachstelle wird noch bewertet |
Wie eine SBOM bietet auch das VEX-Format einen Rahmen für mehr Transparenz zwischen den Beteiligten an der Softwareentwicklung. Für Unternehmen ist VEX zudem maschinenlesbar und ermöglicht die massenhafte Erfassung und Automatisierung des Schwachstellenmanagements von Softwarekomponenten.
Vorteile der Einführung von SBOMs
Software Bill of Materials sind für jedes Unternehmen von Nutzen, dem die Verringerung zusätzlicher Risiken und bewährte Cybersicherheitspraktiken wichtig sind. Anbieter aus den Bereichen Schwachstellenmanagement, Drittanbieterrisikomanagement und Software Composition Analysis integrieren bereits SBOM-Dienste, um Unternehmen bei der Umstellung zu unterstützen.
- Informationsaustausch über Softwarekomponenten und Schwachstellen optimieren
- Eine Produkt-SBOM problemlos über gängige Datendateien (JSON, XML, HTML, PDF oder TXT) teilen
- Die Integrität der Lieferkette durch besser informierte Entwickler, Anbieter und Kunden stärken
- Die zügige Einführung und Rücknahme wichtiger Patches und Maßnahmen zur Behebung von Problemen ermöglichen
- Verbesserte Dokumentation für Softwareprüfungen und regulatorische Compliance-Standards
- Verbesserte Transparenz über eingesetzte Software, Komponenten und Systembeziehungen
So erstellen Sie eine SBOM
Software Bill of Materials sollten als lebende Dokumente geführt und aktualisiert werden, um eine möglichst präzise Transparenz über die jeweils verwendeten Quellcodekomponenten zu gewährleisten. Für die Verwaltung von SBOMs müssen Unternehmen zunächst relevante Elemente ihres Softwarebestands wie unsichere Informationen, Schwachstellen, Lizenzen und Versionen identifizieren.
- Komponentendaten erfassen, Attributdaten auflisten und die SBOM erstellen
- Erste Überarbeitungen abschließen, bevor die primäre Komponentendatei erstellt wird
- Die Datei prüfen und zur Weitergabe an Beteiligte und potenzielle Kunden finalisieren
- Die Integrität der Datei überwachen, festgestellte Änderungen beheben und die Datei aktualisieren
Obwohl US-Bundesauftragnehmer als Erste zur Erstellung von SBOMs verpflichtet sein werden, verfolgen Befürworter eine globale Vision, sie in den Softwareentwicklungsprozess einzubeziehen. Mit zunehmender Verbreitung der bestehenden Standards wird es zur bewährten Praxis werden, für jede neue Softwarekomponente eine zugehörige SBOM zu erstellen. Das Ergebnis wird ein robusteres, auf Transparenz basierendes Ökosystem sein.
Weiterlesen: Angreifer nutzen Schwachstelle aus, die Millionen Router und IoT-Geräte betreffen könnte
Proof of Concept: SBOM im Gesundheitswesen
Im Oktober 2019 veröffentlichte die NTIA Phase I ihrer Initiative zur Entwicklung eines SBOM-Proof-of-Concept für mehr Transparenz bei Softwarekomponenten. Hersteller medizinischer Geräte (MDM), die SBOMs für Gesundheitseinrichtungen (HDO) erstellen, trieben die Initiative maßgeblich voran; das Ergebnis bildete eine Grundlage für die weitere Entwicklung.
Zwei Jahre später schloss die NTIA die Phase II. In den Anfang dieses Monats veröffentlichten Ergebnissen validierte Phase II die akzeptierten Basiselemente und SPDX, listete Standardsoftwarekomponenten sowie einen How-to-Leitfaden für Produzenten auf und untersuchte VEX-Anwendungsfälle. Zu den Zielen von Phase III gehören die Förderung der Einführung im gesamten Gesundheitssektor, die Automatisierung des SBOM-Austauschs sowie die Behebung von Ineffizienzen bei Produkten und Dienstleistungen am Ende ihrer Lebensdauer.
Was SBOMs für die Cybersicherheit bedeuten
Von den Zielen der Informationssicherheit – Vertraulichkeit, Integrität und Verfügbarkeit – adressieren Software Bill of Materials am besten die Wahrung der Integrität von Unternehmensdaten und -systemen. Als formales Dokument über eingesetzte oder in Entwicklung befindliche Software können die Dateien zu Softwarekomponenten zusätzliche Risiken für den Schutz von Geschäftsgeheimnissen darstellen. Ebenso wirkt sich eine SBOM nicht direkt auf die Verfügbarkeit von Daten aus.
SBOMs schaffen einen branchenweiten Präzedenzfall, der die Transparenz zwischen Entwicklern, Softwareanbietern und Kunden erhöht. Mit etablierten Standards können Unternehmen Partner während des Vertragsabschlusses sicher über Details des Quellcodes informieren. Mit der zunehmenden Verbreitung von SBOMs werden Unternehmen besser in der Lage sein, Fehler, Schwachstellen und Zero-Day-Bedrohungen zu identifizieren. Für Cybersicherheitsexperten weltweit ist die Einführung von SBOMs eindeutig ein Gewinn.
Außerdem lesen: Kaseya-Angriff unterstreicht Schwachstelle bei Managed IT