Software Bill of Materials

SBOM als Teil des Vulnerability Managements

Um die Qualität und Leistungsfähigkeit über den gesamten Produktlebenszyklus sicherzustellen, sind Risikomanagementprozesse für Hardware und Software unverzichtbar. Ein implementierter Risikomanagementprozess reduziert die Risiken für Patienten, Anwender und indirekte Nutzer (Safety) so weit wie möglich und stellt die Sicherheit der Software sowie der vernetzten Kundenumgebung (Security) sicher.

Das Vulnerability Management ist Teil des Risikomanagements für IVD-Produkte und beschreibt Vorgehensweisen im Umgang mit Schwachstellen. Die im Rahmen des Vulnerability Managements zu erfüllenden Schutzziele sind die sogenannten CIA-Schutzziele (CIA-Triade):

Die Qualität des Vulnerability Managements hängt auch davon ab, wie gut die Hersteller über die eingesetzten Softwarekomponenten und deren Verwendung informieren. Eine wichtige Rolle spielt hierbei die Verfügbarkeit von qualitativ hochwertigen Quellen für Schwachstellen. Grundsätzlich gilt, dass alle Softwarekomponenten eines Produktes mit bekannten Schwachstellen (Vulnerabilities) identifiziert und bewertet werden. Ohne die vollständige Identifizierung aller Software Komponenten in einem Produkt kann nur ungenügend das Vulnerability Management umgesetzt werden, weshalb auf die Dokumentation mit der sogenannten Software Bill of Materials (SBOM) besonders acht gegen werden muss. 

Eine SBOM ist eine systematische und strukturierte Auflistung aller Softwarekomponenten eines Produkts. Sie gibt an, welche Komponenten (OTS, Pakete, Bibliotheken, Frameworks, Code Snippets etc.) sich in einer Anwendung befinden, woher sie stammen (Ersteller/Supplier/Quelle), welche Version sie haben und wie sie eindeutig zu identifizieren sind. Im Vulnerability Management hat sich ein dokumentierter Prozess des IT-Risikomanagements, welcher die SBOM vorne anstellt, durchgesetzt.

Der Gesetzgeber hat auch die zentrale Bedeutung der SBOM erkannt und in relevante regulatorische IVD Vorgaben erwähnt, jedoch noch nicht über die Einhaltung von Normen und Standards verpflichtet. Eine Übersicht der regulatorischen Vorgaben im Bereich der SBOM ist am Ende des Dokuments enthalten.

Gesetzliche Regelungen in der EU

Die wichtigsten Anforderungen an IVD-Produkte, die Software enthalten oder für Software, die selbst ein IVD ist, finden sich in der Verordnung (EU) 2017/746 (IVDR) in Anhang I Abschnitt 16.1, 16.2 und 16.4. Dort wird die Sicherstellung der Leistung und IT-Sicherheit der Software über den gesamten Produktlebenszyklus gefordert. Daraus leitet sich die Verpflichtung zum Vulnerability Management ab.

Gesetzliche Regelung in den USA

Die FDA fordert mit dem Consolidated Appropriations Act von 2023 in Section 523(b) von den Herstellern explizit ein Vulnerability Management und die Bereitstellung einer SBOM für Medizinprodukte und IVD.

Notwendigkeit einer SBOM

• Ein angemessenes Risikomanagement und Vulnerability Management kann nur mit einer korrekten und vollständigen SBOM durchgeführt werden.
• Mit einer vollständigen SBOM wird das Produkt Lifecycle Management planbarer und die Softwarelieferkette transparenter. Die SBOM kann u.a. als Ausgangspunkt für die Verschlankung und Aktualität von Produkten dienen und Aufwände im Postmarket reduzieren.
• Eine vollständige SBOM ermöglicht eine systematische Betrachtung der Drittanbieter-Lizenzen
• Kunden fordern vom Hersteller eine SBOM für ihre Prozesse wie z.B. Risikomanagement, Ausschreibungen etc. ein.

Inhalte einer SBOM zum Zeitpunkt des Releases 
(in Anlehnung an BSI)

Allgemeine Informationen:

• Ersteller der SBOM
• Datum und Uhrzeit des Zeitpunkts der SBOM-Daten-Zusammenstellung

Datenfelder pro Komponente:

• Ersteller
• Bezeichnung
• Version
• Unmittelbare Abhängigkeiten von anderen Komponenten
• Genutzte Lizenz
• Prüfsumme
• Eindeutige ID (CPE/PURL), um Vulnerabilities nachzuschlagen
• Status bzw. Ende des Supports gem. Ersteller

Weitere optionale Komponenten einer SBOM

• Vulnerabilities
• Komponenten tieferer Level

Wie gelingt die Umsetzung der SBOM?

Um die Erstellung einer SBOM zu erleichtern, gibt es eine Reihe von Standards, Tools und Verfahren. Die wichtigsten sind nachfolgend aufgeführt und erläutert.

