5 Tipps für den Umgang mit Software Bill of Materials (SBOM)

Welche rechtlichen Anforderungen an die Cybersicherheit gibt es in der IT-Lieferkette? Welche Rolle spielt dabei eine Software Bill of Materials (SBOM)? Darüber diskutierte am 03. Mai 2023 die Kompetenzgruppe Sicherheit in einer virtuellen Sitzung.

IT-Anwendungen bauen auf vielen einzelnen Komponenten auf. Einen umfassenden Überblick über ihre Software Supply Chain zu erhalten und diese abzusichern, fällt Unternehmen daher sehr schwer. Eine detaillierte Bill of Materials (Stückliste) schafft Transparenz über die Komponenten und Lieferanten, die für einen Dienst verwendet werden. Lieferanten der US-Regierung müssen für Software neuerdings eine solche Software Bill of Materials (SBOM) zur Verfügung stellen, die genutzte Softwarekomponenten präzise benennt.

Auch die neue NIS2-Richtlinie der EU und der geplante EU Cyber Resilience Act fordern den Einsatz von SBOMs. „Anbieter und Anwender sollten sich mit SBOMs vertraut machen, da die Bereitstellung von SBOMs von Anbietern in vielen Marktbereichen bald verlangt werden wird. Anwender sollten von ihren Lieferanten bereits heute SBOMs fordern, auch wenn viele Anbieter derzeit noch nicht in der Lage sind, diese bereitzustellen“, sagt Oliver Dehning, Leiter der Kompetenzgruppe (KG) Sicherheit im eco Verband.

Bei der Vertragsgestaltung mit Dienstleistern und Lieferanten sollten Unternehmen daher folgende Punkte beachten:

1. Verpflichtung zur Bereitstellung von Informationen für die Durchführung einer Risikobewertung: Eine zentrale Anforderung der neuen EU-Rechtsakte zur Cybersicherheit ist die Durchführung einer Risikobewertung in Bezug auf Netz- und Informationssysteme und hergestellte digitale Produkte. Hierfür sind entsprechende Informationen über die gesamte Lieferkette erforderlich.
2. Verpflichtung zur Bereitstellung von Informationen zur Erstellung einer Software Bill Of Materials (SBOM) über das hergestellte Produkt bzw. die im Unternehmen eingesetzten digitalen Komponenten: Um auf bekannt gewordene Sicherheitslücken reagieren bzw. diese an die zuständigen Aufsichtsbehörden melden zu können, aber auch um Updates für die eigenen Komponenten bereitstellen zu können, ist ein Überblick über die eingesetzten Softwarekomponenten unerlässlich.
3. Verpflichtung zur Bereitstellung von Informationen bei Sicherheitsvorfällen: Um die engen Fristen zur Meldung von Sicherheitsvorfällen an die zuständigen Aufsichtsbehörden einhalten zu können, sollten vertragliche Verpflichtungen zur unverzüglichen Meldung und Dokumentation von Sicherheitsvorfällen vereinbart werden.
4. Verpflichtung von Lieferanten und Auftragnehmern zur Bereitstellung von Sicherheitsupdates: Insbesondere der Entwurf des Cyber Resilience Act verpflichtet Hersteller digitaler Produkte zur Bereitstellung von Sicherheitsupdates für die erwartete Lebensdauer des Produkts oder einen definierten Zeitraum. Um Verzögerungen durch eingesetzte Softwarekomponenten anderer Hersteller zu vermeiden, sollten diese zur unverzüglichen Bereitstellung von Sicherheitsupdates verpflichtet werden.
5. Vertragliche Regelung bezüglich des „Rechts auf Reparatur“: Auf europäischer und nationaler Ebene wird derzeit die Einführung eines allgemeinen Rechts auf Reparatur diskutiert. Digitale und analoge Reparierbarkeit von Produkten hängen eng zusammen. Daher ist es wichtig, dass die geplanten Updatepflichten und die geplanten Anforderungen an die Reparierbarkeit und Nachhaltigkeit von Produkten gut aufeinander abgestimmt sind.

Die Problematik dabei, so Philipp Deppenwiese, Geschäftsführer der immune GmbH: „Die Firmware handelsüblicher PCs ist in den letzten Jahren massiv gewachsen.“ Es gibt teilweise weit über 4.000 Zulieferer für Softwarekomponenten für Firmware großer PC Hersteller wie DELL. Die Dateigröße der Firmware wuchs in den letzten 20 Jahren um bis auf das zwanzigfache. Allerdings ist die Auflistung der verwendeten Funktionen und Bibliotheken seitens der Zulieferer oft unvollständig, so dass eine vollständige SBOM in diesem Bereich eine echte Herausforderung darstellt. Das Projekt „sigstore“ hilft, die Integrität der Software-Lieferkette zu verbessern, indem es Werkzeuge für das Signieren und Verifizieren zur Verfügung stellt – etwa für Archive und kompilierte Binaries. Das verhindert Codemissbrauch und macht Manipulationen erkennbar.

Der Experte erklärte das komplizierte Zusammenspiel bei modernen Rechnern, inklusive TPM (Trusted Platform Module) Chip, Bootloader und UEFI/BIOS. Die stellen sicher, dass der TPM als vertrauenswürdige Quelle auf Hardware-Ebene Sicherheitsinformationen für die Betriebssystemumgebung managen und zur Verfügung stellen kann.

Vertrauliche Informationsquellen

