De FDA wil weten: Wordt uw software nog steeds ondersteund?
| 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: zoek elk component op, controleer of het wordt ondersteund en noteer de datum. In de praktijk blijkt dit echter veel complexer te zijn dan het lijkt. Dit is waarom.
De kloof in het SBOM-formaat
De twee dominante SBOM-standaarden — SPDX en CycloneDX — zijn niet ontworpen met het oog op de FDA-vereisten voor de ondersteuningsstatus.
SPDX (beheerd door de Linux Foundation) heeft geen ingebouwde velden voor het ondersteuningsniveau van componenten of data van het einde van de ondersteuning. Er is simpelweg geen plaats in het standaard SPDX-schema om uit te drukken dat "dit component niet langer wordt onderhouden" of dat "de ondersteuning eindigt op 30-06-2025". U kunt het annotatiemechanisme van SPDX of externe documentreferenties gebruiken, maar dit zijn tijdelijke oplossingen — geen gestructureerde, machine-leesbare velden die tooling consistent kan verwerken.
CycloneDX bevindt zich in een iets betere positie. Het ondersteunt een flexibel uitbreidingsmechanisme voor properties, waarmee u willekeurige sleutel-waarde-paren aan componenten kunt koppelen. Dit is hoe platforms zoals Interlynk de ondersteuningsstatus momenteel afhandelen — door aangepaste eigenschappen te schrijven zoals:
Maar er is een addertje onder het gras: dit zijn leveranciersspecifieke uitbreidingen en maken geen deel uit van de kernspecificatie van CycloneDX. Een andere tool die deze SBOM leest, heeft geen idee wat interlynk:component:support_level betekent, tenzij deze specifiek is gebouwd om dit te begrijpen. Er is geen universele, gestandaardiseerde manier om de ondersteuningsstatus in een van beide formaten uit te drukken.
Dit betekent dat organisaties vaak hun toevlucht nemen tot het exporteren van ondersteuningsgegevens als een apart CSV-bestand naast de SBOM, wat een gefragmentreerd beeld oplevert dat handmatige afstemming vereist. Het is functioneel, maar kwetsbaar.
Het probleem met open-source inferentie
Voor commerciële software is het bepalen van de ondersteuningsstatus relatief eenvoudig. U heeft een leverancier. U heeft een ondersteuningscontract. Het contract heeft een verloopdatum. Klaar.
Open source is een totaal andere wereld.
De meeste open-sourceprojecten publiceren geen formele tijdlijnen voor ondersteuning. Er is geen "End of Support"-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 motiveren waarom ze dat niet kunnen.
Dus hoe bepaalt u de ondersteuningsstatus van een open-source component? U leidt het af. En afleiding vereist gegevens uit meerdere bronnen:
Activiteit in de pakketregistratie — Wanneer is de laatste versie gepubliceerd op npm, PyPI, Maven Central, RubyGems of welk register het pakket zich ook bevindt? Als de nieuwste versie in het afgelopen jaar is uitgebracht, is dat een sterk signaal van actief onderhoud. Als er in drie jaar niets is gepubliceerd, is dat een waarschuwingssignaal (red flag).
Activiteit in de broncode-repository — Wanneer was de laatste commit in de GitHub-, GitLab- of Bitbucket-repository van het project? Is de repository gearchiveerd? Is deze expliciet gemarkeerd als verouderd (deprecated)?
Bekende EOL-databases — Projecten zoals endoflife.date (xeol.io) onderhouden gestructureerde gegevens over de end-of-life-data voor bekende softwareproducten. Deze dekken belangrijke frameworks, talen en besturingssystemen — maar ze vertegenwoordigen slechts een fractie van het totale ecosysteem.
Pakketafschrijvingsvlaggen — Sommige registers ondersteunen expliciete afschrijvingsmarkeringen. Met npm kunnen beheerders pakketten afschrijven. PyPI-pakketten kunnen worden ingetrokken (yanked). De acceptatie van deze mechanismen is echter inconsistent over de verschillende ecosystemen heen.
Het probleem is dat geen enkele bron een volledig beeld geeft. Een pakket vertoont misschien al twee jaar geen nieuwe releases in het register — maar de beheerder is actief bezig met commits en heeft simpelweg nog geen nieuwe release uitgebracht. Of een repository vertoont recente activiteit, maar dat zijn uitsluitend geautomatiseerde updates van afhankelijkheden — geen betekenisvol onderhoud.
Het bepalen van de ondersteuningsstatus vereist het correleren van signalen uit meerdere bronnen en het toepassen van professionele oordeelsvorming. Het is recherchewerk, geen simpele database-opdracht.
De omvang van ecosystemen
Een modern medisch hulpmiddel maakt niet slechts gebruik van een handvol bibliotheken. Een typische firmware- of applicatiestack kan honderden of zelfs duizenden afhankelijkheden bevatten binnen JavaScript, Python, Java, .NET, Rust, Go, C/C++ en meer — elk met miljoenen beschikbare pakketten en elk met verschillende conventies over hoe levenscyclusinformatie wordt gecommuniceerd.
Sommige ecosystemen stellen beheerders in staat om een pakket expliciet af te schrijven. Andere hebben helemaal geen afschrijvingsmechanisme. C- en C++-bibliotheken zijn vaak helemaal niet aanwezig in een pakketbeheerder — ze worden gedownload als bronarchieven of rechtstreeks in de build gecompileerd. Er is geen universele API die u kunt aanroepen om te vragen "wordt deze component nog ondersteund?" voor al deze systemen.
Dit betekent dat het leveren van een consistente ondersteuningsstatus over uw gehele SBOM ecosysteemspecifieke kennis en datapijplijnen vereist — een aanzienlijke infrastructurele uitdaging.
Het probleem met embedded en aangepaste builds
Medische hulpmiddelen draaien vaak op aangepaste Linux-builds die zijn gemaakt met buildsystemen zoals Buildroot of Yocto/OpenEmbedded. In tegenstelling tot typische software die vooraf gebouwde pakketten installeert, compileren deze systemen een heel besturingssysteem — kernel, systeembibliotheken, hulpprogramma's — rechtstreeks vanuit de broncode.
Dit voegt extra complexiteitslagen toe aan de ondersteuningsstatus:
De kwestie van upstream versus leveranciersforks — In embedded systemen hangt de ondersteuningsstatus vaak niet alleen af van het upstream-project, maar ook van door de leverancier aangepaste forks en langetermijncontracten. Een apparaat kan de Linux 5.15-kernel gebruiken, die een bekende upstream EOL-datum heeft — maar de versie die daadwerkelijk 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 registers — Embedded buildsystemen halen de broncode op voor honderden pakketten (OpenSSL, busybox, systemd, enz.) en compileren deze voor de doelhardware. Veel hiervan bestaan niet in pakketregisters zoals npm of PyPI, waardoor de gebruikelijke geautomatiseerde controles simpelweg niet van toepassing zijn. Elk component moet handmatig worden herleid naar het upstream-project.
Systeemeigen hardwarecomponenten — Board Support Packages van chipfabrikanten (NXP, TI, Qualcomm, enz.) bevatten eigen drivers en firmware met ondersteuningslevenscycli die gekoppeld zijn aan de productroadmap van de leverancier. De enige manier om de EOL-datum te achterhalen, is door uw leveranciersovereenkomst te controleren.
Voor deze embedded scenario's is het bepalen van de ondersteuningsstatus vaak een handmatig onderzoeksproces — 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.