Vor etwa einem Jahr, im Jahr 2023, veröffentlichte die Security and Exchange Commission eine Pressemitteilung über eine Klage gegen ein Softwareunternehmen mit Sitz in Austin, Texas. Die Klage spiegelte eine Sorge wider, die Softwareunternehmen auf der ganzen Welt beschäftigt: die Sicherheit der Software-Lieferkette. Cyber-Bedrohungsakteure haben es seit einiger Zeit auf Software-Lieferketten abgesehen und nutzen Schwachstellen wie die im Log4j-Framework, um Malware zu installieren.
Diese wachsende Sorge um die Sicherheit der Lieferkette ist ein wichtiger Grund dafür, dass die Software Bill Of Materials (SBOM) Eingang in die offiziellen Verwaltungsvorschriften für Cybersicherheit findet. Software-Lieferketten sind oft kompliziert und umfassen mehrere Prozesse. SBOM trägt zur Transparenz der Lieferketten bei, indem es die verschiedenen Komponenten und Abhängigkeiten auflistet, mit denen diese Prozesse direkt in Verbindung stehen. Um ein effizientes Risikomanagement für Software-Lieferketten zu entwickeln, müssen wir daher SBOM und seinen Umfang verstehen.
Einführung in SBOM (Software Bill of Materials)
Eine Software Bill Of Materials (SBOM) ist eine detaillierte Liste der verschiedenen Bestandteile einer Software, einschließlich ihrer Open-Source-Komponenten, Bibliotheken und deren Beziehungen untereinander. Die Idee dahinter ist, den Beteiligten ein umfassendes Verständnis aller Aspekte der Software zu vermitteln und so für Transparenz im Bereich der Cybersicherheit zu sorgen. Mit den Veränderungen in der Art und Weise, wie Software entwickelt und bereitgestellt wird, sind Komplexitäten entstanden, die es Cyberangreifern ermöglichen, kreative Vorgehensweisen zu entwickeln. SBOM ist daher ein unverzichtbares Sicherheitsnetz, das einen Einblick in unsere Anwendungen ermöglicht.
Warum ist SBOM für die Cybersicherheit so wichtig?
Als Präsident Biden in seiner Verordnung zur Verbesserung der Cybersicherheit SBOM hervorhob, tat er dies in Kenntnis der Schwachstellen in der Lieferkette, auf die böswillige Kampagnen abzielen. Eine verschachtelte Liste wie SBOM zerlegt die Software im Wesentlichen in ihre Bestandteile und hilft, diese Schwachstellen zu identifizieren. Hier sind drei Gründe, warum SBOM für die Cybersicherheit unverzichtbar ist:
- Transparenz in der Software: SBOM hilft den Beteiligten zu erkennen, ob die Software veraltete oder risikobehaftete Komponenten enthält. Wenn beispielsweise eine veraltete Verschlüsselungsbibliothek oder ein Logging-Framework wie Log4j vorhanden ist, können die Sicherheitsexperten das damit verbundene Risiko leicht identifizieren.
- Verfolgung von Open-Source-Komponenten: Viele moderne Softwarelösungen fördern die Integration von Open-Source-Komponenten und -Bibliotheken. Diese werden möglicherweise nicht immer auf ihre Sicherheit überprüft, daher hilft SBOM dabei, sie auf potenzielle Risiken zu überprüfen.
- Abhängigkeitsbewertung: Auch wenn einige Komponenten auf den ersten Blick keine Cybersicherheitsbedrohung darstellen, kann ihre Abhängigkeit von anderen Komponenten oder Bibliotheken dies jedoch tun. Daher hilft SBOM Sicherheitsexperten auch dabei, diese Abhängigkeiten zu untersuchen und etwaige Sicherheitslücken zu identifizieren.
- Sicherheit der Lieferkette: Transparenz innerhalb der Lieferkette hinsichtlich der Sicherheitslage verschiedener Softwarekomponenten trägt dazu bei, proaktive Sicherheitsstrategien gegen potenzielle Ausnutzung zu gewährleisten. SBOM bietet den Käufern alle notwendigen Informationen, die diese Strategien für die Sicherheit der Lieferkette ermöglichen.
- Compliance-Management: SBOM hilft den Stakeholdern auch dabei, die Softwarelösungen und ihre Komponenten auf die Einhaltung gesetzlicher Vorschriften zu überprüfen. Angesichts strenger Vorschriften in verschiedenen Branchen, darunter Gesundheitswesen, Fintech, Verteidigung und anderen, kann die Nichteinhaltung von Vorschriften durch eine Softwarekomponente leicht erkannt werden.
Wichtige Komponenten einer SBOM (Software Bill of Materials)
NTIA’s report, in Übereinstimmung mit der Verordnung des Präsidenten, schlug drei miteinander verbundene Bestandteile einer SBOM vor, die die erforderliche Transparenz der Software bieten sollen. Diese "Mindestelemente" können einen detaillierten Überblick über die Technologie und den funktionalen Aufbau der Software bieten und ermöglichen so eine gründliche Sicherheitsbewertung.
- Datenfelder: Dieses Element ermittelt die Details zu den Softwarekomponenten in einer formalen SBOM-Struktur. Zu den Datenfeldern gehören unter anderem der Name des Lieferanten, die Komponentenversion und die Abhängigkeitsbeziehungen, um potenzielle Sicherheitslücken aufzuspüren.
- Automatisierungsunterstützung: Automatisierungsunterstützungen bieten die erforderlichen Datenformate, die eine einfache Navigation in SBOM-Daten und die maschinelle Lesbarkeit von Softwarekomponenten ermöglichen. Dies ist ein wesentliches Element, um eine schnellere und autonome Prüfung der Software zu gewährleisten. CycloneDX, SPDX und SWID-Tags sind laut Bericht die drei akzeptierten Formate.
- Prozesse: Dies sind die notwendigen Praktiken, die dazu beitragen würden, die Erstellung und Verwaltung von SBOMs in den sicheren Entwicklungslebenszyklus der Software zu integrieren. Diese Praktiken legen verschiedene Aspekte von SBOMs fest, darunter die Häufigkeit ihrer Erstellung, die Tiefe der enthaltenen Komponenten und Abhängigkeiten sowie bekannte/unbekannte Abhängigkeiten.
Vorteile der Implementierung von SBOM (Software Bill of Materials)
A Umfrage aus dem Jahr 2022 zeigt, dass 53 % der Unternehmen aller Branchen SBOMs als positives Instrument für die Berichterstattung und Compliance bewerten. Eine derart positive Akzeptanz von SBOMs ist nur auf die inhärente Detailgenauigkeit zurückzuführen, die diese Stücklisten bieten. Es ist diese Detailgenauigkeit, die wiederum zu vielen Vorteilen von SBOMs führt:
- Transparenz in der gesamten Lieferkette: Die von SBOMs erfassten Datenfelder und Beziehungen tragen zu einem detaillierten Überblick über die gesamte Software-Lieferkette bei. Die verschiedenen Versionen von Softwarekomponenten, ihre Abhängigkeiten und Kompatibilitäten innerhalb der Software sowie ihre Sicherheitsrisiken lassen sich leicht identifizieren und analysieren.
- Konsistente Sicherheitslage: Selbst bei Software, die trotz potenzieller Risiken, auf die die SBOM hinweist, beschafft wird, können die Sicherheitsadministratoren besser auf etwaige Schwachstellen vorbereitet sein. Auf der Grundlage der SBOM können proaktive Maßnahmen ergriffen werden, um Sicherheitsrisiken zu mindern.
- Compliance-Management: Die SBOM selbst ist zwar eine gesetzliche Vorschrift, hilft den Beteiligten jedoch auch dabei, die strengen Vorschriften für bestimmte Komponenten der Software einzuhalten. Darüber hinaus kann die SBOM durch regelmäßige Audits auch dazu beitragen, Abweichungen bei der Compliance zu identifizieren.
- Bedrohungen durch Dritte: Alle Sicherheitsrisiken, die von Open-Source-Komponenten von Drittanbietern in der Software ausgehen, können mit Hilfe der SBOM leicht nachverfolgt werden. Selbst wenn der Anbieter wissentlich oder unwissentlich eine Sicherheitslücke übersieht, kann SBOM dabei helfen, diese auf die schuldige Komponente eines Drittanbieters zurückzuführen.
Wie erstellt und verwaltet man eine SBOM?
Es gibt Tools, mit denen eine SBOM mit allen erforderlichen Elementen erstellt werden kann. Diese Tools erfüllen die wichtige Funktion, ihre Analyse der Softwarekomponenten in einen der gewünschten SBOM-Standards wie SPDX, CycloneDX und andere zu übersetzen. Diese Tools zur Erstellung von SBOMs können den Beteiligten auch dabei helfen, veraltete Abhängigkeiten, Lizenzen und andere Aspekte zu verfolgen, die zu Sicherheitslücken führen können. So funktionieren diese Tools:
- Schritt 1 – Integration des SBOM-Tools in die CI/CD-Pipeline: Um die verschiedenen Komponenten des Softwarecodes zu erfassen, muss das SBOM-Tool in die CI/CD-Pipeline integriert werden. Diese Tools können je nach Bedarf vor Ort oder in einer Cloud-Umgebung installiert werden.
- Schritt 2 – Scannen des Code-Repositorys: Als Nächstes scannt das Tool den Code, um die verschiedenen Komponenten, Bibliotheken, Open-Source-Frameworks und mehr in der Software zu identifizieren.
- Schritt 3 – Übersetzung der Code-Analyse: Nachdem die Codebasis auf alle Komponenten und Abhängigkeiten gescannt wurde, werden die Daten nach Wunsch in eines der Standard-SBOM-Formate übersetzt.&
- Schritt 4 – Generierung der SBOM: Die übersetzten SBOM-Daten können schließlich zur weiteren Überprüfung im XML- oder JSON-Format exportiert werden. Die NTIA-Berichte schreiben vor, dass bei jeder Aktualisierung der Softwarekomponente eine neue SBOM erstellt werden muss.
SBOM-Standards und -Richtlinien
Die Standards und Richtlinien für die Erstellung von SBOM tragen dazu bei, die Einheitlichkeit der SBOM-Struktur zu gewährleisten und gleichzeitig alle Grundlagen in der verschachtelten Liste von Softwarekomponenten, Bibliotheken und mehr abzudecken. Diese Richtlinien sind auch notwendig, um die automatisierte Erstellung und Verarbeitung von SBOM zu fördern.
- System Package Data Exchange (SPDX): Dieser offene Standard kann dabei helfen, eine lesbare Sprache zu entwickeln, die in Dateiformate wie XML, JSON, YAML und mehr übersetzt werden kann. Der Standard kann die verschiedenen Softwarekomponenten während der Entwicklung und Bereitstellung effizient umreißen, indem er Daten in Form von Erstellungsinformationen, Dateiinformationen, Paketinformationen und mehr sammelt.
- CycloneDX: Dieses Format wurde mit einem besonderen Fokus auf Sicherheit und automatisierte SBOM-Generierung veröffentlicht. Die leichtgewichtige Spezifikation gewährleistet eine gründliche Analyse der Softwarekomponenten, ihrer Interaktion mit externen Diensten und der Beziehungen zwischen ihnen. Der Open-Source-Standard eignet sich auch gut für dynamische Open-Source-Komponenten, die regelmäßig geändert und neu verteilt werden.
- Software Identification Tags (SWID-Tags): SWID-Tags wurden 2012 von der ISO eingeführt und dienen dazu, die Softwarekomponente während ihres gesamten Lebenszyklus zu verfolgen. Diese Tags – nämlich Primär-, Patch-, Korpus- und Ergänzungstags – werden nach der Installation der Software hinzugefügt, um Details zum Installationsprogramm, zur Installation, zu Patches und anderen Aspekten einer Softwarekomponente bereitzustellen.
Herausforderungen bei SBOM (Software Bill of Materials)
Die Herausforderungen bei SBOM ergeben sich aufgrund ihrer stark strukturierten und formalen Natur hauptsächlich im Zusammenhang mit der Generierung. Diese Herausforderungen äußern sich wie folgt:
- Reifegrad von SBOM-Tools: Die Tools werden zwar kontinuierlich weiterentwickelt, um standardisierten SBOM-Formaten und -Strukturen zu entsprechen, dennoch gibt es noch einige Lücken. Darüber hinaus ist die Bedienung dieser Tools aufgrund fehlender guter Schnittstellen, Interfaces und Interoperabilität für verschiedene Interessengruppen schwierig.
- Langsame Einführung und Integration: Es gibt immer noch Drittanbieter, die sich nicht an die SBOM-Vorgaben halten, was zu einer Verzögerung bei der Einführung und Integration von SBOM-Ressourcen führt, insbesondere bei Open-Source-Software.
- Kontinuität bei der SBOM-Erstellung: Die SBOM-Generierung zu einem kontinuierlichen Prozess zu machen, der in verschiedenen Phasen des SDLC stattfindet, ist von den Unternehmen noch nicht erreicht worden. Obwohl dies das Ziel der meisten Unternehmen ist, die mit SBOMs arbeiten, haben viele von ihnen es noch nicht erreicht.
- Zusätzliche Sicherheitsbedenken: Es gibt Sicherheitsexperten, die auch behaupten, dass ein pauschales Schwachstellenmanagement digitale Ökosysteme nicht vor externen Bedrohungen schützen kann. Unternehmen müssen Prioritäten setzen, welche Schwachstellen sie beheben möchten, und entsprechende Strategien entwickeln. Dies ist bei der Arbeit mit SBOMs aufgrund der zusätzlichen Komplexität nur schwer zu erreichen.
Bewährte Verfahren für eine effektive Nutzung von SBOM
Die Erstellung von SBOM ist bereits eine bewährte Vorgehensweise. Die beste Vorgehensweise wäre, sie konsistent und während des gesamten SDLC zu erstellen. Hier sind einige weitere Vorgehensweisen, mit denen dies erreicht und der Nutzen von SBOM für die Sicherheit der Lieferkette maximiert werden kann:
- Frühzeitig erstellen und regelmäßig aktualisieren: Es ist wichtig, dass SBOMs so früh wie möglich im SDLC generiert werden, damit jede hinzugefügte Abhängigkeit von Anfang an erfasst werden kann. Durch regelmäßige Aktualisierungen der SBOM wird sichergestellt, dass alle Builds und Releases der verschiedenen Softwarekomponenten ordnungsgemäß in der Liste vermerkt werden.
- Automatisierte SBOM-Generierung: Da die Automatisierungsunterstützung ein wesentlicher Bestandteil von SBOM ist, wäre es nur sinnvoll, über Automatisierungsressourcen für deren Erstellung zu verfügen. Die Automatisierung würde auch die regelmäßige Erstellung von Rechnungen während des SDLC gewährleisten.
- Standardisierte Formate: Formate wie SPDX oder CycloneDX verfügen über die erforderliche Tiefe, um sicherheitsrelevante SBOM-Daten wirklich zu erfassen. Die Verwendung solcher standardisierten Formate würde die Interoperabilität und Maschinenlesbarkeit der Rechnung gewährleisten.
- Versionskontrolle: Die Versionskontrolle in SBOMs stellt sicher, dass alle neuen Änderungen, die in der Softwarekomponente erstellt oder veröffentlicht werden, für die Sicherheitsbewertung leicht nachverfolgt werden können. Dadurch wird die SBOM auch bei der Verwaltung von Abhängigkeiten zuverlässiger.
Anwendungsfälle für SBOM
Obwohl der Hauptnutzen von SBOM darin besteht, wichtige Einblicke in Software-Schwachstellen zu bieten, kann SBOM für viele Anwendungsfälle eingesetzt werden, darunter:
- Softwaresicherheit: SBOMs können Sicherheitsteams dabei helfen, anfällige Teile des Softwarecodes genau zu identifizieren. Die Teams können damit alle Teile der Software suchen und beheben, die für Cyberangriffe anfällig sind.
- Sicherheit der Lieferkette: Viele Regierungsinstitutionen, darunter die US-Regierung und einige europäische Regierungen, haben die Aufnahme von SBOMs in die Software-Lieferketten vorgeschrieben. Experten gehen davon aus, dass sie bald auch für Endkunden verfügbar sein könnten.
- Einfache Beschaffung: Da Unternehmen aller Branchen über Cybersicherheitsvorfälle besorgt sind, vermitteln SBOMs den Beschaffungsteams, die nach einer Softwarelösung suchen, ein Gefühl der Sicherheit. Die gebotene Transparenz trug dazu bei, Vertrauen zwischen den beiden Parteien aufzubauen.
- Einfache Entwicklung: Da SBOMs eine detaillierte Aufschlüsselung der Abhängigkeiten und Beziehungen zwischen Softwarekomponenten enthalten, ist es für Entwickler einfacher, an neuen Komponenten zu arbeiten, ohne frühere Funktionen zu beeinträchtigen.
Unterschiede zwischen SBOM und SCA
Software Bill of Materials (SBOM) und Software Composition Analysis (SCA) weisen zweifellos Überschneidungen auf, die zum Verständnis der verschiedenen Bestandteile von Software beitragen können. Daher hängt eine fundierte Entscheidung zwischen den beiden davon ab, für welchen Bereich des Software-Lebenszyklus Sie sie einsetzen möchten.
Hier erfahren Sie, was Führungskräfte wissen müssen, um diese Entscheidung zu treffen:
| Aspekt | SBOM | SCA |
|---|---|---|
| Schwerpunkt | Besonderer Fokus auf der Erfassung vielfältiger Softwarekomponenten und der Erstellung einer detaillierten Liste. | Der Schwerpunkt liegt auf der Verwaltung und Analyse von Komponenten hinsichtlich Schwachstellen. |
| Angebote | Bietet eine hierarchische Bestandsaufnahme von Komponenten, Bibliotheken und Abhängigkeiten | Bietet Identifizierung und Behebung von Sicherheitslücken aufgrund risikobehafteter Komponenten. |
| Nutzen | Der Anwendungsbereich ist breiter und umfasst Entwickler, Sicherheitsteams, Beschaffungsteams usw. | Meist beschränkt auf Sicherheitsteams, die SCA-Tools benötigen, um anfällige Komponenten zu beheben. |
Unterschiede zwischen BOM und SBOM
BOM und SBOM klingen so ähnlich, dass man sie oft miteinander verwechseln kann. Sie gehören jedoch zu sehr unterschiedlichen Bereichen. Während BOM ein Inventar ist, das eher für den Fertigungsbereich relevant ist, hat SBOM eine ganz bestimmte Rolle innerhalb der Softwareentwicklung. Hier erfahren Entscheidungsträger, wie sie die beiden Begriffe unterscheiden können:
| Aspekt | Stückliste (BOM) | Software-Stückliste (SBOM) |
|---|---|---|
| Anwendung | Eher für physische Produkte wie Hardware oder Elektronik geeignet. | Anwendung speziell für Softwareprodukte und deren Lieferketten. |
| Compliance | Compliance mit Schwerpunkt auf Fertigungs- oder Bauvorschriften. | Compliance mit Schwerpunkt auf Softwarelizenzen, Sicherheitsanforderungen usw. |
| Benutzer | Hersteller, Lieferkettenmanager. | Entwickler, Sicherheitsteams und Regulierungsprüfer. |
KI-gestützte Cybersicherheit
Verbessern Sie Ihre Sicherheitslage mit Echtzeit-Erkennung, maschineller Reaktion und vollständiger Transparenz Ihrer gesamten digitalen Umgebung.
Demo anfordernFazit
Als Teil der Verwaltungsvorschriften für Cybersicherheit nimmt SBOM bereits einen wichtigen Platz im Software-Lebenszyklus ein. Die Sicherheit von Software-Lieferketten ist einer der vielen Anwendungsfälle, in denen SBOM zum Einsatz kommen kann. Mit verteilten Architekturen, kodifizierter Infrastruktur und weit verbreiteten Netzwerken bedienen Softwarelösungen heute komplexere Geschäftsanwendungsfälle als je zuvor. Die Schlüsselkomponenten und Standardformate von SBOM machen sie zu einem leistungsstarken Verbündeten bei der Eindämmung von Vorfällen wie Uber und Solarwinds.
Basierend auf unseren Ausführungen in diesem Blog können Führungskräfte und Sicherheitsexperten die Best Practices befolgen, um die Erstellung von SBOM zu automatisieren und sie für die Sicherheit der Lieferkette zu nutzen.
SentinelOne kann Ihnen dabei helfen, Funktionen wie SBOM zum Schutz Ihrer Software-Lieferkette einzusetzen. Erfahren Sie mehr über unsere Expertise hier.
"FAQs
Eine Software-Stückliste (SBOM) ist eine detaillierte Aufschlüsselung der verschiedenen Softwarekomponenten, Bibliotheken, Abhängigkeiten und mehr in Form einer hierarchischen Liste. Es ist wichtig, Transparenz über risikobehaftete Teile des Softwarecodes zu gewährleisten, die für Cyberangriffe ausgenutzt werden können.
Dank der umfassenden Transparenz, die eine SBOM bietet, können Sicherheitsexperten potenzielle Schwachstellen in der Software-Lieferkette leichter finden und effektiv beheben.
Gemäß den Verwaltungsvorschriften umfassen die wichtigsten Elemente einer SBOM Datenfelder, Praktiken und Prozesse sowie Automatisierungsunterstützung.
Für eine effektive SBOM-Strategie ist es unerlässlich, Best Practices wie frühzeitige Erstellung, regelmäßige Aktualisierungen, automatisierte Erstellung und Integration in CI/CD-Pipelines zu befolgen.
Die drei Standards, die sich am besten für SBOM eignen, sind SPDX, CycloneDC und SWID Tags.
Zur Erstellung einer Software-Stückliste können Sie Automatisierungstools nutzen, die Ihnen bei den erforderlichen Formaten und Ausgaben helfen. Unsere Experten bei SentinelOne können Ihnen dabei helfen.
