Vorschriften für die Softwarelieferkette: Wie lässt sich ein effektives und effizientes SBOM-Management erreichen?

Die sich verändernde Landschaft der Software-Lieferketten: SBOMs und ihre Herausforderungen

Cybersicherheitsvorfälle zeigen die Notwendigkeit von SBOMs

Die Bedeutung von SBOMs im Hinblick auf jüngste Cybersicherheitsvorfälle

Die Bedeutung von Software Bills of Materials (SBOMs) wurde durch zwei bedeutende Cybersicherheitsvorfälle unterstrichen. Im August 2021 hob die ONEKEY-Warnung schwerwiegende Sicherheitslücken im SDK von Realtek hervor, die eine Vielzahl von IoT-Geräten betrafen und Hunderttausende von Geräten gefährdeten. Diese Schwachstellen, die auf unzureichende Sicherheitspraktiken zurückzuführen sind, bestehen weiterhin in vielen Kundenprodukten, wie von Palo Alto Anfang 2023 aufgedeckt wurde. Dies verdeutlicht die dringende Notwendigkeit von Supply Chain Bills of Materials (SBOMs), die Transparenz und Verantwortlichkeit in der Softwareproduktion und -verteilung schaffen. SBOMs spielen eine entscheidende Rolle dabei, Schwachstellen zu identifizieren und zu beheben, bevor sie die Endbenutzer erreichen, und stärken so die Sicherheit von IoT-Ökosystemen.

Ein weiterer Vorfall ereignete sich im November 2021, als Chen Zhao Jun, ein Sicherheitsanalyst bei Alibaba Cloud Services, eine kritische Sicherheitslücke in der weit verbreiteten Java-Protokollierungsbibliothek Log4j an die Apache Foundation meldete. Diese Schwachstelle, bekannt als Log4Shell (CVE-2021-44228), löste eine weltweite Krise aus. Trotz der schnellen Veröffentlichung von Fixes nach der öffentlichen Bekanntmachung von Apache wurde Log4Shell rasch und umfassend ausgenutzt. IT-Organisationen hatten Schwierigkeiten zu identifizieren, ob ihre Lieferanten Log4j in ihre Produkte integriert hatten, was die Bemühungen zur Schadensminderung behinderte. Softwareanbieter wurden mit Anfragen überflutet und mussten nach Log4j in ihren eigenen Produkten suchen, während sie gleichzeitig versuchten, nachfolgende Fixes zu veröffentlichen. In vielen Fällen mussten sie auf ihre Lieferanten für Patches aus den upstream-Quellen zurückgreifen. Infolgedessen blieben zahlreiche Organisationen sich der Gefahr nicht bewusst und unternahmen keine Maßnahmen.

Diese Vorfälle verdeutlichten zwei wichtige Lektionen: Zufällige Schwachstellen können verheerende Folgen haben, die vergleichbar mit Angriffen auf die Lieferkette sind, und das Management der Exposition gegenüber beiden Risikotypen ist in modernen, erweiterten Software-Lieferketten eine Herausforderung.

Sicherheitslücken könnten als Waffe eingesetzt werden

Zusätzlich weckten diese Vorfälle Bedenken hinsichtlich des möglichen Missbrauchs von Sicherheitslücken, wenn diese nicht öffentlich offengelegt werden, wie das Beispiel zeigt, dass Log4Shell möglicherweise heimlich als Waffe eingesetzt worden wäre, wenn es ausschließlich den chinesischen Behörden offengelegt worden wäre, wie es durch ein kürzlich verabschiedetes chinesisches Gesetz vorgeschrieben ist. Die Folgen dieser Ereignisse haben die Aufmerksamkeit der Regulierungsbehörden auf die kritische Bedeutung von Software-Lieferketten gelenkt.‍

Die Wiederverwendung von Komponenten hat die Produktivität gesteigert

Die weit verbreiteten Herausforderungen der Integration von Softwarekomponenten in der modernen Entwicklung‍

In modernen Softwareentwicklungspraktiken liegt ein starker Fokus auf der Integration bestehender Softwarekomponenten, anstatt von Grund auf neu zu beginnen. Dieser Ansatz umfasst die Kombination einer kleineren Menge neuen Codes mit zahlreichen bereits vorhandenen Komponenten, einschließlich proprietärer und Open-Source-Bibliotheken und -Dienste. Die Fähigkeit, diese Softwarekomponenten wiederzuverwenden, hat die Abstraktion, das Teilen und den Verbrauch solcher Komponenten erheblich vorangetrieben, was zu erheblichen Verbesserungen der Produktivität von Entwicklern geführt hat.