1. Maschinenlesbare Formate CycloneDX oder SPDX verwenden. 
2. Automatisierte (Open Source/kommerzielle) Tools und Scanner verwenden, die den personellen Aufwand bei der Erstellung und Pflege einer SBOM reduzieren. Sie können den Quellcode, Binärdateien und Abhängigkeiten einer Software analysieren und Metadaten extrahieren und daraus eine umfassende Liste der Bestandteile generieren. Zum Beispiel BlackDuck, OWASP Dependency-Check oder Snyk. 
3. SBOM-Erstellung in den Entwicklungsprozess integrieren (CI/CD Pipelines), um die SBOM bei jeder Code-Änderung stets aktuell zu generieren.
4. SBOM manuell überprüfen und validieren, um sicherzustellen, dass die automatisierten Tools keine Komponenten übersehen oder falsch zugeordnet haben.
5. Fokus auf das Top-Level legen, um den Einstieg zu erleichtern. Bei zunehmender Erfahrung und Reife des Prozesses, können auch weitere Level erfasst werden, um ein umfassendes Bild der Softwarekomponenten zu erhalten.

Monitoring der SBOM

Das Monitoring der SBOM beinhaltet die Betrachtung neuer Vulnerabilities und die Aktualität der eingebundenen Komponenten. Im Vulnerability Management hat sich ein dokumentierter wiederholender Prozess des IT-Risikomanagements, welcher die SBOM vorne anstellt, durchgesetzt:

1. Vulnerabilities identifizieren, Aktualität und Status des Supports prüfen
2. Mögliche Auswirkungen im Kontext des Produkts bewerten
3. Maßnahmen definieren, umsetzen und ihre Wirksamkeit überprüfen

Das Monitoring sollte vorwiegend automatisiert erfolgen. Es gibt zahlreiche kommerzielle Produkte und Dienstleistungen, die eine kontinuierliche Analyse und Überprüfung der SBOMs durchführen. Ein Beispiel für ein Open Source Projekt ist OWASP Dependency Track.

Für bekannte und dokumentierte Schwachstellen gibt es unterschiedliche Bezugsquellen, welche über die Webseite oder Programmierschnittstellen abgerufen werden können:

1. National Vulnerability Database (NVD) des National Institute of Standards and Technology (NIST)
2. GitHub Advisory Database
3. Sonatype OSS Index
4. Snyk Vulnerability Database  
5. A distributed vulnerability database for Open Source  

Es ist zu beachten:

• Es können nur bekannte Informationen ins Monitoring einfließen.
• Nicht alle Informationen liegen in maschinenlesbarer Form vor.
• Nicht alle Schwachstellen werden zeitnah in zentralen Datenbanken erfasst.
• Einige Schwachstellen werden nicht in zentralen Datenbanken erfasst.

Aus diesen Gründen ist es sinnvoll, z.B. die Ersteller der Komponenten als Informationsquelle einzubeziehen.

Struktur einer SBOM

(am Beispiel einer CycloneDX JSON-Datei)

Weiterführende Informationen

Eine Einführung in das Thema SBOM bietet sowohl das Dokument des Expertenkreis CyberMed zur Einordnung der SBOM für die Informationssicherheit als auch die TR-03183-2 des BSI zur SBOM. 

Die IMDRF adressiert die SBOM unter anderem in „Principles and Practices for Medical Device Cybersecurity” und “Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity”.

Im Jahr 2022 hat die FDA in ihrem offiziellen Dokument „Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" (Sep 27, 2023) empfohlen, dem Risk Management Report eine SBOM anzuhängen. 

Die standardisierten Formaten CycloneDX oder SPDX verwenden. Zu den genannten Standards existieren zahlreiche Werkzeuge zur Unterstützung der SBOM-Erstellung (CycloneDC Tool Center, SPDX Tools).

OWASP CycloneDX ist ein allgemeines Format für Stücklisten (Bill of Materials, BOM). Es bietet erweiterte Lieferketten-Funktionen zur Reduzierung von Cyberrisiken. Die Spezifikation unterstützt eine Reihe von BOM-Typen (z.B. Software Bill of Materials (SBOM), Software-as-a-Service Bill of Materials (SaaSBOM, Hardware Bill of Materials (HBOM), u.a.). 

SPDX ist ein offener Standard für die Kommunikation von Software-Stücklisten-Informationen, einschließlich Herkunft, Lizenz, Sicherheit und anderer verwandter Informationen. Die SPDX-Spezifikation ist als internationaler offener Standard für Sicherheit, Lizenzkonformität und andere Artefakte der Software-Lieferkette als ISO/IEC 5962:2021 anerkannt.

Siehe auch: ISO/IEC 27001 Control 8.8 Management of technical vulnerabilities. Im Wesentlichen durch das Control 8.8 der ISO/IEC 27002:2022 geregelt, sowie dem Operational Capability: Threat and Vulnerability Management.