Die FDA möchte wissen: Wird Ihre Software weiterhin unterstützt?
14.02.2026
Interlynk
Warum der Unterstützungsstatus von Komponenten der schwierigste Teil von SBOMs für medizinische Geräte ist
Wenn Sie ein Hersteller von medizinischen Geräten sind, der eine Vorankündigung zur Cybersicherheit vorbereitet, haben Sie wahrscheinlich gehört, dass die FDA jetzt einen Software Bill of Materials (SBOM) verlangt. Was Sie möglicherweise nicht realisieren, ist, dass das SBOM selbst nur der Anfang ist. Seit Oktober 2023 setzt die FDA aktiv Anforderungen durch, die weit über die Auflistung der Softwarekomponenten in Ihrem Gerät hinausgehen. Sie möchten wissen, ob diese Komponenten immer noch gepflegt werden.
Dieser Artikel erläutert, was die FDA tatsächlich für den Unterstützungsstatus von Komponenten verlangt, warum es überraschend schwierig ist, dies richtig zu machen, und welche praktischen Ansätze heutzutage existieren.
Was genau will die FDA?
Für jede Komponente in Ihrem SBOM – ob es sich um eine kommerzielle Bibliothek, ein Open-Source-Paket oder ein Stück Standardsoftware handelt – erwartet die FDA zwei spezifische Informationen:
1. Unterstützungsgrad
Wird diese Komponente aktiv gewartet? Hat der Wartende aufgehört, daran zu arbeiten? Wurde sie vollständig aufgegeben? Die FDA interessiert sich dafür, weil eine nicht unterstützte Komponente eine tickende Zeitbombe ist. Wenn eine Schwachstelle in einer Bibliothek entdeckt wird, die niemand patcht, erbt Ihr Gerät dieses Risiko ohne klaren Weg zur Behebung.
Die FDA erkennt allgemein diese Kategorien an:
Aktiv gewartet – Jemand überwacht den Code, gibt Updates heraus und behebt Sicherheitsprobleme.
Nicht mehr gewartet – Die Komponente war zu einem bestimmten Zeitpunkt in einem gewarteten Zustand, aber der Wartende hat aufgehört. Es kommen keine neuen Sicherheitsupdates.
Aufgegeben – Das Projekt wurde ausdrücklich als veraltet erklärt, archiviert oder über einen längeren Zeitraum ohne Wartungsaktivität gelassen.
2. Unterstützung/Ende des Lebenszyklus (EOS/EOL) Datum
Dies ist das Datum, an dem die Unterstützung für die Komponente endet – oder bereits beendet wurde. Für proprietäre Komponenten kann dies aus einem Wartungsvertrag des Anbieters stammen. Für Open-Source-Komponenten wird es kompliziert (mehr dazu gleich).
Wenn Sie keine Unterstützungsinformationen für eine bestimmte Komponente bereitstellen können, erwartet die FDA eine schriftliche Rechtfertigung, die erklärt, warum. „Wir wussten es nicht“ ist keine akzeptable Antwort.
Diese Informationen werden zusammen mit Schwachstellenbewertungen und Behebungsplänen als Teil des umfassenderen Berichts über Cyberrisiken eingereicht. Einreichungen, die unzureichende SBOM- und Komponentensupportdaten aufweisen, können abgelehnt werden – das hat die FDA deutlich gemacht.
Warum ist das so schwer?
Auf dem Papier klingt das einfach: Schauen Sie sich jede Komponente an, überprüfen Sie, ob sie unterstützt wird, und notieren Sie das Datum. In der Praxis erweist sich das jedoch als viel schwieriger, als es scheint. Hier ist der Grund.
Die SBOM-Formatlücke
Die beiden dominierenden SBOM-Standards — SPDX und CycloneDX — wurden nicht mit den Anforderungen an den Unterstützungsstatus der FDA im Hinterkopf entwickelt.
SPDX (pflegegeführt von der Linux Foundation) hat keine nativen Felder für den Unterstützungsgrad von Komponenten oder End-of-Support-Daten. Es gibt einfach keinen Platz im Standard-SPDX-Schema, um auszudrücken: "Diese Komponente wird nicht mehr gewartet" oder "Die Unterstützung endet am 30.06.2025." Sie können die Annotationsmechanismen von SPDX oder externe Dokumentverweise verwenden, aber das sind Umgehungslösungen — keine strukturierten, maschinenlesbaren Felder, die von Tools konsistent verarbeitet werden können.
CycloneDX ist etwas besser positioniert. Es unterstützt einen flexiblen properties-Erweiterungsmechanismus, bei dem Sie beliebige Schlüssel-Wert-Paare an Komponenten anhängen können. So handhaben Plattformen wie Interlynk heute den Unterstützungsstatus — indem sie benutzerdefinierte Eigenschaften schreiben wie:
Aber hier ist der Haken: Das sind hersteller-spezifische Erweiterungen, die nicht Teil der Kern-Specifikation von CycloneDX sind. Ein anderes Tool, das dieses SBOM liest, hätte keine Ahnung, was interlynk:component:support_level bedeutet, es sei denn, es wurde speziell entwickelt, um es zu verstehen. Es gibt keine universelle, standardisierte Möglichkeit, den Unterstützungsstatus in einem der beiden Formate auszudrücken.
Das bedeutet, dass Organisationen oft gezwungen sind, unterstützende Daten als separate CSV-Datei neben dem SBOM zu exportieren, wodurch ein fragmentiertes Bild entsteht, das eine manuelle Abstimmung erfordert. Es funktioniert, aber es ist fragil.
Das Problem der Open-Source-Inferenz
Bei kommerzieller Software ist die Bestimmung des Unterstützungsstatus relativ einfach. Sie haben einen Anbieter. Sie haben einen Unterstützungsvertrag. Der Vertrag hat ein Ablaufdatum. Fertig.
Open Source ist eine ganz andere Welt.
Die meisten Open-Source-Projekte veröffentlichen keine formalen Unterstützungszeitpläne. Es gibt keine "End of Support"-Seite für die Tausenden von transitiven Abhängigkeiten in einem typischen Softwareprojekt. Die FDA erkennt diese Herausforderung an, erwartet jedoch dennoch, dass Hersteller die Informationen bereitstellen — oder rechtfertigen, warum sie dies nicht können.
Wie bestimmen Sie also den Unterstützungsstatus einer Open-Source-Komponente? Sie schließen ihn. Und die Inferenz erfordert Daten aus mehreren Quellen:
Paket-Registry-Aktivität — Wann wurde die letzte Version auf npm, PyPI, Maven Central, RubyGems oder welcher Registry auch immer veröffentlicht? Wenn die letzte Version innerhalb des letzten Jahres veröffentlicht wurde, ist das ein starkes Signal für aktive Wartung. Wenn seit drei Jahren nichts veröffentlicht wurde, ist das ein rotes Tuch.
Aktivität im Quell-Repository — Wann war der letzte Commit im GitHub-, GitLab- oder Bitbucket-Repository des Projekts? Ist das Repository archiviert? Wurde es ausdrücklich als veraltet markiert?
Kennen EOL-Datenbanken — Projekte wie endoflife.date (xeol.io) halten strukturierte Daten über End-of-Life-Daten für bekannte Softwareprodukte. Diese decken große Frameworks, Sprachen und Betriebssysteme ab — repräsentieren jedoch nur einen Bruchteil des gesamten Ökosystems.
Paket-Abwertungsmarken — Einige Registries unterstützen explizite Abwertungsmarker. npm ermöglicht es den Wartenden, Pakete abzuwerten. PyPI-Pakete können zurückgezogen werden. Aber die Akzeptanz dieser Mechanismen variiert stark zwischen den Ökosystemen.
Das Problem ist, dass keine einzige Quelle Ihnen das gesamte Bild liefert. Ein Paket zeigt möglicherweise seit zwei Jahren keine neuen Releases in der Registry — aber der Wartende commitet aktiv, hat einfach keinen Release erstellt. Oder ein Repository zeigt kürzliche Aktivität, aber es sind alles automatisierte Abhängigkeits-Upgrades — keine wesentliche Wartung.
Die Bestimmung des Unterstützungsstatus erfordert die Korrelation von Signalen aus mehreren Quellen und das Anwenden von Urteilsvermögen. Es ist Detektivarbeit, kein Datenbankabgleich.
Das Ausmaß der Ökosysteme
Ein modernes medizinisches Gerät verwendet nicht nur eine Handvoll Bibliotheken. Ein typischer Firmware- oder Anwendungsstack könnte Hunderte oder sogar Tausende von Abhängigkeiten über JavaScript, Python, Java, .NET, Rust, Go, C/C++ und mehr einbeziehen — jede mit Millionen von verfügbaren Paketen und jede mit unterschiedlichen Konventionen, wie Informationen über den Lebenszyklus kommuniziert werden.
Einige Ökosysteme erlauben es den Wartenden, ein Paket explizit abzuwerten. Andere haben überhaupt keinen Abwertungsmechanismus. C- und C++-Bibliotheken haben oft keine Präsenz in Paketmanagern — sie werden als Quellarchive heruntergeladen oder direkt in den Build kompiliert. Es gibt keine universelle API, die Sie anrufen können, um zu fragen: "Ist diese Komponente noch unterstützt?" im gesamten Spektrum.
Das bedeutet, dass die Bereitstellung eines konsistenten Unterstützungsstatus über Ihr gesamtes SBOM spezifisches Wissen über das Ökosystem und Datenpipelines erfordert — eine erhebliche infrastrukturelle Herausforderung.
Das Problem der Embedded- und benutzerdefinierten Builds
Medizinische Geräte laufen häufig auf benutzerdefinierten Linux-Bauten, die mit Buildsystemen wie Buildroot oder Yocto/OpenEmbedded erstellt wurden. Anders als bei typischer Software, die vorgefertigte Pakete installiert, kompiliert dieses System ein ganzes Betriebssystem — Kernel, Systembibliotheken, Dienstprogramme — aus dem Quellcode.
Das fügt zusätzliche Komplexität zum Unterstützungsstatus hinzu:
Die Frage nach dem upstream vs. vendor fork — Bei Embedded-Systemen hängt der Unterstützungsstatus oft nicht nur vom upstream-Projekt ab, sondern auch von hersteller-modifizierten Forks und langfristigen Verträgen. Ein Gerät könnte den Linux-Kernel 5.15 verwenden, der ein bekanntes upstream-EOL-Datum hat — aber die Version, die tatsächlich auf dem Gerät läuft, ist ein vom Anbieter gepatchter Fork. Ob dieser Fork gewartet wird, hängt vom Anbieter ab, nicht vom Open-Source-Projekt.
Hunderte von Komponenten außerhalb traditioneller Registries — Eingebettete Buildsysteme ziehen Quellcode für Hunderte von Paketen (OpenSSL, busybox, systemd usw.) und kompilieren sie für die Zielhardware. Viele davon existieren in Paketregistrierungen wie npm oder PyPI nicht, sodass die üblichen automatisierten Überprüfungen nicht angewendet werden können. Jedes einzelne muss manuell zu seinem upstream-Projekt zurückverfolgt werden.
Proprietäre Hardwarekomponenten — Board Support Packages von Chipanbietern (NXP, TI, Qualcomm usw.) enthalten proprietäre Treiber und Firmware mit Unterstützungslebenszyklen, die an den Produktplan des Anbieters gebunden sind. Die einzige Möglichkeit, das EOL-Datum zu erfahren, besteht darin, Ihren Anbietervertrag zu überprüfen.
Für diese Embedded-Szenarien ist die Bestimmung des Unterstützungsstatus oft eine manuelle Forschungsübung — und einer der zeitaufwändigsten Teile einer FDA-Einreichung.
Ein praktischer Rahmen, um das richtig zu machen.
Angesichts all dieser Komplexität, was sollte ein Hersteller von Medizinprodukten tatsächlich tun? Hier ist ein gestufter Ansatz, der von automatisierten Grundlagen bis hin zu menschlicher Aufsicht aufbaut.
Schicht 1: Nutzung bekannter EOL-Datenbanken
Beginnen Sie mit dem, was bereits dokumentiert ist. Datenbanken wie endoflife.date bieten strukturierte EOL/EOS-Daten für Hunderte von bekannten Produkten — Programmiersprachen, Frameworks, Betriebssysteme, Datenbanken und mehr. Dies wird nicht Ihr gesamtes SBOM abdecken, aber es wird sich um die "großen Steine" kümmern — die Hauptkomponenten, die das größte Risiko darstellen.
Für Komponenten mit bekannten EOL-Daten ist die Zuordnung einfach: Wenn das EOL-Datum verstrichen ist, wird die Komponente nicht mehr gewartet. Wenn das EOS-Datum verstrichen ist, hat die Unterstützung geendet. Wenn das Produkt als veraltet gilt, behandeln Sie es als aufgegeben.
Schicht 2: Automatisierung von Schlussfolgerungen aus Paket- und Repository-Metadaten
Für die lange Liste an Open-Source-Komponenten ohne formelle EOL-Daten sollten automatisierte Prüfungen eingerichtet werden:
Paketfrische: Abfragen des relevanten Paketregisters. Wenn die neueste Version innerhalb eines konfigurierbaren Zeitraums (üblich 365 Tage) veröffentlicht wurde, klassifizieren Sie es als aktiv gewartet.
Repository-Aktivität: Überprüfen Sie das Datum des letzten Commits im Quell-Repository. Wenn die Commits aktuell sind, ist das ein positives Signal.
Veraltete Kennzeichnungen: Überprüfen Sie, ob das Paket oder das Repository ausdrücklich als veraltet oder archiviert markiert wurde.
Kombinieren Sie diese Signale mit sinnvollen Voreinstellungen: Wenn sowohl das Register als auch das Repository keine Aktivität über Ihren Schwellenwert hinaus zeigen, klassifizieren Sie es als nicht mehr gewartet. Wenn das Repository archiviert ist oder das Paket als veraltet gilt, klassifizieren Sie es als aufgegeben.
Dieser automatisierte Ansatz wird nicht perfekt sein — einige aktive Projekte veröffentlichen einfach unregelmäßig — aber er bietet eine schlüssige Grundlage, die den Großteil Ihres SBOM abdeckt.
Schicht 3: Manuelle Überschreibungen mit Audit-Protokollen
Die Automatisierung wird Sie zu 70-80 % dorthin bringen. Der Rest erfordert menschliches Urteilsvermögen. Ihr Team muss in der Lage sein:
Automatisierte Klassifizierungen zu überschreiben — Ein Sicherheitsingenieur könnte wissen, dass ein scheinbar inaktives Projekt tatsächlich von einem internen Team oder einem kommerziellen Anbieter unter Vertrag gewartet wird.
Explizite EOL-Daten festzulegen — Für proprietäre Komponenten oder vom Anbieter unterstützte Bibliotheken, manuell das Vertragsablaufdatum eingeben.
Begründungen zu dokumentieren — Wenn der Unterstützungsstatus ehrlich nicht bestimmt werden kann, halten Sie fest, warum. "Komponente XYZ ist eine lizenzierte C-Bibliothek ohne öffentliche Repository- oder Registerpräsenz. Der ursprüngliche Autor reagiert nicht. Wir haben sie als nicht spezifiziert klassifiziert und in unsere Risikobewertung aufgenommen" ist eine legitime Begründung.
Diese Überschreibungen sollten mit vollständigen Audit-Protokollen verfolgt werden — wer was, wann und warum geändert hat — da die FDA möglicherweise fragt.
Ein Beispiel aus der Praxis: das OpenSSL-Problem
Betrachten Sie ein Medizinprodukt, das OpenSSL 1.1.1 verwendet — eine der am weitesten verbreiteten kryptografischen Bibliotheken der Welt. Upstream erreichte OpenSSL 1.1.1 sein offizielles End-of-Life am 11. September 2023. Ein automatisiertes System würde dies korrekt kennzeichnen und die Komponente als "Nicht mehr gewartet" klassifizieren. Fall abgeschlossen?
Nicht unbedingt. Wenn das Gerät auf Ubuntu 20.04 LTS läuft, übernimmt Canonical Sicherheitsfixes für OpenSSL 1.1.1 im Rahmen ihres langfristigen Support-Engagements. Das upstream Projekt ist am Ende, aber der speziellen Build, die Ihr Gerät nutzt erhält weiterhin Patches über Ihren Distributionsanbieter.
Dies ist eine Unterscheidung, die die Automatisierung allein nicht treffen kann. Die automatisierte Schicht kennzeichnet das Risiko. Die manuelle Überschreibung erfasst die Nuance:
> "OpenSSL 1.1.1 upstream ist EOL, aber unser Gerät verwendet die von Ubuntu 20.04 LTS gewartete Build. Canonical bietet Sicherheits-Patches im Rahmen unseres Supportvertrags bis April 2025. EOL-Datum auf Vertragsablauf festgelegt."
Diese Überschreibung — dokumentiert mit einer Begründung und verknüpft mit einem bestimmten Supportvertrag — ist genau die Art von Beweis, die die FDA erwartet.
Jetzt multiplizieren Sie dies über jede Komponente in einem komplexen Gerät, und der Bedarf an einem strukturierten Überschreibungssystem mit Audit-Protokollen wird offensichtlich.
Schicht 4: Organisatorische Richtlinien
Verschiedene Organisationen benötigen möglicherweise unterschiedliche Schwellenwerte und Regeln. Eine Komponente, die sechs Monate lang inaktiv war, könnte in einem Kontext akzeptabel, in einem anderen jedoch besorgniserregend sein. Organisationen sollten in der Lage sein:
Die Aktivitätsschwellen zu konfigurieren, die für die automatische Klassifizierung verwendet werden
Organisationweit Überschreibungen für Komponenten festzulegen, die sie unabhängig verifiziert haben
Richtlinien zu definieren, die Komponenten mit bestimmten Unterstützungsstatus für eine Überprüfung kennzeichnen
Schicht 5: Kontinuierliche Überwachung
Der Unterstützungsstatus ist keine zeitpunktbasierte Bewertung. Eine Komponente, die aktiv gewartet wurde, als Sie Ihren Antrag auf Marktzulassung eingereicht haben, könnte sechs Monate später aufgegeben werden. Kontinuierliche Überwachung — die regelmäßige Neubewertung des Unterstützungsstatus und das Alarmieren, wenn Komponenten in besorgniserregende Zustände übergehen — ist entscheidend, um Ihr Cybersicherheitsrisiko während des Lebenszyklus des Geräts aufrechtzuerhalten.
Schicht 6: Menschen und Prozesse
Technologie und Daten sind nur ein Teil der Gleichung. Eine der am meisten unterschätzten Herausforderungen ist die organisatorische: Wer besitzt diese Arbeit tatsächlich?
In den meisten Unternehmen für medizinische Geräte ist die Antwort unklar — und das ist das Problem.
Entwicklung erstellt die Software und wählt die Komponenten aus — aber wechselt zur nächsten Version. Den Lebenszyklusstatus für Hunderte von Abhängigkeiten zu verfolgen, gehört nicht zu ihrem täglichen Workflow.
Sicherheit versteht das Risiko von nicht unterstützten Komponenten — hat jedoch oft nicht den Kontext, warum eine bestimmte Version gewählt wurde oder ob ein interner Fork gewartet wird.
Regulierung besitzt die FDA-Einreichung — ist jedoch völlig auf die Ingenieure angewiesen, um die Daten bereitzustellen. Sie können nicht bestimmen, ob busybox 1.35.0 in einem Yocto-Build weiterhin Patches erhält.
Produkt/Einkauf verwaltet die Lieferantenverträge, die die EOL-Daten bestimmen — verbindet aber möglicherweise eine Vertragsverlängerung nicht mit dem Cybersicherheitsrisikoprofil eines Geräts, das bereits auf dem Markt ist.
Keine einzelne Person hat das vollständige Bild. Der Firmware-Ingenieur weiß, dass der Kernel-Fork gewartet wird. Der Einkauf weiß, dass der BSP-Supportvertrag nächstes Jahr ausläuft. Das Open-Source-Programm verfolgt die Community-Gesundheit für wichtige Abhängigkeiten.
Die Organisationen, die dies gut handhaben, etablieren eine klare, funktionsübergreifende Verantwortung — und definieren, wer die Klassifizierungen des Unterstützungsstatus überprüft, wer auf Veränderungen achtet und wer die Unterlagen aktualisiert, wenn ein Lieferantenvertrag erneuert oder eine Komponente ersetzt wird. Ohne diese Prozessklarheit bringt selbst das beste Werkzeug unvollständige Ergebnisse hervor. Die schwierigsten Daten, die zu erfassen sind, sind das institutionelle Wissen, das in den Köpfen der Menschen lebt, nicht in den Paketregistern.
Was muss sich ändern
Der aktuelle Stand der Dinge ist umsetzbar, aber weit davon entfernt, ideal zu sein. Mehrere Dinge wären hilfreich:
SBOM-Standards benötigen native Support-Statusfelder. Sowohl SPDX als auch CycloneDX sollten standardisierte, maschinenlesbare Felder für den Supportlevel und EOL/EOS-Daten enthalten. Anbieter-spezifische Eigenschaften und CSV-Nebenkanäle sind nicht nachhaltig. Die Anforderungen der FDA sind klar – die Standards sollten diese widerspiegeln.
Paketeregistrierungen benötigen bessere Lebenszyklusmetadaten. Wenn npm, PyPI und Maven Central strukturierte EOL- und Supportstatusinformationen zusammen mit Versionsdaten bereitstellten, würde das gesamte Ökosystem profitieren. Einige Registrierungen bewegen sich in diese Richtung, aber die Annahme ist ungleichmäßig.
Das Embedded-Ökosystem benötigt bessere Werkzeuge. Buildroot und Yocto erstellen detaillierte Manifestdateien dessen, was sie bauen, aber die Zuordnung dieser Manifestdateien zum upstream Supportstatus ist weitgehend ein manueller Prozess. Eine bessere Integration zwischen eingebetteten Buildsystemen und SBOM/Support-Status-Werkzeugen würde die Last für Gerätehersteller erheblich reduzieren.
Branchensynergie zu EOL-Daten – und OpenEoX zeigt den Weg. Gemeinschaftsprojekte wie endoflife.date haben begonnen, EOL-Daten für beliebte Produkte zu katalogisieren, aber es hat ein branchenunterstützter Standard gefehlt, wie Lebenszyklustdaten strukturiert und ausgetauscht werden sollten. Genau das ist es, was OpenEoX zu bieten beabsichtigt.
Im Dezember 2023 als OASIS Technical Committee gestartet, wird OpenEoX von Cisco, Dell, Microsoft, Red Hat, Qualys und anderen unterstützt – mit Beiträgen von CISA. Der Standard definiert klare Lebenszyklusphasen, die direkt dem entsprechen, was die FDA verlangt:
Ende des Verkaufs – Anbieter akzeptiert keine neuen Bestellungen mehr
Ende des Sicherheits-Supports – Sicherheitsupdates werden nicht mehr ausgestellt (das entscheidende für medizinische Geräte)
Ende der Lebensdauer – vollständige Stilllegung, keine weitere Unterstützung jeglicher Art
Der wesentliche Einblick hinter OpenEoX ist, dass es bestehende Standards nicht ersetzt – es füllt die Lücke zwischen ihnen. Ihr SBOM sagt Ihnen was in Ihrem Gerät ist. VEX und CSAF sagen Ihnen welche Schwachstellen zutreffen. OpenEoX fügt das fehlende Stück hinzu: wie lange jede Komponente unterstützt wird.
Die Spezifikation befindet sich noch in aktiver Entwicklung (v1.0 ist im Gange), aber die Richtung ist klar und die Branchenunterstützung ist erheblich. Für Hersteller medizinischer Geräte ist OpenEoX eine genaue Beobachtung wert. Es wird das heutige Einreichungsdatum nicht lösen, aber es repräsentiert, wohin sich die Branche entwickelt – hin zu einem universellen, maschinenlesbaren Format für Lebenszyklusdaten, das jedes Werkzeug erzeugen und konsumieren kann.
Das Wichtigste
Die Unterstützungsstatusanforderungen der FDA existieren aus gutem Grund: Nicht unterstützte Software in medizinischen Geräten ist ein Sicherheitsproblem für Patienten. Aber diese Anforderungen zu erfüllen, ist wirklich schwierig – nicht weil die Hersteller nicht bereit sind, sondern weil die Dateninfrastruktur noch nicht vollständig existiert.
Der Weg nach vorne beinhaltet eine Kombination aus automatisierter Inferenz, kuratierten Datenbanken, manueller Aufsicht und – entscheidend – besseren Werkzeugen.
Bei Interlynk haben wir speziell Infrastruktur aufgebaut, um diese Lücke zu schließen – mit automatisierter Inferenz des Unterstützungsniveaus über Paketregister und Quellcode-Repositories, kuratierten EOL-Datenbanken, manuellen Übersteuerungsworkflows mit Ablaufkontrollen und vollständigen Prüfspuren, die für die Prüfung durch die FDA ausgelegt sind. Jede Schicht des in diesem Artikel beschriebenen Rahmens spiegelt die tatsächlichen Herausforderungen wider, die wir für Hersteller medizinischer Geräte gelöst haben, die sich mit Vorabgenehmigungen befassen.
Wenn Sie Schwierigkeiten mit den Unterstützungsstatusdaten haben, sind Sie nicht allein. Die Herausforderung ist real – aber sie ist lösbar, und die Werkzeuge entwickeln sich schnell weiter.
Interlynk bietet Werkzeuge zur Verwaltung von SBOM und zur Sicherheit der Softwarelieferkette, die speziell für regulierte Branchen entwickelt wurden. Um mehr darüber zu erfahren, wie wir die Anforderungen der FDA an den Unterstützungsstatus verwalten, besuchen Sie interlynk.io.