De FDA wil weten: Wordt uw software nog steeds ondersteund?
14 feb 2026
Interlynk
Waarom de Ondersteuningsstatus van Componenten het Moeilijkste Onderdeel is van SBOMs voor Medische Apparaten
Als je een fabrikant van medische apparaten bent die een vooraanstaande cybersecurity-indiening voorbereidt, heb je waarschijnlijk gehoord dat de FDA nu een Software Bill of Materials (SBOM) vereist. Wat je misschien niet beseft, is dat de SBOM zelf slechts het begin is. Sinds oktober 2023 handhaaft de FDA actief eisen die veel verder gaan dan het opsommen van de softwarecomponenten in je apparaat. Ze willen weten of die componenten nog steeds worden verzorgd.
Dit artikel legt uit wat de FDA daadwerkelijk vereist voor de ondersteuningsstatus van componenten, waarom het verrassend moeilijk is om goed te krijgen, en welke praktische benaderingen er vandaag de dag bestaan.
Wat wil de FDA precies?
Voor elk component in uw SBOM - of het nu een commerciële bibliotheek, een open-sourcepakket of een stuk kant-en-klare software is - verwacht de FDA twee specifieke stukjes informatie:
1. Niveau van Ondersteuning
Wordt dit component actief onderhouden? Is de onderhouder gestopt met het werken eraan? Is het volledig verlaten? De FDA geeft om deze zaken omdat een niet-ondersteund component een tikkende klok is. Wanneer een kwetsbaarheid wordt ontdekt in een bibliotheek die niemand aanpakt, neemt uw apparaat dat risico over zonder een duidelijke oplossing.
De FDA erkent doorgaans deze categorieën:
Actief Ondersteund - Iemand houdt de code in de gaten, geeft updates uit en verhelpt beveiligingsproblemen.
Niet Meer Ondersteund - Het component was op een bepaald moment in een onderhouden staat, maar de onderhouder is verder gegaan. Er komen geen nieuwe beveiligingspatches meer.
Verlaten - Het project is expliciet gedeactiveerd, gearchiveerd of heeft gedurende een lange periode geen onderhoudactiviteit meer gehad.
2. Einde Ondersteuning / Einde Levensduur (EOS/EOL) Datum
Dit is de datum waarop de ondersteuning voor het component zal eindigen - of al is geëindigd. Voor eigendomcomponenten kan dit voortkomen uit een ondersteuningscontract met een leverancier. Voor open-sourcecomponenten wordt het ingewikkeld (meer daarover binnenkort).
Als u geen ondersteuningsinformatie voor een specifiek component kunt verstrekken, verwacht de FDA een schriftelijke rechtvaardiging waarin wordt uitgelegd waarom. "We wisten het niet" is geen acceptabel antwoord.
Deze informatie wordt ingediend samen met kwetsbaarheidseffectbeoordelingen en herstelplannen als onderdeel van het bredere cyberbeveiligingsrisicorapport. Indieners die onvoldoende SBOM- en componentondersteuningsgegevens ontbreken, kunnen worden afgewezen - de FDA heeft dit duidelijk gemaakt.
Waarom is dit zo moeilijk?
Op papier klinkt dit eenvoudig: kijk naar elk onderdeel, controleer of het wordt ondersteund, schrijf de datum op. In de praktijk blijkt dit echter veel moeilijker te zijn dan het lijkt. Dit is waarom.
De SBOM Format Kloof
De twee dominante SBOM-standaarden — SPDX en CycloneDX — zijn niet ontworpen met de eisen voor de ondersteuningstatus van de FDA in gedachten.
SPDX (onderhouden door de Linux Foundation) heeft geen native velden voor het ondersteuningsniveau van componenten of einddatum van ondersteuning. Er is simpelweg geen plaats in het standaard SPDX-schema om uit te drukken "dit onderdeel wordt niet langer onderhouden" of "ondersteuning eindigt op 2025-06-30." Je kunt de annotatiemechanisme van SPDX of externe documentreferenties gebruiken, maar dit zijn oplossingen — geen gestructureerde, machine-leesbare velden die tooling consistent kan verwerken.
CycloneDX is iets beter gepositioneerd. Het ondersteunt een flexibel properties uitbreidingsmechanisme waar je willekeurige sleutel-waarde paren aan componenten kunt hechten. Dit is hoe platforms zoals Interlynk vandaag de ondersteuningstatus afhandelen — door aangepaste eigenschappen te schrijven zoals:
Maar hier is het addertje onder het gras: dit zijn leverancier-specifieke uitbreidingen, geen onderdeel van de kern CycloneDX-specificatie. Een ander instrument dat deze SBOM leest, zou geen idee hebben wat interlynk:component:support_level betekent, tenzij het specifiek is gebouwd om dit te begrijpen. Er is geen universele, gestandaardiseerde manier om de ondersteuningstatus in een van beide formaten uit te drukken.
Dit betekent dat organisaties vaak resorteren tot het exporteren van ondersteuningsdata als een afzonderlijk CSV-bestand naast de SBOM, waardoor een gefragmenteerd beeld ontstaat dat handmatige reconciliatie vereist. Het is functioneel, maar fragiel.
Het Open-Source Inferentieprobleem
Voor commercieel software is het bepalen van de ondersteuningstatus relatief eenvoudig. Je hebt een leverancier. Je hebt een ondersteuningscontract. Het contract heeft een vervaldatum. Klaar.
Open source is een heel andere wereld.
De meeste open-sourceprojecten publiceren geen formele ondersteuningsschema's. Er is geen "Einde van ondersteuning"-pagina voor de duizenden transitieve afhankelijkheden in een typisch softwareproject. De FDA erkent deze uitdaging, maar verwacht nog steeds dat fabrikanten de informatie verstrekken — of rechtvaardigen waarom ze dat niet kunnen.
Dus hoe bepaal je de ondersteuningstatus van een open-sourcecomponent? Je leidt het af. En afleiden vereist gegevens uit meerdere bronnen:
Pakketregistratie Activiteit — Wanneer is de laatste versie gepubliceerd op npm, PyPI, Maven Central, RubyGems, of welke registratie de pakket ook heeft? Als de laatste versie binnen het afgelopen jaar is uitgebracht, is dat een sterk signaal van actieve onderhoud. Als er in drie jaar niets is gepubliceerd, is dat een rode vlag.
Bronrepository Activiteit — Wanneer was de laatste commit aan het GitHub-, GitLab- of Bitbucket-repository van het project? Is het repository gearchiveerd? Is het expliciet gemarkeerd als verouderd?
Bekende EOL Databases — Projecten zoals endoflife.date (xeol.io) onderhouden gestructureerde gegevens over einddatums voor bekende softwareproducten. Deze dekken belangrijke frameworks, talen en besturingssystemen — maar ze vertegenwoordigen een fractie van het totale ecosysteem.
Pakket Afkeuringsvlaggen — Sommige registraties ondersteunen expliciete afkeuringsmarkers. npm staat onderhouders toe om pakketten te devalueren. PyPI-pakketten kunnen worden teruggetrokken. Maar de adoptie van deze mechanismen is inconsistent over ecosystemen.
Het probleem is dat geen enkele bron je het complete plaatje biedt. Een pakket kan in twee jaar geen nieuwe registratied releases tonen — maar de onderhoudsverantwoordelijke commit actief, heeft alleen geen release gemaakt. Of een repository kan recente activiteit vertonen, maar het zijn allemaal geautomatiseerde afhankelijkheidsverhogingen — geen zinvol onderhoud.
Het bepalen van de ondersteuningstatus vereist het correleren van signalen uit meerdere bronnen en het toepassen van oordeel. Het is detectivewerk, geen database-opzoeking.
De Schaal van Ecosystemen
Een modern medisch apparaat maakt niet alleen gebruik van een handvol bibliotheken. Een typische firmware of applicatiestack kan honderden of zelfs duizenden afhankelijkheden bevatten in JavaScript, Python, Java, .NET, Rust, Go, C/C++, en meer — elk met miljoenen beschikbare pakketten en elk met verschillende conventies voor hoe lifecycle-informatie wordt gecommuniceerd.
Sommige ecosystemen laten onderhouders expliciet een pakket afkeuren. Anderen hebben helemaal geen afkeuringsmechanisme. C- en C++-bibliotheken hebben vaak geen pakketbeheerder aanwezig — ze worden gedownload als bronarchieven of rechtstreeks in de build gecompileerd. Er is geen universele API die je kunt aanroepen om te vragen "wordt dit component nog steeds ondersteund?" in al deze.
Dit betekent dat het bieden van een consistente ondersteuningstatus over je gehele SBOM ecosysteem-specifieke kennis en gegevenspipelines vereist — een aanzienlijke infrastructuuruitdaging.
Het Embedded en Aangepaste Bouw Probleem
Medische apparaten draaien vaak op op maat gemaakte Linux-builds die zijn gemaakt met buildsystemen zoals Buildroot of Yocto/OpenEmbedded. In tegenstelling tot typische software die kant-en-klare pakketten installeert, compileren deze systemen een compleet besturingssysteem — kernel, systeembibliotheken, hulpprogramma's — vanuit de broncode.
Dit voegt lagen van complexiteit toe aan de ondersteuningstatus:
De upstream vs. leverancier forkvraag — In embedded systemen is de ondersteuningstatus vaak afhankelijk, niet alleen van het upstream-project, maar ook van door de leverancier gemodificeerde forks en langlopende contracten. Een apparaat kan de Linux 5.15-kernel gebruiken, die een bekende upstream EOL-datum heeft — maar de versie die op het apparaat draait is een door de leverancier gepatchte fork. Of die fork wordt onderhouden hangt af van de leverancier, niet van het open-sourceproject.
Honderden componenten buiten traditionele registraties — Embedded buildsystemen trekken broncode voor honderden pakketten (OpenSSL, busybox, systemd, enz.) en compileren deze voor de doelhardware. Veel van deze bestaan niet in pakketregistraties zoals npm of PyPI, dus de gebruikelijke automatische controles zijn eenvoudigweg niet van toepassing. Elk moet handmatig worden herleid naar het upstream-project.
Proprietaire hardwarecomponenten — Board Support Packages van chipleveranciers (NXP, TI, Qualcomm, enz.) bevatten proprietaire stuurprogramma's en firmware met ondersteuningslevenscycli die zijn gekoppeld aan de productroadmap van de leverancier. De enige manier om de EOL-datum te weten is om je leveranciersovereenkomst te controleren.
Voor deze embedded scenario's is het bepalen van de ondersteuningstatus vaak een handmatige onderzoeksactiviteit — en een van de meest tijdrovende onderdelen van een FDA-indiening.
Een Praktisch Kader om Dit Goed te Doen
Gezien al deze complexiteit, wat zou een fabrikant van medische apparaten eigenlijk moeten? Hier is een gelaagde benadering die voortbouwt op geautomatiseerde fundamenten tot menselijke supervisie.
Laag 1: Maak gebruik van Bekende EOL Databases
Begin met wat al gedocumenteerd is. Databases zoals endoflife.date bieden gestructureerde EOL/EOS-gegevens voor honderden bekende producten — programmeertalen, frameworks, besturingssystemen, databases en meer. Dit dekt niet je volledige SBOM, maar het behandelt de "grote stenen" — de belangrijkste componenten die het meeste risico vertegenwoordigen.
Voor componenten met bekende EOL-datums is de mapping rechttoe rechtaan: als de EOL is verstreken, wordt de component niet langer onderhouden. Als de EOS is verstreken, is de ondersteuning geëindigd. Als het product verouderd is, beschouw het dan als verlaten.
Laag 2: Automatiseer Inferentie vanuit Pakket- en Repository Metadata
Voor de lange staart van open-source componenten zonder formele EOL-gegevens, stel geautomatiseerde controles in:
Pakket versheid: Raadpleeg het relevante pakketregister. Als de laatste versie binnen een configureerbare drempel (meestal 365 dagen) is gepubliceerd, classificeer dan als actief onderhouden.
Repository-activiteit: Controleer de laatste commitdatum van de bronnrepository. Als commits recent zijn, is dat een positief signaal.
Verouderingsvlaggen: Controleer of het pakket of de repository expliciet is verouderd of gearchiveerd.
Combineer deze signalen met redelijke standaarden: als zowel het register als de repository geen activiteit tonen die jouw drempel overschrijdt, classificeer dan als niet langer onderhouden. Als de repository gearchiveerd is of het pakket is verouderd, classificeer dan als verlaten.
Deze geautomatiseerde aanpak zal niet perfect zijn — sommige actieve projecten geven gewoon zelden uit — maar het biedt een verdedigbare basislijn die het grootste deel van je SBOM dekt.
Laag 3: Handmatige Overrides met Audit Trails
Automatisering zal je voor 70-80% van de weg brengen. De rest vereist menselijk oordeel. Jouw team heeft de mogelijkheid nodig om:
Geautomatiseerde classificaties te overschrijven — Een beveiligingsingenieur kan weten dat een schijnbaar inactief project in werkelijkheid wordt onderhouden door een intern team of een commerciële leverancier onder contract.
Expliciete EOL-datums in te stellen — Voor propriëtaire componenten of door de leverancier ondersteunde bibliotheken, voer handmatig de contractvervaldatum in.
Rechtvaardigingen te documenteren — Wanneer de ondersteuningsstatus werkelijk niet kan worden bepaald, noteer waarom. "Component XYZ is een vendor C-bibliotheek zonder openbare repository of registeraanwezigheid. De oorspronkelijke auteur reageert niet. We hebben het geclassificeerd als ongespecificeerd en opgenomen in onze risicoanalyse" is een legitieme rechtvaardiging.
Deze overrides moeten worden bijgehouden met volledige audit trails — wie wat heeft veranderd, wanneer en waarom — omdat de FDA kan vragen.
Een praktijkvoorbeeld: het OpenSSL-probleem
Overweeg een medisch apparaat dat OpenSSL 1.1.1 gebruikt — een van de meest wijdverspreide cryptografische bibliotheken ter wereld. Op upstream niveau bereikte OpenSSL 1.1.1 zijn officiële Einde van Leven op 11 september 2023. Een geautomatiseerd systeem zou dit correct markeren en de component classificeren als "Niet Langer Onderhouden." Zaak gesloten?
Niet noodzakelijk. Als het apparaat draait op Ubuntu 20.04 LTS, brengt Canonical beveiligingsfixes voor OpenSSL 1.1.1 terug als onderdeel van hun langetermijnondersteuningscommitment. Het upstream project is aan het einde van zijn leven, maar de specifieke build die jouw apparaat gebruikt ontvangt nog steeds patches via jouw distributieleverancier.
Dit is een onderscheid dat automatisering alleen niet kan maken. De geautomatiseerde laag markeert het risico. De handmatige override legt de nuance vast:
> "OpenSSL 1.1.1 upstream is EOL, maar ons apparaat gebruikt de door Ubuntu 20.04 LTS onderhouden build. Canonical biedt beveiligingspatches onder ons ondersteuningscontract tot april 2025. EOL-datum ingesteld op contractverval."
Die override — gedocumenteerd met een rechtvaardiging en gekoppeld aan een specifiek ondersteuningscontract — is precies het soort bewijs dat de FDA verwacht.
Vermenigvuldig dit nu over elke component in een complex apparaat, en de behoefte aan een gestructureerd overridesysteem met audit trails wordt duidelijk.
Laag 4: Organisatorische Beleidslijnen
Verschillende organisaties hebben mogelijk verschillende drempels en regels nodig. Een component die zes maanden inactief is geweest, kan in de ene context acceptabel zijn, maar verontrustend in een andere. Organisaties moeten in staat zijn om:
De activiteitsdrempels te configureren die worden gebruikt voor automatische classificatie
Organisatiebrede overrides in te stellen voor componenten die ze onafhankelijk hebben geverifieerd
Beleidslijnen te definiëren die componenten met bepaalde ondersteuningsstatussen voor beoordeling markeren
Laag 5: Continue Monitoring
De ondersteuningsstatus is geen beoordeling op een specifiek moment. Een component die actief werd onderhouden toen je jouw premarket-aanvraag indiende, kan zes maanden later verlaten worden. Continue monitoring — het regelmatig herberekenen van de ondersteuningsstatus en het waarschuwen wanneer componenten overgaan naar verontrustende toestanden — is essentieel om jouw cybersecurity-risicoprofiel tijdens de levenscyclus van het apparaat te handhaven.
Laag 6: Mensen en Proces
Technologie en gegevens zijn slechts een deel van de oplossing. Een van de meest onderschatte uitdagingen is de organisatorische: wie is eigenlijk verantwoordelijk voor dit werk?
In de meeste bedrijven die medische apparaten produceren is het antwoord onduidelijk — en dat is het probleem.
Ontwikkeling bouwt de software en kiest de componenten — maar gaat verder naar de volgende release. Het bijhouden van de levenscyclusstatus van honderden afhankelijkheden maakt geen deel uit van hun dagelijkse workflow.
Beveiliging begrijpt het risico van niet-ondersteunde componenten — maar mist vaak de context van waarom een specifieke versie is gekozen of of een interne fork wordt onderhouden.
Regulatory is verantwoordelijk voor de FDA-indiening — maar is volledig afhankelijk van engineering voor het leveren van de gegevens. Ze kunnen niet bepalen of busybox 1.35.0 in een Yocto-build nog steeds patches ontvangt.
Product/Aankoop beheert de leverancierscontracten die de EOL-datums bepalen — maar maakt mogelijk geen verbinding tussen een contractvernieuwing en het cybersecurity-risicoprofiel van een apparaat dat al op de markt is.
Geen enkele persoon heeft het volledige beeld. De firmware-ingenieur weet dat de kernel-fork wordt onderhouden. Aankoop weet dat het BSP-ondersteuningscontract volgend jaar afloopt. Het open-source programmabureau houdt de gemeenschapsgezondheid bij voor belangrijke afhankelijkheden.
De organisaties die dit goed aanpakken, vestigen duidelijke, cross-functionele eigendom — definiëren wie de ondersteuningsstatusclassificaties beoordeelt, wie veranderingen monitort, en wie records bijwerkt wanneer een leverancierscontract wordt vernieuwd of een component wordt vervangen. Zonder deze proceshelderheid levert zelfs de beste tooling onvolledige resultaten op. De moeilijkste gegevens om vast te leggen zijn de institutionele kennis die in de hoofden van mensen leeft, niet in pakketregisters.
Wat moet veranderen
De huidige staat van zaken is werkbaar maar verre van ideaal. Verschillende zaken zouden helpen:
SBOM-standaarden hebben inheemse ondersteuningsstatusvelden nodig. Zowel SPDX als CycloneDX zouden gestandaardiseerde, machine-leesbare velden voor ondersteuningsniveau en EOL/EOS-datums moeten bevatten. Leveranciersspecifieke eigenschappen en CSV-zijkanalen zijn niet duurzaam. De vereisten van de FDA zijn duidelijk - de standaarden moeten deze weerspiegelen.
Pakketregistraties hebben betere levenscyclusmetadata nodig. Als npm, PyPI en Maven Central gestructureerde EOL- en ondersteuningsstatusinformatie naast versiegegevens zouden blootstellen, zou het hele ecosysteem profiteren. Sommige registraties bewegen in deze richting, maar de adoptie is ongelijkmatig.
Het embedded ecosysteem heeft betere tooling nodig. Buildroot en Yocto genereren gedetailleerde manifesten van wat ze bouwen, maar het in kaart brengen van die manifesten naar upstream ondersteuningsstatus is grotendeels een handmatig proces. Betere integratie tussen embedded build-systemen en SBOM/ondersteuningsstatus-tools zou de last voor fabrikanten van apparaten aanzienlijk verminderen.
Industriesamenwerking over EOL-gegevens - en OpenEoX leidt de weg. Gemeenschapsprojecten zoals endoflife.date hebben catalogus EOL-datums voor populaire producten gestart, maar wat ontbreekt, is een door de industrie gesteunde standaard voor hoe levenscyclusgegevens gestructureerd en uitgewisseld moeten worden. Dat is precies wat OpenEoX beoogt te bieden.
Gelanceerd in december 2023 als een OASIS Technische Commissie, wordt OpenEoX gesteund door Cisco, Dell, Microsoft, Red Hat, Qualys en anderen - met ook een bijdrage van CISA. De standaard definieert duidelijke levenscyclusfasen die direct overeenkomen met wat de FDA vraagt:
Einde van de verkoop - leverancier stopt met het accepteren van nieuwe bestellingen
Einde van de beveiligingsondersteuning - beveiligingspatches worden niet meer uitgegeven (de kritieke voor medische apparaten)
Einde van levensduur - volledige beëindiging, geen verdere ondersteuning van enig type
De belangrijkste inzicht achter OpenEoX is dat het bestaande standaarden niet vervangt - het vult de kloof tussen hen. Je SBOM vertelt je wat er in je apparaat zit. VEX en CSAF vertellen je welke kwetsbaarheden van toepassing zijn. OpenEoX voegt het ontbrekende stuk toe: hoe lang elk component wordt ondersteund.
De specificatie is nog in actieve ontwikkeling (v1.0 is in de maak), maar de richting is duidelijk en de steun van de industrie is aanzienlijk. Voor fabrikanten van medische apparaten is OpenEoX het volgen waard. Het lost de deadline voor indiening van vandaag niet op, maar het vertegenwoordigt waar de industrie naartoe gaat - naar een universeel, machine-leesbaar formaat voor levenscyclusgegevens dat door elke tool kan worden geproduceerd en geconsumeerd.
De conclusie
De ondersteuningsstatusvereisten van de FDA bestaan om een goede reden: onbeheerde software in medische apparaten is een kwestie van patiëntveiligheid. Maar het voldoen aan deze vereisten is echt moeilijk — niet omdat fabrikanten niet bereid zijn, maar omdat de data-infrastructuur nog niet volledig bestaat.
De weg vooruit omvat een combinatie van geautomatiseerde afleiding, gecureerde databases, handmatige toezicht en — cruciaal — betere tools.
Bij Interlynk hebben we infrastructuur gebouwd die specifiek is ontworpen om deze kloof aan te pakken — door geautomatiseerde afleiding van ondersteuningsniveaus over pakketregistraties en bronrepositories, gecureerde EOL-databases, handmatige override-workflows met vervaldatums, en volledige audittrails die zijn ontworpen voor FDA-toezicht. Elke laag van het kader dat in dit artikel wordt beschreven, weerspiegelt echte uitdagingen die we hebben opgelost voor fabrikanten van medische apparaten die navigeren door premarket-indieningen.
Als je moeite hebt met ondersteuningsstatusdata, ben je niet alleen. De uitdaging is echt — maar het is oplosbaar, en de tools voltooien zich snel.
Interlynk biedt SBOM-beheer en tools voor softwareleveringsketenbeveiliging die speciaal zijn ontwikkeld voor gereguleerde industrieën. Om meer te leren over hoe we omgaan met de vereisten voor ondersteuningsstatus van de FDA, bezoek interlynk.io.