Die IoT-Revolution hat die Verfügbarkeit hochgradig wiederverwendbarer eingebetteter und Cloud-Softwareplattformen effektiv genutzt. Diese Plattformen integrieren Lösungen für verschiedene Designherausforderungen zu niedrigen Kosten und ermöglichen so die weitverbreitete Einführung vernetzter eingebetteter Systeme.

Viele dieser Systeme verwenden ein „IoT-Betriebssystem“ oder eingebettetes Betriebssystem, oft in Form von Referenzcode des Mikrocontroller-Herstellers, zusammen mit zusätzlichem importiertem Code wie Peripherietreibern, Board-Support-Paketen und anwendungsspezifischen Bibliotheken. In zahlreichen Fällen umfasst dieser importierte Code die Mehrheit des gesamten Codes, der zwischen 90 % und 99 % des gesamten Codes ausmacht. Dieser Ansatz hat die Kosten für die Entwicklung von IoT/OT-Geräten erheblich gesenkt.

Das Importieren von Softwarekomponenten ist zu einer so alltäglichen und mühelosen Praxis geworden, dass viele Projekte diese ohne viel Überlegung einbeziehen, obwohl diese Komponenten oft zahlreiche Abhängigkeiten mit sich bringen. Alles, was den Projektfortschritt fördert, wird schnell übernommen. Allerdings haben sich mit der zunehmenden Verbreitung dieser Praxis drei bedeutende Herausforderungen herauskristallisiert.

Die erste Herausforderung besteht darin, dass Organisationen, die stark auf extern entwickelte Komponenten angewiesen sind, die Kontrolle über die Qualität und Sicherheit ihrer eigenen Software abgeben. Auch wenn sie modernste Qualitätstechniken in ihren eigenen Projekten anwenden, haben sie nur begrenzte Einflussmöglichkeiten auf die Qualität und Sicherheit der verwendeten externen Komponenten. Zudem haben sie möglicherweise nur eingeschränkte Transparenz über die gesamte Lieferkette jenseits ihrer direkten Lieferanten.

Die zweite Herausforderung liegt darin, mit Problemen und Sicherheitsupdates in einer Vielzahl von extern gepflegten Komponenten Schritt zu halten. Softwareanbieter müssen Sicherheitsbenachrichtigungen zu diesen Komponenten umgehend bewerten und darauf reagieren, da jede Schwachstelle Kunden Angriffen aussetzen kann. Diese Aufgabe effektiv zu managen, ist jedoch notorisch schwierig. Selbst Organisationen, die in diesem Bereich exzellent arbeiten, sind oft auf ihre Lieferanten angewiesen, um dasselbe zu tun.

Die dritte Herausforderung ergibt sich, wenn extern entwickelte Software unter mehreren Urheberrechtslizenzen bereitgestellt wird. Es ist leicht, den Überblick über die kumulierten Bedingungen dieser Lizenzen zu verlieren und unbeabsichtigt nicht konform zu werden.

Obwohl dies nicht direkt mit Cybersicherheit zu tun hat, stellt die Nichteinhaltung ein Risiko für Störungen durch mögliche Klagen der Urheberrechtsinhaber dar. Daher haben Unternehmensrechtsabteilungen begonnen, diesem Thema mehr Aufmerksamkeit zu schenken.

Während die Integration von Softwarekomponenten Vorteile in Bezug auf Produktivität und Kostensenkungen bietet, stellt sie auch erhebliche Herausforderungen bei der Sicherstellung von Qualität, Sicherheit und Compliance in der gesamten Lieferkette dar. Die Bewältigung dieser Herausforderungen erfordert, dass Organisationen das Management der Software-Lieferkette priorisieren, robuste Sicherheitspraktiken implementieren und eine effektive Kommunikation und Zusammenarbeit mit ihren Lieferanten etablieren.

Verstehen der Rolle und Herausforderungen von SBOMs im Risikomanagement der Lieferkette

Während Software Bills of Materials (SBOMs) erhebliche Aufmerksamkeit erhalten haben, ist es wichtig zu erkennen, dass sie keine eigenständige Lösung für Risiken in der Lieferkette darstellen. Stattdessen ermöglichen SBOMs effektive Lösungen, indem sie eine umfassende Liste von Softwarekomponenten bereitstellen.

Cybersicherheitstools, -prozesse und -richtlinien werden wirkungsvoller und weniger anfällig für blinde Flecken, wenn sie systematisch gegen ein sorgfältig gepflegtes SBOM angewendet werden. Daher sollte der Fokus auf der Implementierung eines breiteren Satzes von Lösungen liegen, anstatt sich ausschließlich auf SBOMs zu verlassen.

