Gesetze und Normen verpflichten Medizinproduktehersteller zur Software Bill of Materials, der SBOM. Standardisierte SBOM-Formate reichen allerdings nicht immer aus, um diese Anforderungen zu erfüllen.
Insbesondere Medizinproduktehersteller, die für ihre Software keine SBOM ausliefern und nutzen, sind im Markt nicht mehr akzeptiert. Hier sind die Gründe.
1. SBOM: Die Grundlagen
a) Was ist eine “Software Bill of Materials”?
Definition des Begriffs „SBOM“
Die „Software Bill of Materials“ (SBOM) ist eine verschachtelte Liste von Software-Komponenten, aus denen ein Software-System besteht. Mit dieser Inventarliste machen die Hersteller transparent, aus welchen eindeutig identifizierbaren Komponenten in welchen Versionen ihre Software-Produkte bestehen.
Eine formale Aufzeichnung der Einzelheiten und Lieferkettenbeziehungen der Komponenten, die in den Softwareelementen eines Produkts mit digitalen Elementen enthalten sind;
EU Cyber Resilience Act, Artikel 3, Abschnitt 37
SBOMs bilden die Hierarchie der Komponenten ab, aus denen Software-Produkte bestehen.
Abgrenzung der SBOM von der SOUP-Liste
Die SBOM und die Liste der verwendeten SOUPs sind nicht identisch:
| SOUP | SBOM |
| Die SOUP-Liste listet „nur“ die Software-Komponenten, die im Medizinprodukt selbst enthalten sind. | Die SBOM kann auch Systemkomponenten um das Medizinprodukt herum enthalten, von denen das Produkt abhängig ist. |
| Eine SOUP ist eine Software-Komponente, die nicht konform der IEC 62304 entwickelt wurde. | Die SBOM unterscheidet dies nicht. |
| Auch selbst entwickelte Software-Komponenten, die Teil des Medizinprodukts sind, aber nicht IEC 62304-konform entwickelt wurden, zählen zur SOUP. | Die SBOM unterscheidet keine Typen selbst entwickelter Software. |
| Die SOUP-Liste ist i. d. R. eine „flache Liste“. | Die SBOM kann die Hierarchie von Komponenten enthalten. |
| Eine SOUP-Liste ist als Teil der Technischen Dokumentation meist ein eigenständiges Dokument oder ein Teil dessen (z. B. Teil der Software-Architektur). | SBOMs sind maschinenlesbar. |
| Die SOUP-Liste ist als Teil der Technischen Dokumentation ein internes Dokument. | Die SBOM wird Betreibern zur Verfügung gestellt (Gesundheitsdienstleistern wie Krankenhäusern). |
| Die SOUP-Liste enthält für jeden Eintrag die erforderlichen Attribute, um die jeweilige SOUP-Komponente zu identifizieren. | Die Einträge einer SBOM verfügen über mehr Attribute als die Elemente einer SOUP-Liste. Beispiele sind HASH/Signatur, Link zur Host-Komponente, weltweit eindeutige ID etc.) |
Fazit: Sowohl SOUPs in der IEC 62304 als auch SBOMs dienen der Identifizierung und Verwaltung von Softwarekomponenten. Sie stammen aber aus unterschiedlichen Kontexten und dienen unterschiedlichen Zwecken:
- Die SOUP ist ein Konzept, das spezifisch ist für Software für medizinische Geräte, insbesondere im Zusammenhang mit der Gewährleistung der Sicherheit und Wirksamkeit dieser Software.
- Das Konzept der SBOM ist breiter und wird in verschiedenen Branchen zur Verwaltung von Software-Lieferketten und zur Verbesserung der Cybersicherheit verwendet, indem es Transparenz über die in einem System verwendeten Software-Komponenten schafft.
b) Was sind die Ziele von SBOMs?
Die SBOMs sollen sowohl den Herstellern als auch deren Kunden (z. B. den Betreibern der Software) und den Aufsichtsbehörden bzw. Benannten Stellen dienen.
Ziele der Hersteller
Die Hersteller verfolgen mit den SBOMs mehrere Ziele:
- Sie erfüllen ihre regulatorischen Anforderungen (mehr dazu weiter unten).
- Die Lizenzbedingungen von Open-Source-Software enthalten die Pflicht zu offenbaren, dass diese Open-Source-Software Teil des Produkts ist.
- Hersteller müssen Schwachstellen in den verwendeten Komponenten schnell finden – z. B. durch einen Abgleich mit der NIST-Datenbank – und beheben. Das setzt voraus, dass sie genau wissen, welche Komponenten ihr Produkt enthält. Die SBOM ermöglicht es, diese Schwachstellenanalyse zu automatisieren.
- Diese Kenntnis hilft auch bei der Risikoanalyse, insbesondere bei der FMEA. Denn diese Analysemethode startet mit der Annahme, dass die Komponenten eines Produkts fehlerbehaftet sind.
- Diese Analyse müssen Hersteller auch in der Post-Market-Phase fortführen, insbesondere als Teil der Post-Market Surveillance.
- Bei der Entwicklung ist es wichtig zu wissen (und festzulegen), welche Komponenten in welchen Versionen zum Einsatz kommen. Versionskonflikte und redundante Komponenten verursachen regelmäßig ein Fehlverhalten der Software und erschweren die Fehlersuche und -behebung. Die SBOM wird damit zum Teil des Konfigurationsmanagements.
- Schließlich kann die SBOM Teil der Lieferantenlenkung sein. Sie verknüpft die Komponenten mit den Lieferanten und den Anforderungen an deren Prozesse und Produkte (die Komponenten). Sie erleichtert die Kommunikation zwischen Hersteller und Lieferant, indem sie die Komponenten eindeutig identifiziert und dem jeweiligen Lieferanten zuordnet.
Ziele der Betreiber
- Betreiber können anhand der SBOM feststellen, ob sie von einer Sicherheitslücke betroffen sind, welche sie dem Hersteller oder einer „Vulnerability-Datenbank“ melden und ggf. selbst beseitigen müssen.
- Bei der Installation sind SBOMs nützlich, um Versionskonflikte von Komponenten zu erkennen und zu vermeiden. Solche Konflikte treten beispielsweise auf, wenn ein Betreiber mehrere Produkte (von mehreren Herstellern) auf einer Plattform installiert.
Ziele der Behörden und Benannten Stellen
Behörden und Benannten Stellen müssen sicherstellen, dass Hersteller die regulatorischen Anforderungen erfüllen.
- Wenn ein Hersteller eine SBOM vorlegen kann, so ist das ein Indiz für eine Konformität.
- Falls der Hersteller zudem plausibel darlegt, wie er die SBOM (automatisiert) erstellt, spricht das auch dafür, dass er sein System kennt und das Konfigurationsmanagement im Griff hat.
Beides hilft Behörden und Benannten Stellen, ihren eigenen regulatorischen Anforderungen gerecht zu werden.
2. Regulatorische Anforderungen
Die FDA fordert explizit SBOMs. In anderen Rechtsbereichen sind die SBOMs unverzichtbar, weil sie Stand der Technik sind und ohne sie andere gesetzliche Pflichten nicht erfüllt werden können.
a) EU-Anforderungen
Anforderungen spezifisch für Medizinprodukte
Die MDR und analog die IVDR fordern im Anhang I, Abschnitt 17.2 keine SBOM, sondern „nur“ IT-Sicherheit nach Stand der Technik. Aber SBOMs sind Stand der Technik.
Die MDCG 2019-16 rev. 1 verpflichtet ebenfalls nicht explizit dazu, SBOMs zu verwenden. Sie fordert aber das Vulnerability-Monitoring.
“This may include the infield monitoring of the software’s vulnerabilities and the possibility to perform a device update (outside the context of a field safety corrective action) through, for example delivering patches to ensure the continued security of the device.”
MDCG 2019-16 rev. 1
Ohne SBOM ist es schwierig, diesen Prozess zu automatisieren und sinnvoll umzusetzen.
Auch die IEC 81001-5-1 als zukünftige harmonisierte Norm fordert nicht explizit die SBOM. Aber sie schreibt:
“The software bill of material (SBOM) is a documentation that tracks all incorporated software.”
IEC 81001-5-1, Anmerkung in E.2.4
Die IEC TR 60601-4-5 wendet sich mit ihren Anforderungen an medizinische elektrische Systeme und ist ausdrücklich auch auf Software als Medizinprodukt anwendbar. Diese Norm beschreibt die “Security Bill of Material”:
“A SECURITY concept related cyber SECURITY Bill of Material including but not limited to a list of commercial, open source, and off-the-shelf software and hardware components. The list should enable the target groups to effectively manage their ASSETS, to understand the potential impact of identified vulnerabilities to the MEDICAL DEVICE (and the connected IT-NETWORK), and to deploy COUNTERMEASURES to maintain the ESSENTIAL FUNCTION of the MEDICAL DEVICE.”
IEC TR 60601-4-5
Die Auslegung der Benannten Stellen ist noch zurückhaltend. Weder das Positionspapier der IG-NB noch das Positionspapier des TEAM-NB erwähnen die SBOM.
Anforderungen an alle Produkte
Der Cyber Resiliance Act schließt Medizinprodukte zwar aus, weil sie bereits einer vertikalen Gesetzgebung folgen. Es ist dennoch interessant, dass dieses Gesetz an 13 Stellen von der “Software-Stückliste” (SBOM) spricht.
Die Hersteller der Produkte mit digitalen Elementen müssen (1) Schwachstellen und Komponenten des Produkts ermitteln und dokumentieren, u. a. durch Erstellung einer Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten des Produkts hervorgehen;
Cyber Resilience Act, Anhang I, Abschnitt 2
Um die Umsetzung des bisher nicht veröffentlichten Gesetzes praktikabler zu machen, hat das BSI die Technische Richtlinie TR03183 erlassen. Der Teil TR03183-2 hat den Titel „Software Bill of Materials (SBOM)“ und formuliert die entsprechenden Anforderungen. Diese können als allgemeingültiger Stand der Technik verstanden werden.
b) Anforderungen der FDA
Während in Europa die Forderungen nach einer SBOM meist nicht explizit formuliert werden, besteht die FDA schon länger auf einer “Cybersecurity Bill of Materials”, die auch Hardware einschloss.
Mit dem Omnibus Act auf nationaler Ebene wurde die SBOM schließlich gesetzlich verpflichtend und wird jetzt auch im aktuellen finalen Cybersecurity-Dokument gefordert.
Es verweist auf die Spezifikationen der National Telecomunications and Information Administration (NTIA). Diese spezifizieren auch die Inhalte der SBOMs (Baseline und Options). Die FDA fordert grundlegende Attribute ein (“baseline attributes“, Quelle: Seite 17 dieses Dokuments).
Die Executive Order 14028 der US-amerikanischen Regierung verpflichtet Zulieferer von US-Behörden, eine Software Bill of Materials beizulegen.
c) Anforderungen in anderen Märkten
Auch in anderen Märkten gibt es eine explizite Anforderung nach SBOMs.
Dazu zählen die „Principles and Practices“ der IMDRF zur Cybersecurity sowie ein Guidance Document dazu.
China hat dezidierte Cybersecurity-Leitlinien für Medizinprodukte publiziert. Dazu zählen die Guidelines for the Review of Medical Device Cybersecurity Registration (überarbeitet 2022). Sie nennen die SBOM:
“16. Off-the-shelf software list (SBOM): The ability of the product to provide the user with a full list of off-the-shelf software.”
Guidelines for the Review of Medical Device Cybersecurity Registration (Nr. 7, 2022)
Die SBOM wird also nicht nur als Dokument erwartet, sondern gleich mit einem Zweck (Veröffentlichung gegenüber Betreiber) verknüpft.
3. SBOM: Standardisierte Formate
a) Überblick über die Formate
SPDX und CyclonDX
SPDX und CyclonDX sind etablierte SBOM-Formate. Diese Formate legen das Dokumentenformat (JSON, XML) fest, identifizieren aber die Software-Komponenten nicht eindeutig. Dafür nutzen sie weitere Formate wie CPE, PURE oder SWID (s. Abb. 2) sowie Check-Summen bzw. Hashes.
Sie finden hier Beispiele für SBOMs im SPDX-Format (als JSON, XML-, Excel-, YAML- und RDF-Datei).
Die Attribute all dieser Formate überlappen sich teilweise.
Konverter erlauben die Umwandlung von SPDX-Dateien in CycloneDX-Dateien und umgekehrt.
Wie oben gezeigt, gelingt die eindeutige Identifikation der Software-Komponenten mit weiteren Standards wie CPE, PURL und SWID. Besonders relevant sind die beiden erstgenannten.
CPE
Das NIST pflegt eine Liste an Komponenten im Common Platform Enumeration (CPE).
Das NIST erstellt auch die Liste der „Common Vulnerabilities“. Die Formate CPE und CVE (Common Vulnerability Enumeration) sowie CVSS sind Teil des Security Content Automation Protocols (SCAP).
PURL
PURL verfolgt einen dezentralen Ansatz. Hier vergibt der Hersteller selbst die Attribute. Das ähnelt dem Ansatz bei Maven mit den GAV-Parametern. GAV steht für
- Group-ID (z. B. org.apache.commons)
- Artifact-ID (z. B. commons-math) und
- Version (z. B. 2.0).
Im Gegensatz zu CPE lassen sich die Artefakte bzw. Komponenten granularer darstellen. Beispielsweise unterscheidet PURL bei Log4j zwischen log4j-core und log4-api; CPE hingegen nicht (s. Tabelle 2).
| Attribut | CPE | Paketmanager (Maven) |
| Hersteller bzw. Namespace | apache | org.apache.logging.log4j |
| Name der Komponente | log4j | log4j-core |
| Version der Komponente | 2.0 | 2.0 |
b) Erfüllung regulatorischer Anforderungen durch die Formate
Bedauerlicherweise sind die Attribute in den Standardformaten nicht so vollständig definiert, dass damit alle gesetzlichen Anforderungen erfüllt sind. So unterscheidet die IEC 81001-5-1 bei Komponenten den Status “maintained”, “supported” oder “required”. Dieser Status ist kein Attribut der Standardformate.
Es liegt in der Entscheidung der Hersteller, ob sie diese Informationen manuell ergänzen oder sich auf die etablierten Formate als Stand der Technik beschränken.
Die strengsten Anforderungen stellt die FDA (“baseline attributes“, Seite 17 dieses Dokuments). Diese entsprechen den Anforderungen der US National Telecommunications and Information Administration (NTIA) und sind durch die o. g. Formate abgedeckt.
4. Arbeiten mit SBOMs
a) Automatisches Erzeugen von SBOMs
Hersteller sollten eine SBOM automatisiert und als Teil ihrer CI/CD-Pipeline erzeugen. Dazu bieten sich Plugins an wie das CycloneDX-Maven-Plugin oder das npm-Meta-Package „CycloneDX BOM“. Microsoft hat ein „sbom-tool“ bei Github veröffentlicht.
Hilfreich ist auch die Tool-Liste der OWASP.
Empfehlenswert sind außerdem Plugins, die die Abhängigkeiten von Bibliotheken und Packages automatisiert analysieren und visuell darstellen. Ein Beispiel ist Oracles JDeps für Java.
b) SBOMs bei der automatischen Erkennung von Schwachstellen
Ein wesentlicher Nutzen der SBOMs ist die automatisierte Identifizierung von Schwachstellen in Software-Produkten, die man verwendet oder selbst hergestellt hat.
Dazu gleichen Tools die in der SBOM gelisteten Software-Komponenten mit den z. B. in der NIST-Datenbank veröffentlichten Schwachstellen automatisch und regelmäßig ab.
Es sind unzählige kommerzielle und freie Tools verfügbar. Eine Suche beispielsweise nach „sbom vulnerability check“, ggf. ergänzt durch „open source“, fördert relevante Treffer zu Tage.
Hersteller sollten mindestens wöchentlich einen Durchlauf durchführen oder sich in Echtzeit mit Push-Benachrichtigung bei gefundenen Schwachstellen über einem festgelegten CVSS-Wert informieren lassen.
5. Fazit und Zusammenfassung
Eine Software ohne SBOM auszuliefern, entspricht nicht dem Stand der Technik. In den USA ist es eine gesetzliche Anforderungen.
Es gibt zahlreiche Tools, um die Software Bill of Materials zu erstellen und automatisiert mit den Schwachstellen-Datenbanken abzugleichen.
Insbesondere Medizinproduktehersteller müssen der Verantwortung für die (IT-)Sicherheit ihrer Produkte gerecht werden.
Aus diesen Gründen gibt es keine Rechtfertigung mehr, auf das Arbeiten mit SBOMs zu verzichten.
Das Johner Institut unterstützt Medizinproduktehersteller dabei, die gesetzlichen Anforderungen an die IT-Sicherheit ihrer Produkte schnell und ohne unnötige Aufwände zu erfüllen und damit sichere Medizinprodukte in die Märkte zu bringen.