So kann beispielsweise durch „remote attestation“ überprüft werden, ob Hash-Werte mit denen in der SBOM angegebenen übereinstimmen und ob die ausgeführte Software tatsächlich signiert und vertrauenswürdig ist. Besonders wichtig ist dies im mobilen Markt, da hier oftmals eine verlässliche Endpoint-Protection fehlt. Außerdem führte Philip Deppenwiese die Schwierigkeiten in der Zusammenarbeit von Soft- und Hardwareherstellern auf, deren unterschiedliche Kompetenzen oft zu Problemen in der Zusammenarbeit und damit letztendlich zu Schwachstellen führt.

Die Firmware als zentraler Funktionsblock stellt ein lukratives Ziel dar, da die in der SBOM dokumentierten Funktionen und Daten auch von Angreifern genutzt werden können. Umso wichtiger ist es, die Integrität sowohl der Firmware als auch der SBOM sicherzustellen.

SBOM als Grundlage fürs autonome Fahren

Insbesondere im Bereich des autonomen Fahrens entstehen dadurch Herausforderungne. Rohit Bohara von asvin.io geht davon aus, dass das aktuelle Level von 2-3 auf das Level 5 ansteigen wird, was weitere Komplexität und Verantwortung mit sich bringt. Ein zentraler Aspekt ist die große Angriffsfläche, der sich die Software ausgesetzt sieht. Angreifer können hier verschiedene Schwachstellen und Eintrittspunkte ausnutzen. Um die Sicherheit in diesem System zu gewährleisten, ist eine ungebrochene Kette des Vertrauens und der Eigentümerschaft unabdingbar. Es muss bekannt sein, wo eine bestimmte Softwarekomponente herkommt, wer sie erstellt hat und wann sie entwickelt wurden. Dies erfordert eine gut dokumentierte und transparente SBOM.

Eine verteilte SBOM ermöglicht eine Darstellung der Abhängigkeiten in Softwaregraphen, einschließlich Verbindungen zu Bibliotheken und anderen Komponenten. Dies hilft dabei, den Kontext der Software besser zu verstehen und ermöglicht somit ein kontextbasiertes Risikomanagement. Bei der Priorisierung von Risiken werden verschiedene Assets berücksichtigt, um die Sicherheitsmaßnahmen angemessen zu gestalten. Dabei ist es wichtig zu überprüfen, ob eine Schwachstelle überhaupt ausnutzbar ist, zum Beispiel wenn eine bestimmte Komponente nicht am Netz hängt. Die Berücksichtigung all dieser Aspekte ist entscheidend, um die Sicherheit in der komplexen Softwarelandschaft zu gewährleisten und potenzielle Angriffe zu minimieren. Die sorgfältige und vollständige Erstellung der SBOM, die Erfassung von Abhängigkeiten und ein kontextbasiertes Risikomanagement legen den Grundstein für die nächsten Level des autonomen Fahrens.

Cybersicherheit in der Lieferkette: Handlungsbedarf bei Vertragsgestaltungen

Die rechtlichen Herausforderungen sind daher immens, so Stefan Hessel von der Reusch Rechtsanwaltsgesellschaft. In der IT-Branche sei mit erheblichen Veränderungen in den Verträgen zu rechnen, die Produktbeobachtung sowie kostenlose Sicherheitsupdates könnten zur Pflicht werden. Wie lange eine solche Update-Verpflichtung bindend sein wird, steht noch zur Diskussion. Dass es zu einer solchen kommen wird, gilt allerdings als sicher. Ein wesentliches Element dieser Verpflichtung ist die Dokumentation, insbesondere eine Software-Stückliste (SBOM). Eine Nichterfüllung der Dokumentationsvorschriften kann zu hohen Strafen führen. Der CVSS-Score dient als allgemeiner Indikator für die Bewertung von Sicherheitsrisiken. Stefan Hessel ist sich sicher: Verträge mit Meldepflichten zu Sicherheitsvorfällen werden sich häufen. Er schätzt, dass die Richtlinie etwa fünf Jahre nach ihrer Einführung Früchte tragen wird, ähnlich wie es bei der DSGVO der Fall war. Im Zweifel rät er dazu, mit den Behörden in den Dialog zu gehen und konkrete Fragen zu stellen. Denn gibt die Behörde keine oder keine passende Antwort, kann der Vorwurf, sich nicht mit der Richtlinie beschäftigt zu haben, schnell von der Hand gewiesen werden. In solchen Fällen kann es sinnvoll sein, per Gericht Klarheit zu schaffen und einen Präzedenzfall zu kreieren. Er stellt sich die Frage, ob es nicht fatal sein kann, ein Gesetzt zu erlassen, von dem man weiß, dass es zum aktuellen Zeitpunkt noch nicht umsetzbar ist. Auch hier führt er als Beispiel die DSGVO an, deren Umsetzung noch immer nicht vollständig erfolgt. Sein Fazit lautet jedoch, dass es trotzdem wichtig ist, sich auf die bevorstehenden Änderungen vorzubereiten und schrittweise Fortschritte zu erzielen.

Wir bedanken uns bei allen Referenten für die spannenden Vorträge und bei allen Teilnehmenden für die interessanten Diskussionen. Durch unsere Sitzung konnten wir die Bedeutung und die zukünftige Notwendigkeit der Lieferkettensicherheit, insbesondere im SBOM Umfeld, beleuchten. Die Kompetenzgruppe Sicherheit verfolgt das Thema weiterhin und wird in Zukunft noch eine Schritt-für-Schritt Anleitung für die Mitglieder erstellen, was zu tun ist, wenn NIS2, der CRA und Co. greifen. Abonnieren Sie unseren Newsletter, um keine Informationen zu verpassen!