SBOM, SOUP, COTS und OTS in Medizinprodukterichtlinien-Software: Der vollständige Leitfaden (2026)
| Interlynk
Moderne Medizinproduktesoftware stammt zum Großteil nicht von Ihnen. Analysen aktueller FDA-Einreichungen zeigen durchweg, dass 75 % oder mehr des durchschnittlichen Software-Stacks eines Geräts aus externen Komponenten bestehen — Open-Source-Bibliotheken, kommerziellen Tools von Drittanbietern und vorgefertigter Infrastruktur. Der Code, den Ihr Team tatsächlich von Grund auf neu geschrieben hat, macht oft nur einen Bruchteil des Ausgelieferten aus.
In dem Moment, in dem Sie nicht beantworten können, was auf einem Gerät läuft, haben Sie ein Compliance-Problem. Zudem haben Sie auch ein Problem mit der Patientensicherheit.
Seit März 2023 fordert die FDA-Sektion 524B eine Software-Stückliste (Software Bill of Materials – SBOM) für alle Premarket-Einreichungen von Cybersicherheitsgeräten. Seit dem 2. Februar 2026 hat das QMSR die ISO 13485:2016 als verbindliche Anforderung in 21 CFR Part 820 integriert. Das bedeutet, dass die Beschaffungskontrollen, Lieferantenbewertungen und Design-Lebenszyklusprozesse, die regeln, wie Sie Softwarekomponenten von Drittanbietern verwalten, nun US-Recht sind und nicht mehr nur eine internationale Best Practice. Zudem setzt der EU Cyber Resilience Act bis Dezember 2027 dieselbe SBOM-Erwartung für europäische Märkte voraus.
Die IEC 62304 fordert bereits seit Jahren ein strukturiertes SOUP-Management. Die meisten Medizinproduktehersteller (MDMs) haben dies jedoch nicht konsequent genug umgesetzt, um einem ernsthaften Audit standzuhalten.
Was ist eine SBOM bei Medizinprodukten?
Eine Software-Stückliste (Software Bill of Materials – SBOM) ist ein maschinenlesbares Verzeichnis aller Softwarekomponenten in einem Gerät: Open-Source-Bibliotheken, kommerzielle SDKs, Betriebssystempakete, Firmware-Abhängigkeiten, Cloud-APIs, die Ihr Gerät zur Laufzeit aufruft, und Ihr eigener proprietärer Code. Das alles.
Die Analogie einer Zutatenliste passt hier sehr gut: Bei einem fehlenden Eintrag steht vielmehr die Patientensicherheit auf dem Spiel als eine Lebensmittelallergie.
Was muss in einer SBOM enthalten sein?
Der im Juni 2025 veröffentlichte endgültige Leitfaden der FDA verweist auf die NTIA-Mindestelemente als Ausgangsbasis. Jeder Komponenteneintrag sollte Folgendes enthalten:
Name des Lieferanten
Name der Komponente
Version
Eindeutiger Bezeichner (CPE oder PURL)
Abhängigkeitsbeziehungen
Autor der SBOM
Zeitstempel
Die FDA akzeptiert SPDX und CycloneDX als maschinenlesbare Formate. Eine PDF-Datei mit einer Auflistung der Softwareversionen ist nicht ausreichend.
Was erfordert FDA-Abschnitt 524B?
Abschnitt 524B des FD&C-Gesetzes, der am 29. März 2023 in Kraft getreten ist, verpflichtet Hersteller von „Cyber-Geräten“, eine SBOM (Software-Stückliste) vorzulegen, die alle kommerziellen, Open-Source- und Standardkomponenten abdeckt. Die FDA hat am 1. Oktober 2023 damit begonnen, nicht konforme Einreichungen abzulehnen. Die endgültige Richtlinie vom Juni 2025 stellte klar, dass SBOMs für Cyber-Geräte obligatorisch sind; für andere Software enthaltende Geräte werden sie dringend empfohlen.
Ein Gerät gilt als Cyber-Gerät, wenn es:
Software enthält, die vom Hersteller validiert, installiert oder autorisiert wurde;
eine Verbindung zum Internet oder einem anderen Gerät herstellen kann; und
technologische Eigenschaften aufweist, die ausgenutzt werden könnten.
Unter QMSR müssen die QMS-Prozesse hinter dieser SBOM —
wie Sie die darin enthaltenen Softwarekomponenten bewerten und qualifizieren,
wie Sie Lieferanten überwachen,
wie Sie Designentscheidungen bezüglich Drittanbieter-Software dokumentieren
— nun die Beschaffungsangaben von ISO 13485:2016 §7.4 als US-amerikanische regulatorische Anforderung erfüllen, nicht mehr nur als internationale Zertifizierungspraxis.
Praxisbeispiel:
Eine Insulinpumpe der Klasse II mit
drahtloser Konnektivität verwendet Ihren proprietären Dosierungsalgorithmus,
OpenSSL für die Verschlüsselung,
Linux als Betriebssystem und
einen Bluetooth-Stack eines Drittanbieters.
Alle vier werden mit Versionsnummern und CVE-Exposition in der SBOM erfasst. Wenn eine kritische Sicherheitslücke OpenSSL betrifft, bewerten Sie die Auswirkungen noch am selben Tag, anstatt zwei Wochen mit dem Reverse Engineering Ihres eigenen Produkts zu verbringen.
Was ist SOUP bei Medizinprodukten? (IEC 62304)
SOUP — Software of Unknown Provenance (Software unbekannter Herkunft) — umfasst jegliche Software, die nicht speziell für Ihr Gerät entwickelt wurde oder für die keine ausreichenden Aufzeichnungen über den Entwicklungslebenszyklus vorliegen. Die Definition der IEC 62304 in §3.1.7 ist bewusst weit gefasst: Sie umfasst Open-Source-Bibliotheken, kommerzielle Software, Legacy-Treiber, vortrainierte KI/ML-Modelle, Cloud-Service-SDKs und sogar Software, die Ihr eigenes Unternehmen für ein früheres Produkt geschrieben hat, wenn die Dokumentation nicht lückenlos ist.
Konkrete Beispiele: Windows, Linux, Android (Betriebssysteme), Bluetooth- und USB-Stacks (Treiber), TensorFlow, OpenSSL, React (Bibliotheken), MySQL, PostgreSQL (Datenbanken), VxWorks, FreeRTOS (Echtzeitbetriebssysteme), AWS- und Azure-SDKs (Cloud-APIs).
Die größte Herausforderung bei SOUP
Das Standard-Software-Lebenszyklusmanagement geht davon aus, dass Sie den Code geschrieben haben, die Anforderungsdokumente besitzen und jede Zeile auf eine Designentscheidung zurückzuführen ist. Bei SOUP trifft nichts davon zu. Sie haben eine Bibliothek, die meistens das tut, was auf der Verpackung steht, und eine Versionsnummer. Sie können nicht überprüfen, wie sie entwickelt wurde, Sie können nicht garantieren, dass der Autor IRGENDELINEN Standard für medizinische Software eingehalten hat, und Sie können nicht kontrollieren, ob und wann Patches veröffentlicht werden.
Das ist keine theoretische Sorge. Es ist die praktische Realität für den Großteil der Software in den meisten Geräten.
IEC 62304 SOUP-Anforderungen nach Sicherheitsklasse:
Klasse A (keine Verletzung bei Softwarefehler möglich): Identifizieren Sie das SOUP-Element und die Version. Nur minimale zusätzliche Dokumentation erforderlich.
Klasse B (nicht schwerwiegende Verletzung möglich): Anforderungen der Klasse A plus dokumentierte funktionale Anforderungen an die SOUP, Nutzungsbedingungen und bekannte Anomalien.
Klasse C (schwere Verletzung oder Tod möglich): Anforderungen der Klasse B plus alle verfügbaren Informationen über die Entwicklungsgeschichte und Prüfung der SOUP, einschließlich einer Bewertung der Angemessenheit.
Unter QMSR regelt ISO 13485 §7.3 (Design und Entwicklung) nun, wie SOUP in das Gerätedesign integriert wird. §7.4 regelt die Lieferantenbewertung und -überwachung für SOUP-Anbieter. Beides ist nun nach US-Recht überprüfbar. Wenn Ihre SOUP-Registrierung und die Aufzeichnungen zur Lieferantenqualifizierung einer ISO 13485-Prüfung nicht standhalten, haben Sie eine QMSR-Lücke – und nicht nur ein Dokumentationsproblem nach IEC 62304.
Praxisbeispiel: Ein EKG-Monitor verwendet eine beliebte Open-Source-Bibliothek zur Kurvendarstellung von GitHub, die seit 18 Monaten nicht mehr angerührt wurde. Ein neuer Mitwirkender führt eine Regression ein, die unter bestimmten Anzeigebedingungen zu einer fehlerhaften Skalierung der Kurve führt. Ohne Versionsbindung und Post-Market-Surveillance für CVEs und Release-Feeds erfährt der Medizinproduktehersteller erst davon, wenn ein Arzt anomale Messwerte meldet. Mit einem ordnungsgemäßen SOUP-Register löst das neue Release eine Überprüfung aus, bevor es überhaupt in die Nähe des Geräts gelangt.
OTS and COTS: Die Unterscheidung, auf die es bei der Dokumentation ankommt
OTS (Off-the-Shelf) Software ist jede vorgefertigte Software, die nicht speziell für Ihr Gerät entwickelt wurde — für den allgemeinen Gebrauch erstellt, in Ihr Produkt integriert, wobei der Quellcode in der Regel für Änderungen nicht zugänglich ist. COTS (Commercial Off-the-Shelf) ist die kommerziell lizenzierte Untergruppe: Ein Anbieter verkauft sie, stellt sie in Rechnung und besitzt das geistige Eigentum. Somit ist jede COTS-Software auch OTS-Software, aber nicht jede OTS-Software ist COTS-Software — Open-Source-Software ist OTS, ohne kommerziell zu sein. Beide Kategorien gelten gemäß IEC 62304 als SOUP und beide müssen in Ihrer SBOM aufgeführt sein.
Die Auswirkungen auf die Dokumentation sind unterschiedlich. Open-Source-OTS bietet Ihnen Zugriff auf die Codebasis und den Entwicklungsverlauf, selbst wenn dieser Verlauf nicht nach medizinischen Softwarestandards erstellt wurde. Kommerzielles OTS bietet Ihnen in der Regel beides nicht — lediglich eine Lizenzvereinbarung und die vom Anbieter zu seinen eigenen Bedingungen durchgeführten Tests.
Die OTS-Richtlinie der FDA erfordert den Nachweis, dass OTS-Software die Geräteleistung oder -sicherheit nicht beeinträchtigt: eine dokumentierte Begründung für die Auswahl, Testnachweise für die korrekte Funktion im spezifischen Kontext Ihres Geräts und ein Plan für den Umgang mit Lebenszyklusereignissen des Anbieters. Die IEC 62304 erfordert diese Validierung selbst dann, wenn die Software völlig unverändert ist. Anbieter-Tests gelten nicht als Ihre eigenen Tests.
Das Risiko im Hinblick auf den Lebenszyklus wird oft unterschätzt: Wenn ein COTS-Anbieter das Support-Ende (End-of-Life) für eine in Ihrem Gerät eingebettete Komponente ankündigt, sind die Optionen begrenzt. Die Verhandlung über erweiterten Support ist teuer. Ein Forken der Codebasis ist unter der Lizenz meist unmöglich. Eine Neuentwicklung um ein Ersatzprodukt herum kann im regulierten Kontext eine neue 510(k)-Zulassung bedeuten. Gemäß QMSR fordert ISO 13485 §7.4, dass Sie dieses Lebenszyklusrisiko vor der Auswahl bewertet haben und es während der gesamten kommerziellen Lebensdauer des Produkts überwachen — und es nicht erst nach der EOL-Ankündigung des Anbieters entdecken.
Eigener Code | Open-Source (SOUP) | OTS/COTS (SOUP) | |
|---|---|---|---|
IEC 62304-Klasse | A, B oder C | B oder C, wenn sicherheitskritisch | B oder C, wenn sicherheitskritisch |
FDA 524B SBOM | Erforderlich | Erforderlich | Erforderlich |
Akzeptiertes SBOM-Format | SPDX oder CycloneDX (maschinenlesbar) | ||
Risikoanalyse | ISO 14971 Risikomanagement | SOUP-Risikoanalyse Funktionale Auswirkung + Sicherheitsrelevanz | SOUP-Risikoanalyse |
CVE-Überwachung | Liegt vollständig bei Ihnen | NVD + CISA KEV | NVD + Hersteller-Sicherheitshinweise |
Quellcode-Zugriff | Vollständiger Zugriff | Meist vollständiger Zugriff | Meist geschlossen |
Patch-Kontrolle | Sie kontrollieren den Veröffentlichungszeitpunkt | Forken oder auf Upstream warten | Anbieterabhängig |
Lizenztyp | Proprietär | MIT, Apache, GPL, BSD | Kommerzielle Lizenz erforderlich |
Praxisbeispiele | Geräte-UI-Logik, Dosierungsalgorithmus, Sensor-Fusions-Code | OpenSSL, libcurl, Linux-Kernel | Windows 10, VxWorks, Azure SDK |
Wenn unbekannte Herkunft mehr kostet als Compliance-Punkte
Im Dezember 2021 traf die Log4Shell-Schwachstelle (CVE-2021-44228) Apache Log4j u2013 eine Java-Protokollierungsbibliothek, die in einem erheblichen Teil der weltweit genutzten Unternehmenssoftware eingebettet ist. CVSS 10.0. Remote-Code-Ausfu00fchrung u00fcber eine einzige bu00f6sartige Zeichenfolge in einem Protokolleintrag.
Auch die Hersteller von Medizinprodukten gerieten in Bedru00e4ngnis. Das konkrete Problem: Viele konnten nicht beantworten, ob ihre Geru00e4te Log4j u00fcberhaupt verwendeten, da sie u00fcber kein zuverlu00e4ssiges Komponenteninventar verfu00fcgten. Einige fu00fchrten es in Backend-Cloud-Systemen aus, die Geru00e4tedaten verarbeiteten. Andere hatten es in einer Jahre zuvor integrierten Drittanbieterkomponente eingebettet. Die FDA veru00f6ffentlichte im Januar 2022 eine Sicherheitsmitteilung (Safety Communication), die sich speziell mit Log4j in Medizinprodukten befasste.
Unternehmen mit gepflegten SBOMs und SOUP-Registern konnten ihr Risiko innerhalb von Stunden bewerten. Unternehmen ohne diese Register benu00f6tigten Wochen u2013 und einige konnten keine vollstu00e4ndige Gewissheit erlangen.
Dasselbe Muster wiederholte sich bei OpenSSL (CVE-2022-0778, CVE-2022-3786), bei Schwachstellen im eingebetteten Linux-Kernel und bei Supply-Chain-Angriffen auf die in der Geru00e4teentwicklung verwendete CI/CD-Infrastruktur. Ende 2025 warnte die FDA, dass die FreeStyle Libre 3-Sensoren von Abbott aufgrund eines Firmware-Fehlers fehlerhaft niedrige Glukosewerte lieferten u2013 sieben Todesfu00e4lle und u00fcber 700 Verletzungen. Softwarefehler in Geru00e4ten, bei denen der Stack nicht vollstu00e4ndig verstanden und kontrolliert wird, haben klinische Auswirkungen.
Eine unbekannte Herkunft (Provenance) ist eine Variable, die die Patientensicherheit gefu00e4hrdet.
Die Regulierungslandschaft im Jahr 2026
Vorschrift | Anforderungen | Status |
|---|---|---|
FDA §524B (FD&C-Gesetz) | Maschinenlesbare SBOM (SPDX oder CycloneDX), die alle kommerziellen, Open-Source- und OTS-Komponenten abdeckt | In Kraft seit März 2023; durchgesetzt seit Okt. 2023 |
FDA June 2025 Final Guidance (Endgültige Leitlinie) | Klärt den Geltungsbereich von §524B für Modifikationen an Geräten; fügt Abschnitt VII für Cybersicherheitsgeräte hinzu | Aktiv |
FDA QMSR (21 CFR Part 820) | ISO 13485:2016 durch Verweis integriert – Beschaffungskontrollen (§7.4), Designlenkung (§7.3) und Lieferantenüberwachung sind nun US-Recht | In Kraft ab 2. Februar 2026 |
IEC 62304 | SOUP-Management, Risikoanalyse, Versionsdokumentation für Software der Klassen B und C | Aktiver internationaler Standard |
EU Cyber Resilience Act | SBOM erforderlich für alle in der EU verkauften Produkte mit digitalen Elementen | In Kraft seit Dez. 2024; SBOM-Konformität fällig bis 11. Dez. 2027 |
ISO 14971 | Risikomanagement-Framework; SOUP-Risiken müssen berücksichtigt werden | Aktiver internationaler Standard |
Executive Order 14028 | SBOM für das Bundesbeschaffungswesen | Optional |
Eine praktische Konsequenz von QMSR, die Teams unvorbereitet trifft: FDA-Nutzer werden Ihre QMS-Aufzeichnungen nun anhand der Anforderungen von ISO 13485 überprüfen, einschließlich der Aufzeichnungen, die vor Februar 2026 erstellt wurden. Wenn Ihre SOUP-Managementprozesse, die Dokumentation zur Lieferantenqualifizierung und die Designlenkungsaufzeichnungen für Drittanbieterkomponenten nicht sauber auf ISO 13485 abgestimmt sind, wird diese Lücke bei einer Inspektion auffallen – und nicht nur bei einer Überprüfung durch eine benannte Stelle.
Über die SBOM als lebendes Dokument: Geräteänderungen – Software-Updates, Lieferantenwechsel, neue Komponentenintegrationen – können eine neue Pre-Market-Einreichung erfordern. Wenn dies der Fall ist, findet §524B uneingeschränkte Anwendung, was eine vollständige und aktuelle SBOM bedeutet. Die bei der ersten Freigabe erstellte SBOM ist nicht das Artefakt, das Sie durch die gesamte kommerzielle Lebensdauer des Geräts begleitet.
10 Praktiken, die es wert sind, 2026 durchgesetzt zu werden
1. SBOMs aus dem Build generieren, nicht aus dem Gedächtnis. Manuell gepflegte SBOMs sind veraltet, sobald sich eine Abhängigkeit ändert. SCA-Tools, die direkt in Ihre CI/CD-Pipeline integriert sind, erstellen SBOMs, die versioniert, signiert und exakt auf den Build abgestimmt sind.
2. Die Container-Ebene abdecken. Bei mit der Cloud verbundenen Geräten muss die SBOM jede Ebene des Container-Images umfassen – Basis-Betriebssystem, Laufzeitumgebung, Middleware – nicht nur den Anwendungscode. Die Komponente, die die Schwachstelle einbringt, ist oft nicht die, die Sie selbst geschrieben haben.
3. Die SBOM vom SOUP-Register trennen. Die SBOM zeigt Ihnen, was vorhanden ist. Das SOUP-Register dokumentiert die Risikoanalyse, die fixierte Version, bekannte Anomalien und die Support-Zeitpläne des Herstellers. Unterschiedliche Artefakte, unterschiedliche Verantwortliche, beide zwingend erforderlich.
4. Versionen fixieren (Pinning). Variable Abhängigkeiten bedeuten, dass sich die Gerätesoftware ohne eine bewusste Entscheidung ändert. Gemäß IEC 62304 ist eine Versionsänderung an einem SOUP-Element eine Änderung der Gerätesoftware. Behandeln Sie sie auch so.
5. CVE-Feeds kontinuierlich für jede SOUP-Komponente überwachen. NVD, OSV und Sicherheitswarnungen der Hersteller müssen alle einbezogen werden. Sobald eine neue CVE ein Element in Ihrer SBOM betrifft, benötigen Sie einen dokumentierten Reaktionsprozess – nicht eine Woche lang Triage, um herauszufinden, wer zuständig ist.
6. SOUP vor der Integration nach Sicherheitsklassen klassifizieren. Eine Bibliothek zur Anzeigeformatierung und ein Insulin-Dosieralgorithmus haben völlig unterschiedliche Dokumentationsanforderungen nach IEC 62304. Treffen Sie diese Klassifizierungsentscheidung explizit und dokumentieren Sie die Begründung. Eine nachträgliche Klassifizierung unter Audit-Druck ist kein gutes Vorgehen.
7. Eigene Validierung für OTS/COTS-Komponenten durchführen. Die Tests des Herstellers zeigen Ihnen, dass die Software in der Umgebung des Herstellers funktioniert. Sie benötigen den Nachweis, dass sie in Ihrer eigenen Umgebung funktioniert – mit Ihrer Hardware, unter Ihren Betriebsbedingungen und im Kontext der von Ihnen zugewiesenen Sicherheitsklasse.
8. Lebenszyklus-Zusagen der Hersteller im SOUP-Register erfassen. Wann dieser Hersteller plant, den Support für diese Version einzustellen, ist ein Risikofaktor, den Ihr Prozess nach ISO 13485 §7.4 bereits bei der Auswahl hätte erfassen müssen. Falls dies nicht geschehen ist, dokumentieren Sie Ihren aktuellen Wissensstand und markieren Sie die Lücke.
9. KI/ML-Modelle als SOUP behandeln. Ein vortrainiertes Modell eines Drittanbieters, ein feinabgestimmtes Basismodell, ein Modell, das in einer Pipeline trainiert wurde, die Sie nicht vollständig kontrollieren – all diese weisen nach IEC 62304 eine unbekannte Herkunft auf. Sie erfordern dieselbe Risikoanalyse wie jedes andere SOUP-Element, plus besondere Aufmerksamkeit für die Integrität der Trainingsdaten und die Modellversionskontrolle.
10. SBOM-Abdeckung auf die Cloud-Infrastruktur ausweiten. Bei mit der Cloud verbundenen Geräten umfasst das betriebliche Abhängigkeitsnetzwerk auch Virtual-Machine-Images, Container-Registries, Cloud-native Dienste und Drittanbieter-APIs. Eine SBOM, die beim Anwendungscode aufhört, deckt die Komponente, die ausgenutzt wird, nicht ab.
Häufig gestellte Fragen
Ist Windows ein Beispiel für SOUP?
Ja – ebenso wie Linux, Android und jedes andere Betriebssystem, das Sie nicht unter Ihrem eigenen Qualitätsmanagementsystem entwickelt haben. Nach IEC 62304 §3.1.7 gilt Windows als SOUP, da keine ausreichenden Aufzeichnungen über seinen Entwicklungsprozess gemäß der Norm existieren. Die internen Tests von Microsoft und Ihre IEC 62304 SOUP-Validierung sind zwei verschiedene Dinge.
Ist eine SBOM von der FDA für alle Medizinprodukte vorgeschrieben?
Die gesetzliche Verpflichtung nach §524B gilt speziell für Cyber-Geräte – also Geräte mit Software, die der Hersteller validiert oder autorisiert, und die die Fähigkeit besitzen, sich mit dem Internet oder einem anderen Gerät zu verbinden. Für Nicht-Cyber-Geräte, die dennoch Software enthalten, empfiehlt die FDA eine SBOM dringend. Die Richtlinie vom Juni 2025 hat diesen Anwendungsbereich nicht geändert, aber sie hat klargestellt, dass bestimmte Änderungen an bestehenden Geräten eine vollständige Einhaltung von §524B auslösen.
Welche SBOM-Formate akzeptiert die FDA?
Sowohl SPDX (unterstützt von der Linux Foundation) als auch CycloneDX (unterstützt von OWASP) werden akzeptiert. Eine Tabelle oder ein PDF gilt nach der Definition der FDA nicht als maschinenlesbar. Beide Formate unterstützen die NTIA-Mindestelemente, auf die sich die FDA in ihrer Richtlinie bezieht.
Was ist der Unterschied zwischen COTS und OTS?
OTS ist die übergeordnete Kategorie – jede vorgefertigte Software, die nicht speziell für Ihr Gerät entwickelt wurde. COTS ist kommerziell lizenzierte OTS: Sie bezahlen dafür, ein Anbieter besitzt sie. Open-Source-Software ist OTS, aber kein COTS. In der Praxis sind die Compliance-Verpflichtungen ähnlich, aber die Dokumentationswege unterscheiden sich, da COTS-Anbieter in der Regel den Quellzugriff und den Zeitpunkt von Patches auf eine Weise kontrollieren, wie es Open-Source-Entwickler nicht tun.
Gilt Open-Source-Software als SOUP?
Ja. Open-Source-Code wird außerhalb Ihres QMS entwickelt. Die Tatsache, dass ein Projekt gut dokumentiert oder weit verbreitet ist, ändert nichts an der Klassifizierung nach IEC 62304 – ausreichende Entwicklungsaufzeichnungen gemäß der Norm existieren für Open-Source-Projekte nicht, da die Norm nicht Teil ihrer Entwicklung war. Eine Risikoanalyse, die der von Ihnen zugewiesenen Sicherheitsklasse entspricht, ist erforderlich.
Was passiert, wenn eine SOUP-Komponente mitten im Lebenszyklus ihr Lebensende (End-of-Life) erreicht?
Der Medizinproduktehersteller (MDM) muss bewerten, ob das Gerät weiterhin in einem cybersicheren Zustand gehalten werden kann. Wenn für neu entdeckte Schwachstellen keine Sicherheits-Patches mehr verfügbar sind, läuft das Gerät Gefahr, „nicht mehr angemessen gegen aktuelle Cybersicherheitsbedrohungen geschützt werden zu können“ – die Schwelle in der FDA-Richtlinie zur Cybersicherheit nach dem Inverkehrbringen, die Offenlegungs- und potenzielle Behebungsverpflichtungen auslöst. Unter QMSR hätte Ihr Lieferantenüberwachungsprozess nach ISO 13485 §7.4 dieses Risiko erkennen müssen, bevor es eintritt.
Wie Interlynk hilft?
Die Pflege einer präzisen, dynamischen SBOM über ein gesamtes Geräteportfolio hinweg – Cloud-Komponenten, Open-Source-SOUP, COTS-Abhängigkeiten, KI/ML-Modelle – ist eine betriebliche Herausforderung. Sie erfordert Automatisierung auf Build-Ebene, eine kontinuierliche Schwachstellenüberwachung, die an den Gerätekontext gekoppelt ist, eine strukturierte SOUP-Risikoanalyse und die Fähigkeit, bei Bedarf FDA-konforme Artefakte zu erstellen. QMSR fügt die Anforderung hinzu, dass all dies innerhalb eines QMS stattfindet, das der ISO 13485 entspricht.
Interlynk baut diese Infrastruktur auf: automatisierte SBOM-Erstellung, SOUP-Registerverwaltung, Lieferantenüberwachung, CVE-Tracking pro Gerät und Bewertung der Bereitschaft für Post-Quanten-Kryptographie.
Buchen Sie eine Demo oder entdecken Sie unsere Open-Source-Tools.