Die FDA will wissen: Wird Ihre Software noch unterstützt?
| Interlynk
Warum der Support-Status von Komponenten der schwierigste Teil von SBOMs für Medizinprodukte ist
Wenn Sie ein Hersteller von Medizinprodukten sind, der eine Einreichung zur Cybersicherheit vor dem Inverkehrbringen vorbereitet, haben Sie wahrscheinlich schon gehört, dass die FDA jetzt eine Software-Stückliste (SBOM) verlangt. Was Ihnen vielleicht nicht bewusst ist, ist die Tatsache, dass die SBOM selbst erst der Anfang ist. Seit Oktober 2023 setzt die FDA aktiv Anforderungen durch, die weit über die bloße Auflistung der Softwarekomponenten in Ihrem Gerät hinausgehen. Sie möchte wissen, ob diese Komponenten immer noch gepflegt werden.
Dieser Artikel schlüsselt auf, was die FDA tatsächlich in Bezug auf den Support-Status von Komponenten verlangt, warum es überraschend schwierig ist, dies richtig zu machen, und welche praktischen Ansätze es heute gibt.
Was genau will die FDA?
Für jede Komponente in Ihrer SBOM – egal ob es sich um eine kommerzielle Bibliothek, ein Open-Source-Paket oder eine Standardsoftware handelt – erwartet die FDA zwei spezifische Informationen:
1. Grad der Unterstützung (Level of Support)
Wird diese Komponente aktiv gepflegt? Hat der Entwickler die Arbeit daran eingestellt? Wurde sie komplett aufgegeben? Die FDA kümmert sich darum, weil eine nicht unterstützte Komponente eine tickende Zeitbombe ist. Wenn eine Schwachstelle in einer Bibliothek entdeckt wird, die niemand mehr patcht, übernimmt Ihr Gerät dieses Risiko ohne klaren Weg zur Behebung.
Die FDA unterscheidet im Allgemeinen folgende Kategorien:
Aktiv gepflegt (Actively Maintained) – Jemand überwacht den Code, veröffentlicht Updates und behebt Sicherheitslücken.
Nicht mehr gepflegt (No Longer Maintained) – Die Komponente wurde zu einem bestimmten Zeitpunkt gepflegt, aber der Entwickler hat sich anderen Projekten zugewandt. Es erscheinen keine neuen Sicherheits-Patches mehr.
Aufgegeben (Abandoned) – Das Projekt wurde ausdrücklich als veraltet markiert, archiviert oder über einen längeren Zeitraum ohne jegliche Aktivität des Entwicklers belassen.
2. Ende des Supports / End-of-Life (EOS/EOL)-Datum
Dies ist das Datum, an dem der Support für die Komponente endet – oder bereits geendet hat. Bei proprietären Komponenten kann sich dies aus dem Supportvertrag eines Anbieters ergeben. Bei Open-Source-Komponenten wird es hier kompliziert (dazu gleich mehr).
Wenn Sie für eine bestimmte Komponente keine Informationen zum Support bereitstellen können, erwartet die FDA eine schriftliche Begründung. „Wir wussten es nicht“ ist keine akzeptable Antwort.
Diese Informationen werden zusammen mit Schwachstellenanalysen und Sanierungsplänen als Teil des umfassenderen Berichts zu Cybersicherheitsrisiken eingereicht. Einreichungen, denen es an angemessenen SBOM- und Komponentensupportdaten mangelt, können abgelehnt werden – dies hat die FDA deutlich gemacht.
Warum ist das so schwer?
Auf dem Papier klingt das unkompliziert: Jede Komponente nachschlagen, prüfen, ob sie unterstützt wird, und das Datum notieren. In der Praxis erweist sich dies jedoch als weitaus schwieriger, als es sich anhört. Hier ist der Grund dafür.
Die Lücke im SBOM-Format
Die beiden dominierenden SBOM-Standards — SPDX und CycloneDX — wurden nicht mit Blick auf die FDA-Anforderungen zum Support-Status entwickelt.
SPDX (gepflegt von der Linux Foundation) verfügt über keine nativen Felder für die Support-Stufe von Komponenten oder das Support-Ende-Datum. Es gibt im Standard-SPDX-Schema schlichtweg keinen Ort, um auszudrücken, dass „diese Komponente nicht mehr gepflegt wird“ oder „der Support am 30.06.2025 endet“. Man kann zwar den Annotationsmechanismus von SPDX oder Verweise auf externe Dokumente nutzen, aber das sind nur Behelfe — keine strukturierten, maschinenlesbaren Felder, die Tools einheitlich verarbeiten können.
CycloneDX ist da etwas besser aufgestellt. Es unterstützt einen flexiblen Mechanismus zur Erweiterung von properties, mit dem beliebige Schlüssel-Wert-Paare an Komponenten angehängt werden können. Auf diese Weise handhaben Plattformen wie Interlynk den Support-Status heute — indem sie benutzerdefinierte Eigenschaften schreiben wie:
Doch der Haken an der Sache ist: Dies sind anbieterspezifische Erweiterungen und kein Teil der CycloneDX-Kernspezifikation. Ein anderes Tool, das diese SBOM liest, wüsste nicht, was interlynk:component:support_level bedeutet, es sei denn, es wurde speziell dafür entwickelt, dies zu verstehen. Es gibt in keinem der beiden Formate einen universellen, standardisierten Weg, den Support-Status auszudrücken.
Das führt dazu, dass Unternehmen häufig dazu übergehen, Supportdaten als separate CSV-Datei neben der SBOM zu exportieren. Dadurch entsteht ein fragmentiertes Bild, das manuell abgeglichen werden muss. Das funktioniert zwar, ist aber fehleranfällig.
Das Problem der Open-Source-Inferenz
Bei kommerzieller Software ist die Ermittlung des Support-Status relativ einfach. Es gibt einen Anbieter. Es gibt einen Supportvertrag. Der Vertrag hat ein Ablaufdatum. Fertig.
Open Source wiederum ist eine völlig andere Welt.
Die meisten Open-Source-Projekte veröffentlichen keine formellen Support-Zeitplä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 von den Herstellern jedoch dennoch die Bereitstellung dieser Informationen — oder eine Begründung, warum dies nicht möglich ist.
Wie ermittelt man also den Support-Status einer Open-Source-Komponente? Man leitet ihn ab. Und diese Ableitung erfordert Daten aus mehreren Quellen:
Aktivität in der Paketregistrierung — Wann wurde die letzte Version auf npm, PyPI, Maven Central, RubyGems oder der entsprechenden Registrierung des Pakets veröffentlicht? Wenn die neueste Version innerhalb des letzten Jahres veröffentlicht wurde, ist das ein starkes Signal für eine aktive Pflege. Wenn seit drei Jahren nichts mehr veröffentlicht wurde, ist das ein Warnsignal.
Aktivität im Quellcode-Repository — Wann erfolgte der letzte Commit im GitHub-, GitLab- oder Bitbucket-Repository des Projekts? Ist das Repository archiviert? Wurde es ausdrücklich als veraltet (deprecated) markiert?
Bekannte EOL-Datenbanken — Projekte wie endoflife.date (xeol.io) pflegen strukturierte Daten über Support-Enddaten für bekannte Softwareprodukte. Diese decken große Frameworks, Sprachen und Betriebssysteme ab — machen jedoch nur einen Bruchteil des gesamten Ökosystems aus.
Veraltet-Markierungen bei Paketen — Einige Registrierungen unterstützen explizite Kennzeichnungen für veraltete Pakete. npm erlaubt es Maintainern, Pakete als „deprecated“ zu markieren. PyPI-Pakete können zurückgezogen (yanked) werden. Die Nutzung dieser Mechanismen ist jedoch über die verschiedenen Ökosysteme hinweg uneinheitlich.
Das Problem ist, dass keine einzelne Quelle das vollständige Bild liefert. Ein Paket zeigt unter Umständen seit zwei Jahren keine neuen Veröffentlichungen in der Registrierung — aber der Maintainer committet aktiv und hat lediglich noch keine neue Version freigegeben. Oder ein Repository zeigt aktuelle Aktivitäten, bei denen es sich jedoch nur um automatisierte Versionsaktualisierungen von Abhängigkeiten handelt — und nicht um eine inhaltliche Pflege.
Die Ermittlung des Support-Status erfordert das Abgleichen von Signalen aus mehreren Quellen und die eigene Beurteilung. Das ist Detektivarbeit und kein einfaches Nachschlagen in einer Datenbank.
Die Dimensionen der Ökosysteme
Ein modernes Medizinprodukt nutzt nicht nur eine Handvoll Bibliotheken. Ein typischer Firmware- oder Anwendungs-Stack kann Hunderte oder sogar Tausende von Abhängigkeiten in JavaScript, Python, Java, .NET, Rust, Go, C/C++ und anderen Sprachen enthalten — jede mit Millionen von verfügbaren Paketen und jeweils unterschiedlichen Konventionen dafür, wie Lebenszyklus-Informationen kommuniziert werden.
Einige Ökosysteme erlauben es Maintainern, ein Paket explizit als veraltet zu markieren. Andere haben überhaupt keinen solchen Mechanismus. C- und C++-Bibliotheken sind in Paketmanagern oft gar nicht vertreten — sie werden als Quellcode-Archive heruntergeladen oder direkt in den Build einkompiliert. Es gibt keine universelle API, die man aufrufen kann, um für alle diese Komponenten zu fragen: „Wird diese Komponente noch unterstützt?“
Das bedeutet, dass die Bereitstellung eines konsistenten Support-Status für die gesamte SBOM ökosystemspezifisches Wissen und entsprechende Daten-Pipelines erfordert — eine erhebliche infrastrukturelle Herausforderung.
Das Problem bei Embedded- und Custom-Builds
Medizinprodukte laufen häufig auf maßgeschneiderten Linux-Builds, die mit Build-Systemen wie Buildroot oder Yocto/OpenEmbedded erstellt wurden. Im Gegensatz zu typischer Software, die vorkompilierte Pakete installiert, kompilieren diese Systeme ein ganzes Betriebssystem — Kernel, Systembibliotheken, Hilfsprogramme — direkt aus dem Quellcode.
Dies bringt zusätzliche Komplexitätsebenen für den Support-Status mit sich:
Die Frage nach Upstream vs. herstellereigenem Fork — In eingebetteten Systemen hängt der Support-Status oft nicht nur vom Upstream-Projekt ab, sondern von herstellerseitig modifizierten Forks und langfristigen Verträgen. Ein Gerät verwendet möglicherweise den Linux-Kernel 5.15, der ein bekanntes Upstream-EOL-Datum hat — aber die tatsächlich auf dem Gerät ausgeführte Version ist ein vom Hersteller gepatchter Fork. Ob dieser Fork gepflegt wird, hängt vom Hersteller ab, nicht vom Open-Source-Projekt.
Hunderte von Komponenten außerhalb traditioneller Registrierungen — Embedded-Build-Systeme beziehen den Quellcode für Hunderte von Paketen (OpenSSL, busybox, systemd usw.) und kompilieren sie für die Zielhardware. Viele davon existieren nicht in Paketregistrierungen wie npm oder PyPI, sodass die üblichen automatisierten Prüfungen schlichtweg nicht greifen. Jedes einzelne Paket muss manuell bis zu seinem Upstream-Projekt zurückverfolgt werden.
Proprietäre Hardwarekomponenten — Board Support Packages von Chipherstellern (NXP, TI, Qualcomm usw.) enthalten proprietäre Treiber und Firmware, deren Support-Lebenszyklen an die Produktpläne des jeweiligen Herstellers gebunden sind. Die einzige Möglichkeit, das EOL-Datum zu erfahren, ist ein Blick in die Vereinbarung mit Ihrem Lieferanten.
Für diese Embedded-Szenarien ist die Ermittlung des Support-Status oft eine manuelle Recherchearbeit — und einer der zeitaufwendigsten Teile einer FDA-Zulassung.
Ein praktischer Leitfaden, um alles richtig zu machen
Was sollte ein Medizinproduktehersteller angesichts dieser Komplexität eigentlich tun? Hier ist ein mehrschichtiger Ansatz, der sich von automatisierten Grundlagen hin zu menschlicher Kontrolle aufbaut.
Ebene 1: Bekannte EOL-Datenbanken nutzen
Beginnen Sie mit dem, was bereits dokumentiert ist. Datenbanken wie endoflife.date bieten strukturierte EOL/EOS-Daten für Hunderte bekannter Produkte – Programmiersprachen, Frameworks, Betriebssysteme, Datenbanken und mehr. Dies wird zwar nicht Ihre gesamte SBOM abdecken, aber es kümmert sich um die „großen Brocken“ – die Hauptkomponenten, die das größte Risiko darstellen.
Für Komponenten mit bekannten EOL-Daten ist die Zuordnung unkompliziert: Wenn das EOL-Datum überschritten ist, wird die Komponente nicht mehr gewartet. Wenn das EOS-Datum überschritten ist, ist der Support beendet. Wenn das Produkt als veraltet (deprecated) markiert ist, betrachten Sie es als aufgegeben.
Ebene 2: Automatisierte Ableitung aus Paket- und Repository-Metadaten
Richten Sie für die vielen Open-Source-Komponenten ohne formelle EOL-Daten automatisierte Prüfungen ein:
Paket-Aktualität: Fragen Sie das entsprechende Paketregister ab. Wenn die neueste Version innerhalb eines konfigurierbaren Schwellenwerts (üblicherweise 365 Tage) veröffentlicht wurde, wird sie als aktiv gewartet eingestuft.
Repository-Aktivität: Überprüfen Sie das Datum des letzten Commits im Quell-Repository. Wenn die Commits jüngeren Datums sind, ist das ein positives Signal.
Deprecate-Flags: Prüfen Sie, ob das Paket oder das Repository explizit als veraltet markiert oder archiviert wurde.
Kombinieren Sie diese Signale mit sinnvollen Standardwerten: Wenn sowohl das Register als auch das Repository über Ihren Schwellenwert hinaus keine Aktivität aufweisen, stufen Sie sie als nicht mehr gewartet ein. Wenn das Repository archiviert oder das Paket veraltet ist, stufen Sie es als aufgegeben ein.
Dieser automatisierte Ansatz wird nicht perfekt sein – manche aktive Projekte veröffentlichen einfach selten neue Versionen – aber er bietet eine vertretbare Ausgangsbasis, die den Großteil Ihrer SBOM abdeckt.
Ebene 3: Manuelle Überschreibungen mit Audit-Trails
Die Automatisierung bringt Sie zu 70–80 % ans Ziel. Der Rest erfordert menschliches Urteilsvermögen. Ihr Team muss in der Lage sein:
Automatisierte Einstufungen zu überschreiben – Ein Sicherheitsingenieur weiß möglicherweise, dass ein scheinbar inaktives Projekt tatsächlich von einem internen Team oder einem kommerziellen Anbieter im Rahmen eines Vertrags gewartet wird.
Explizite EOL-Daten festzulegen – Geben Sie das Vertragsablaufdatum für proprietäre Komponenten oder herstellerunterstützte Bibliotheken manuell ein.
Begründungen zu dokumentieren – Wenn der Support-Status beim besten Willen nicht ermittelt werden kann, protokollieren Sie den Grund. „Die Komponente XYZ ist eine eingekaufte C-Bibliothek ohne öffentliches Repository oder Präsenz im Paketregister. Der ursprüngliche Autor reagiert nicht. Wir haben sie als unbestimmt eingestuft und in unsere Risikobewertung aufgenommen“ ist eine legitime Begründung.
Diese Überschreibungen sollten mit lückenlosen Audit-Trails nachverfolgt werden – wer hat was, wann und warum geändert –, da die FDA danach fragen könnte.
Ein reales Beispiel: Das OpenSSL-Problem
Denken Sie an ein Medizinprodukt, das OpenSSL 1.1.1 verwendet – eine der am weitesten verbreiteten kryptografischen Bibliotheken der Welt. Seitens des Upstream-Projekts hat OpenSSL 1.1.1 am 11. September 2023 das offizielle End-of-Life erreicht. Ein automatisiertes System würde dies korrekt kennzeichnen und die Komponente als „Nicht mehr gewartet“ einstufen. Fall abgeschlossen?
Nicht unbedingt. Wenn das Gerät unter Ubuntu 20.04 LTS läuft, portiert Canonical im Rahmen seiner langfristigen Support-Zusage Sicherheitskorrekturen für OpenSSL 1.1.1 zurück (Backporting). Das Upstream-Projekt hat das Ende seiner Lebensdauer erreicht, aber der spezifische Build, den Ihr Gerät verwendet, erhält über Ihren Distributionsanbieter weiterhin Patches.
Dies ist eine Unterscheidung, die eine Automatisierung allein nicht treffen kann. Die automatisierte Ebene zeigt das Risiko auf. Die manuelle Überschreibung erfasst die Nuance:
> „OpenSSL 1.1.1 Upstream ist EOL, aber unser Gerät verwendet den von Ubuntu 20.04 LTS gewarteten Build. Canonical stellt im Rahmen unseres Supportvertrags bis April 2025 Sicherheits-Patches zur Verfügung. EOL-Datum auf Vertragsablauf festgelegt.“
Diese Überschreibung – dokumentiert mit einer Begründung und verknüpft mit einem bestimmten Supportvertrag – ist genau die Art von Nachweis, die die FDA erwartet.
Wenn Sie dies nun auf jede Komponente in einem komplexen Gerät hochrechnen, wird die Notwendigkeit eines strukturierten Überschreibungssystems mit Audit-Trails offensichtlich.
Ebene 4: Richtlinien der Organisation
Verschiedene Organisationen benötigen möglicherweise unterschiedliche Schwellenwerte und Regeln. Eine Komponente, die seit sechs Monaten inaktiv ist, kann in einem Kontext akzeptabel sein, in einem anderen jedoch Anlass zur Sorge geben. Organisationen sollten in der Lage sein:
Die für die automatische Einstufung verwendeten Aktivitätsschwellenwerte zu konfigurieren
Organisationsweite Überschreibungen für Komponenten festzulegen, die sie unabhängig überprüft haben
Richtlinien zu definieren, die Komponenten mit bestimmten Support-Status zur Überprüfung kennzeichnen
Ebene 5: Kontinuierliche Überwachung
Der Support-Status ist keine punktuelle Bewertung. Eine Komponente, die bei der Einreichung Ihres Zulassungsantrags aktiv gewartet wurde, könnte sechs Monate später aufgegeben sein. Eine kontinuierliche Überwachung – die regelmäßige Neuberechnung des Support-Status und die Alarmierung, wenn Komponenten in besorgniserregende Zustände übergehen – ist unerlässlich, um Ihr Cybersicherheits-Risikoprofil während des gesamten Lebenszyklus des Geräts aufrechtzuerhalten.
Ebene 6: Menschen und Prozesse
Technologie und Daten sind nur ein Teil der Gleichung. Eine der am meisten unterschätzten Herausforderungen ist die organisatorische: Wer ist eigentlich für diese Arbeit zuständig?
In den meisten Medizintechnikunternehmen ist die Antwort unklar – und genau das ist das Problem.
Die Entwicklung erstellt die Software und wählt die Komponenten aus – wendet sich dann aber der nächsten Version zu. Die Verfolgung des Lebenszyklusstatus über Hunderte von Abhängigkeiten hinweg gehört nicht zu ihren täglichen Aufgaben.
Die Sicherheit versteht das Risiko nicht unterstützter Komponenten – oft fehlt ihr jedoch der Kontext, warum eine bestimmte Version gewählt wurde oder ob ein interner Fork gepflegt wird.
Die Zulassungsabteilung verantwortet die FDA-Einreichung – ist jedoch völlig auf die Entwickler angewiesen, um die Daten bereitzustellen. Sie kann nicht feststellen, ob busybox 1.35.0 in einem Yocto-Build noch Patches erhält.
Der Produktbereich/Einkauf verwaltet die Lieferantenverträge, die die EOL-Daten bestimmen – verknüpft eine Vertragsverlängerung jedoch möglicherweise nicht mit dem Cybersicherheits-Risikoprofil eines bereits auf dem Markt befindlichen Geräts.
Keine einzelne Person hat das vollständige Bild. Der Firmware-Ingenieur weiß, dass der Kernel-Fork gepflegt wird. Der Einkauf weiß, dass der Supportvertrag für das Support-Paket (BSP) nächstes Jahr ausläuft. Das Open-Source-Programmbüro verfolgt den Zustand der Community für wichtige Abhängigkeiten.
Unternehmen, die dies gut handhaben, etablieren klare, abteilungsübergreifende Verantwortlichkeiten. Sie legen fest, wer die Einstufungen des Support-Status überprüft, wer Änderungen überwacht und wer die Daten aktualisiert, wenn ein Lieferantenvertrag verlängert oder eine Komponente ausgetauscht wird. Ohne diese Prozessklarheit führt selbst das beste Tool zu unvollständigen Ergebnissen. Die am schwersten zu erfassenden Daten sind das institutionelle Wissen, das in den Köpfen der Menschen existiert und nicht in Paketregistern.
Was sich ändern muss
Der aktuelle Zustand ist zwar handhabbar, aber weit entfernt von ideal. Einige Maßnahmen würden helfen:
SBOM-Standards benötigen native Statusfelder für den Support-Lebenszyklus. Sowohl SPDX als auch CycloneDX sollten standardisierte, maschinenlesbare Felder für die Supportstufe und EOL/EOS-Daten enthalten. Herstellerspezifische Eigenschaften und separate CSV-Kanäle sind nicht nachhaltig. Die Anforderungen der FDA sind eindeutig – die Standards sollten diese widerspiegeln.
Paket-Registries benötigen bessere Metadaten zum Lebenszyklus. Wenn npm, PyPI und Maven Central strukturierte EOL- und Support-Statusinformationen zusammen mit den Versionsdaten bereitstellen würden, würde das gesamte Ökosystem davon profitieren. Einige Registries bewegen sich bereits in diese Richtung, aber die Akzeptanz ist ungleichmäßig.
Das Embedded-Ökosystem benötigt bessere Werkzeuge. Buildroot und Yocto generieren detaillierte Manifeste der von ihnen erstellten Builds, aber die Zuordnung dieser Manifeste zum Upstream-Supportstatus ist weitgehend ein manueller Prozess. Eine bessere Integration zwischen Embedded-Buildsystemen und Werkzeugen für SBOM/Support-Status würde die Belastung der Gerätehersteller erheblich verringern.
Branchenübergreifende Zusammenarbeit bei EOL-Daten – und OpenEoX ist wegweisend. Community-Projekte wie endoflife.date haben begonnen, EOL-Daten für beliebte Produkte zu katalogisieren. Was jedoch bisher fehlte, war ein von der Industrie unterstützter Standard dafür, wie Lebenszyklusdaten strukturiert und ausgetauscht werden sollten. Genau das will OpenEoX bieten.
OpenEoX wurde im Dezember 2023 als ein OASIS Technical Committee ins Leben gerufen und wird von Cisco, Dell, Microsoft, Red Hat, Qualys und anderen unterstützt – auch die CISA trägt dazu bei. Der Standard definiert klare Lebenszyklusphasen, die genau den Anforderungen der FDA entsprechen:
End-of-Sales – der Hersteller nimmt keine neuen Bestellungen mehr an
End-of-Security-Support – es werden keine Sicherheits-Patches mehr bereitgestellt (der kritische Punkt für Medizinprodukte)
End-of-Life – vollständige Einstellung, keinerlei Support mehr
Die wichtigste Erkenntnis hinter OpenEoX ist, dass es bestehende Standards nicht ersetzt, sondern die Lücke zwischen ihnen schließt. Ihre SBOM sagt Ihnen, was in Ihrem Gerät enthalten ist. VEX und CSAF sagen Ihnen, welche Schwachstellen vorliegen. OpenEoX fügt das fehlende Puzzleteil hinzu: wie lange jede Komponente unterstützt wird.
Die Spezifikation befindet sich noch in der aktiven Entwicklung (v1.0 ist in Arbeit), aber die Richtung ist klar und die Unterstützung durch die Industrie ist beträchtlich. Für Hersteller von Medizinprodukten lohnt es sich, OpenEoX genau im Auge zu behalten. Es wird zwar die heutige Abgabefrist nicht lösen, aber es zeigt, wohin sich die Branche entwickelt – hin zu einem universellen, maschinenlesbaren Format für Lebenszyklusdaten, das jedes Tool erstellen und verarbeiten kann.
Fazit
Die Anforderungen der FDA an den Support-Status existieren aus gutem Grund: Nicht unterstützte Software in Medizinprodukten ist ein Risiko für die Patientensicherheit. Aber die Erfüllung dieser Anforderungen ist ausgesprochen schwierig – nicht weil die Hersteller nicht wollen, sondern weil die Dateninfrastruktur noch nicht vollständig existiert.
Der Weg nach vorn erfordert eine Kombination aus automatisierter Ableitung, gepflegten Datenbanken, manueller Überwachung und – ganz entscheidend – besseren Tools.
Bei Interlynk haben wir eine Infrastruktur aufgebaut, die genau diese Lücke schließt. Sie kombiniert die automatisierte Ableitung des Support-Status über Paketregister und Source-Repositories hinweg mit gepflegten EOL-Datenbanken, manuellen Override-Workflows mit Ablaufsteuerung und vollständigen Audit-Trails, die speziell für die FDA-Prüfung entwickelt wurden. Jede Ebene des in diesem Artikel beschriebenen Frameworks spiegelt reale Herausforderungen wider, die wir für Hersteller von Medizinprodukten bei der Bewältigung von Zulassungsanträgen gelöst haben.
Wenn Sie mit Daten zum Support-Status kämpfen, sind Sie nicht allein. Die Herausforderung ist real – aber sie ist lösbar, und die Tool-Landschaft reift schnell heran.
Interlynk bietet Tools für das SBOM-Management und die Sicherheit der Software-Lieferkette, die speziell für regulierte Branchen entwickelt wurden. Um mehr darüber zu erfahren, wie wir die Anforderungen der FDA an den Support-Status handhaben, besuchen Sie interlynk.io.