Es ist entscheidend zu verstehen, dass die Erstellung eines verwendbaren SBOMs schwieriger ist, als es zunächst erscheinen mag. Ein gut gestaltetes SBOM muss Softwarekomponenten universell und eindeutig identifizieren. Es sollte zusätzliche Informationen wie Abhängigkeitsbeziehungen, Wartende und Lizenzen enthalten, alles in einem standardisierten und weit verbreiteten Format.

Darüber hinaus sollte es Vollständigkeit über verschiedene Komponententypen hinweg anstreben und kontinuierlich aktualisiert werden, um Änderungen in der dokumentierten Software widerzuspiegeln. Ideal wäre es, wenn jede Softwarekomponente ihre eigenen Abhängigkeiten dokumentiert, was die Erstellung eines umfassenden SBOMs erleichtern würde.

Es ist erwähnenswert, dass SBOMs nicht ganz neu sind. Viele Betreiber von IoT/OT-Bibliotheken und Geräten verwenden bereits eine Art Softwareinventar, um diese Herausforderungen zu adressieren oder ihre Anwendungen zu erstellen.

Zudem haben mehrere Anbieter die Fähigkeit, automatisch qualitativ hochwertige SBOMs zu generieren, auch wenn sie diese derzeit nicht nutzen. Neu ist das wachsende Interesse, das durch regulatorische Initiativen vorangetrieben wird, die Sicherheitslage in der Lieferkette zu verbessern. Dies umfasst die Standardisierung und Kommunikation von SBOMs entlang der Lieferketten sowie erhöhte Erwartungen an deren effektive Nutzung.

In den folgenden Abschnitten werden wir die wesentlichen Komponenten und Hauptstandards für SBOMs skizzieren. Wir werden auch erörtern, wie IoT/OT-Anbieter SBOMs erstellen und teilen sollten sowie wie alle Stakeholder in der IoT/OT-Lieferkette SBOMs effektiv nutzen können, um Cybersicherheitsrisiken für IoT/OT-Betreiber zu mindern.

Die ONEKEY Product Cybersecurity & Compliance Platform (OCP) ermöglicht es Herstellern, ihr Produkt-Sicherheitsmanagement von der Gestaltung bis zum Ende des Lebenszyklus zu automatisieren, über den gesamten Produktlebenszyklus hinweg:

Die einzigartige und proprietäre Binärextraktionstechnologie von ONEKEY ermöglicht eine tiefere und präzisere Analyse des Binärfirmware-Images ohne die Notwendigkeit von Quellcode. ONEKEY generiert automatisch ein detailliertes SBOM, einschließlich Softwareabhängigkeiten auf allen Ebenen der Firmware.

Anschließend verwendet ONEKEY basierend auf künstlicher Intelligenz (KI) und maschinellem Lernen einen Natural Language Processing (NLP)-Ansatz, um festzustellen, ob es öffentlich bekannte Schwachstellen gibt, die diese Softwareversion betreffen. Darüber hinaus analysiert der KI/ML-basierte Ansatz von ONEKEY automatisch die Voraussetzungen für die Ausnutzbarkeit der Schwachstellen. In einer integrierten, automatisierten Auswirkungsbewertung wird das Zielgerät daraufhin analysiert, ob die Voraussetzungen für die Ausnutzbarkeit erfüllt sind, wobei nicht relevante Schwachstellen herausgefiltert werden. Dieser einzigartige Ansatz verkürzt die Reaktionszeiten erheblich, indem er die manuelle Auswirkungsbewertung deutlich reduziert und es den Entwicklungs- und ProductSecurity Incident Response Teams (PSIRT) ermöglicht, sich auf die wirklich relevanten Schwachstellen zu konzentrieren.

Die ONEKEY Product Cybersecurity & Compliance Platform (OCP) stellt SBOMs sofort zur Verfügung – bereit für den Export in CycloneDX oder andere Formate

ONEKEY kann ein SBOM einfach aus einem binären Firmware-Image generieren. Das SBOM kann sowohl in maschinenlesbaren Formaten (z. B. CycloneDX, SPDX) als auch in menschenlesbaren Formaten (CSV, EXCEL) exportiert werden, um es anderen Systemen, Endbenutzern und Aufsichtsbehörden zur Verfügung zu stellen.

Das Firmware-Monitoring von ONEKEY analysiert täglich das Zielprodukt auf neue Zero-Day-Schwachstellen oder bekannte Schwachstellen und führt automatische, KI/ML-basierte Auswirkungsbewertungen für alle identifizierten Schwachstellen durch. Dies ermöglicht es Herstellern, schnell auf neue Schwachstellen zu reagieren und Sicherheits-Patches zu erstellen und zu verteilen.

Analyse und Überwachung für automatisierte Sicherheitsprüfung von Drittanbieterkomponenten – richten Sie ONEKEY einfach als Security Gate für jede Drittanbieterkomponente oder jedes Produkt ein.