Je leverancier stuurde je een SBOM. Kun je die echt vertrouwen?
| Interlynk
Een leveranciers-SBOM is een bewering, geen geverifieerd feit. Hier lees je of de ontvangen SBOM goed genoeg is om op te handelen, gekaderd door het ENISA-advisory en gescoord met sbomqs.
Overzicht
Steeds meer teams vragen hun leveranciers om een SBOM, en steeds meer leveranciers sturen er een terug. Dat is vooruitgang. Maar het ontvangen van een bestand zegt heel weinig over de vraag of het de software die je geleverd kreeg accuraat beschrijft.
De SBOM kan zijn gegenereerd uit een broncodeboom die verschilt van de uitgeleverde binary. Hij kan transitieve afhankelijkheden of gebundelde componenten weglaten. Of zijn component-identificatoren kunnen te zwak zijn om een betrouwbare match met kwetsbaarheidsdata te ondersteunen.
In elk van die gevallen kan de organisatie zeggen dat ze een SBOM heeft. De moeilijkere vraag is of ze erop kan vertrouwen.
In oktober 2026 publiceerde ENISA een Technical Advisory for Software Bill of Materials die dit als een levenscyclusprobleem behandelt: generatie, validatie, distributie en de dreigingen voor de SBOM-integriteit onderweg. Dat is een nuttig kader, en het is een actuele aanleiding om iets te verduidelijken dat vaak onuitgesproken blijft. SBOM's verzamelen is niet het doel. Erop kunnen handelen wel.
De lijn die je moet vasthouden luidt: meet je SBOM-programma niet af aan hoeveel bestanden je verzamelt. Meet het af aan hoe zeker je ze kunt gebruiken om een beveiligingsbeslissing te nemen. Dit bericht zet de drie vertrouwensniveaus uiteen die een SBOM moet verdienen, vijf concrete controles voor een leveranciers-SBOM, en hoe je kwaliteit in de praktijk scoort met sbomqs zonder te overdrijven wat een score bewijst.
Belangrijkste feiten
Een SBOM ontvangen is niet hetzelfde als betrouwbare transparantie. Een SBOM is een bewering over de softwaresamenstelling. Hij moet beoordeeld worden voordat je erop vertrouwt.
Er zijn drie vertrouwensniveaus: syntactische geldigheid (laat hij zich parsen en is hij conform), inventariskwaliteit (zijn de componenten volledig en bruikbaar) en artefactvertrouwen (beschrijft hij wat je daadwerkelijk geleverd kreeg). Het ene niveau halen geeft je de andere niet.
Een quality score legt zwakke plekken bloot; hij certificeert geen waarheid. Een tool als sbomqs markeert ontbrekende velden, zwakke identificatoren en afwezige integriteitsdata. Het kan niet bewijzen dat een leverancier elk component heeft bekendgemaakt of dat een binary overeenkomt met de inventaris.
Dekking bepaalt de bruikbaarheid. De SBOM moet de componenten dekken die relevant zijn voor het product en het beoogde beveiligingsgebruik. Afhankelijk van de software kan dat transitieve afhankelijkheden, gebundelde runtimes, statische bibliotheken, leveranciers-SDK's, besturingssysteempakketten of via binaire analyse geïdentificeerde componenten vereisen. Een manifest alleen is mogelijk niet genoeg.
Geldigheid is geen integriteit. Een volkomen geldige SBOM kan het geleverde artefact alsnog niet beschrijven. Release-traceerbaarheid vraagt apart bewijs: hashes, handtekeningen en build-provenance kunnen helpen een SBOM aan een release te koppelen en artefactidentiteit of -herkomst vast te stellen, maar ze bewijzen afzonderlijk niet dat de inventaris volledig is.
Een SBOM is een bewering, geen geverifieerd feit
Wees onomwonden over wat een leveranciers-SBOM is. Het is een uitspraak van de leverancier die zegt: "hier is wat wij denken dat er in dit product zit." Het is bewijs, en nuttig bewijs, maar het bewijst zichzelf niet. De leverancier kan hem uit de verkeerde invoer hebben gegenereerd, kan tooling gebruiken die hele klassen componenten mist, of weet simpelweg niet alles wat een complex product bevat.
Het bestand als vaststaand feit behandelen is hoe teams eindigen met een verzameling SBOM's die ze niet kunnen gebruiken wanneer er een kwetsbaarheid opduikt. De nuttigere houding is die van een beveiligingsbeoordelaar bij elke leveranciersbewering: accepteer hem, beoordeel hem dan. De rest van dit bericht laat zien hoe je die beoordeling efficiënt doet.
Drie vertrouwensniveaus
Voor praktische leveranciersbeoordelingen helpt het om SBOM-vertrouwen op te splitsen in drie vragen. Deze niveaus zijn een werkkader om een SBOM te beoordelen, geen officiële classificatie van ENISA of CISA, en ze zijn niet uitwisselbaar. Ze verwarren is de meest voorkomende fout in SBOM-programma's.
Syntactische geldigheid. Laat het bestand zich parsen, en is het conform CycloneDX of SPDX. Dit is de ondergrens. Een validator of schemacontrole beantwoordt dat. Het is noodzakelijk en het is het zwakste van de drie, want een bestand kan onberispelijke JSON zijn en toch de verkeerde software beschrijven.
Inventariskwaliteit. Zijn de componenten ondubbelzinnig geïdentificeerd, met versies en relaties, en is de inventaris volledig genoeg om nuttig te zijn. Hier zit het grootste deel van de dagelijkse waarde en van het falen. Een geldige SBOM met vage identificatoren of een oppervlakkige componentenlijst ondersteunt het matchen met kwetsbaarheidsdata niet, en daar draait het juist om.
Artefactvertrouwen. Is er bewijs dat deze SBOM overeenkomt met het exacte software-artefact dat de leverancier heeft geleverd. Dit is het moeilijkste niveau en het vaakst overgeslagen. Een uit een broncodeboom gegenereerde SBOM kan geldig en van hoge kwaliteit zijn en toch niet de uitgeleverde binary beschrijven, omdat er tussen bron en release iets is veranderd.
Een leveranciers-SBOM kan het eerste niveau halen, het tweede redelijk goed doen en op het derde niets bieden. Weten welk niveau je voor je hebt, vertelt je hoeveel gewicht het bestand kan dragen.
Vijf controles voor een leveranciers-SBOM
Voer deze doorloop uit op elke SBOM die een leverancier je overhandigt. Voor elke controle dezelfde vier punten: wat te inspecteren, waarom het telt, hoe falen eruitziet en wat je daarna doet.
1. Identiteit
Inspecteer hoe componenten worden geïdentificeerd. Zoek naar ondubbelzinnige identificatoren zoals package URLs (purl) en CPE's, met concrete versies, niet alleen namen.
Waarom het telt: matchen met kwetsbaarheidsdata is slechts zo goed als de identificatoren. Als een component in deze SBOM anders wordt benoemd dan in een databron, mislukt de match stilzwijgend.
Hoe falen eruitziet: componenten met namen maar zonder versies, ontbrekende of inconsistente purls, of hetzelfde component dat in de eigen SBOM's van de leverancier verschillend wordt geïdentificeerd.
Wat te doen: vraag de leverancier opnieuw te genereren met correcte identificatoren, of behandel de zwak geïdentificeerde componenten als een bekend hiaat dat je handmatig moet oplossen.
2. Dekking
Inspecteer hoe diep de inventaris reikt. Een echt product is meer dan zijn directe afhankelijkheden.
Waarom het telt: een kwetsbaar of kwaadaardig component kan transitief zijn, gebundeld in een groter SDK, statisch gelinkt in firmware, of ingebakken in een container-image. Een SBOM die bij het bovenste niveau stopt, kan componenten missen die ertoe doen voor je beveiligingsbeoordeling.
Hoe falen eruitziet: een korte, nette lijst van directe afhankelijkheden zonder transitieve graaf, geen besturingssysteempakketten voor een container, of geen vendored en statische bibliotheken voor firmware.
Wat te doen: vraag welke generatiemethode de SBOM heeft voortgebracht en of hij uit het uiteindelijke artefact of uit een manifest is gebouwd. Een SBOM op basis van alleen een manifest voor een embedded of gecontaineriseerd product zou verdere vragen moeten oproepen over welke componenten hij vastlegt en welke buiten zijn bereik blijven.
3. Artefactafstemming en integriteit
Dit is de controle die teams overslaan, en het is de moeite waard hem op te splitsen in drie aparte vragen in plaats van één.
Ten eerste: kan de leverancier de SBOM koppelen aan een specifieke productversie of een release-artefact. Ten tweede: kun je verifiëren dat het artefact dat je ontving het artefact is dat de leverancier wilde leveren. Ten derde: is er bewijs dat de SBOM uit dat artefact is gegenereerd of het anderszins accuraat vertegenwoordigt.
Waarom het telt: een geldige, volledige SBOM voor de verkeerde build is misleidend op een manier waarop een ontbrekende SBOM dat niet is. De compromittering van de OVHcloud-CLI in oktober 2026, waarbij aanvallers de gepubliceerde binaries verwisselden terwijl de broncode schoon bleef, is de herinnering dat artefact en bron verschillende verhalen kunnen vertellen.
Wat de integriteitstools daadwerkelijk bewijzen, en niet: een component-hash identificeert een bepaald component-artefact. Een hash geeft een vingerafdruk van het release-artefact. Het vergelijken met een vertrouwde referentie-hash kan helpen verifiëren dat het geleverde artefact het verwachte is. Een handtekening kan verifiëren dat een document of artefact met een bepaalde sleutel is ondertekend, maar de betrouwbaarheid van die handtekening hangt ook af van hoe de sleutel en zijn identiteit worden geverifieerd. Provenance beschrijft hoe een artefact is gebouwd. Geen van deze bewijst op zichzelf dat de software goedaardig is of dat de SBOM elk component opsomt. Ze stellen afstemming en herkomst vast, geen veiligheid of volledigheid.
Hoe falen eruitziet: een SBOM zonder versiebinding, zonder hashes, zonder handtekening en zonder manier om te zien bij welke release hij hoort.
Wat te doen: vraag de leverancier de SBOM te koppelen aan een specifieke productrelease en, waar haalbaar, verifieerbaar bewijs te leveren dat de inventaris verbindt met het geleverde artefact. Dat kan artefact-hashes, een ondertekende SBOM of build-provenance omvatten. Verifieer wat elk bewijsstuk vaststelt in plaats van één ervan te behandelen als bewijs van volledigheid of veiligheid. Voor firmware, embedded software en alles met statisch gelinkte of door leveranciers aangeleverde componenten hier het hardst doorvragen, want daar lopen bron en artefact het meest uiteen.
4. Actualiteit en generatiecontext
Inspecteer wanneer en hoe de SBOM is gegenereerd. Zoek naar een tijdstempel, de genererende tool en de auteur of leverancier.
Waarom het telt: een SBOM die maanden geleden is gegenereerd, of vóór een latere buildstap die het artefact veranderde, beschrijft mogelijk niet meer wat je draait. De 2026 SBOM Minimum Elements breiden de metadata uit die beschikbaar zijn om een inventaris te beoordelen, waaronder generatiecontext, toolnaam en -versie, component-hashes en een SBOM-auteurshandtekening. Deze velden leveren nuttig bewijs over hoe de SBOM is geproduceerd en wat hij identificeert, al bewijzen ze niet onafhankelijk dat hij het geleverde artefact accuraat vertegenwoordigt.
Hoe falen eruitziet: geen tijdstempel, geen toolidentificatie, geen auteur, of een generatiedatum die vóór de release ligt die je kreeg.
Wat te doen: vraag om een SBOM die is gegenereerd als onderdeel van de build die jouw artefact voortbracht, niet een achteraf met de hand gemaakt eenmalig exemplaar.
5. Handelbaarheid
Inspecteer of je de SBOM daadwerkelijk kunt gebruiken om een beveiligingsvraag te beantwoorden. De praktische test: als een CVE of een advisory over een kwaadaardig pakket een component benoemt, kun je het dan tegen deze SBOM matchen en een betrouwbaar antwoord krijgen.
Waarom het telt: dit is de reden dat je de SBOM in de eerste plaats hebt aangevraagd. Al het voorgaande komt hier samen. Ons begeleidende stuk over wat een SBOM doet tijdens een supply chain-aanval behandelt de responskant in detail.
Hoe falen eruitziet: identificatoren die niet matchen met databronnen, dekking die te oppervlakkig is om een schoon resultaat te vertrouwen, of geen manier om de SBOM terug te koppelen aan het product en de versie in je omgeving.
Wat te doen: voer de bovenstaande controles uit, dicht de hiaten die ertoe doen voor je risicoprofiel, en bewaar de SBOM ergens waar hij doorlopend tegen kwetsbaarheidsdata kan worden gematcht, niet slechts opgeborgen.
De controles in de praktijk brengen met sbomqs
Deze controles met de hand uitvoeren over een stapel leveranciers-SBOM's schaalt niet. Daar komt een quality scorer van pas. sbomqs is een open-source tool voor het beoordelen van SBOM-kwaliteit, en het ENISA-advisory noemt het, naast eBay's sbomscorecard, onder de quality-scoring tools in zijn indicatieve open-source toolstack. ENISA noemt deze tools als onderdeel van het landschap; het certificeert of beveelt ze niet aan, en het advisory stelt uitdrukkelijk dat de lijst indicatief en niet uitputtend is. Interlynk onderhoudt sbomqs als open-source project.
sbomqs produceert een kwaliteitsscore van 0 tot 10 voor een CycloneDX- of SPDX-SBOM, uitgesplitst naar categorieën die nauw aansluiten bij de bovenstaande controles: identificatie, volledigheid, structurele conformiteit, integriteit, provenance, licentiëring, kwetsbaarheden en componentinformatie. Het kan scoren tegen NTIA- en BSI-TR-03183-2-profielen, wat nuttig is wanneer een specifieke baseline geldt. Het kan snel problemen aan het licht brengen zoals ontbrekende versies, zwakke componentidentificatie, onvolledige metadata en afwezige integriteitsvelden, en helpt beoordelaars hun handmatige onderzoek te richten op de hiaten die ertoe doen.
Nu de eerlijke grens, en die telt. Een quality score meet gedefinieerde aspecten van de structuur en inhoud van een SBOM, zoals of verwachte velden zijn ingevuld, component-identificatoren aanwezig zijn, afhankelijkheidsrelaties zijn gedocumenteerd en integriteits- of provenance-informatie is opgenomen. Het kan niet vaststellen dat de inventaris elk component bevat dat daadwerkelijk in de geleverde software aanwezig is. Als sbomqs "integriteit" hoog scoort, betekent dat dat de SBOM integriteitsdata zoals component-hashes bevat, niet dat iemand de geleverde binary daartegen heeft geverifieerd. Een hoge score voor "volledigheid" betekent dat de verwachte velden zijn ingevuld, niet dat de leverancier daadwerkelijk elk component heeft bekendgemaakt. De score is een snelle, herhaalbare manier om zwakke plekken te vinden en SBOM's op een gemeenschappelijke schaal te vergelijken. Het is geen waarheidscertificaat, en geen enkele kwaliteitstool kan dat zijn. Met dat begrip gebruikt, maakt het de vijf controles tot iets dat je op schaal kunt uitvoeren en in de tijd kunt volgen.
Bekende onbekenden
Een volwassen SBOM-programma behandelt niet elk ontbrekend veld als een automatisch falen, want sommige hiaten zijn reëel en onvermijdelijk. Een leverancier kent mogelijk echt niet elk component in een complex product. Een door een leverancier aangeleverde binary kan zonder gedetailleerde metadata binnenkomen. Een statisch gelinkte afhankelijkheid kan moeilijk precies te identificeren zijn. Doen alsof deze niet bestaan, levert een slechter resultaat op dan ze benoemen.
Het ENISA-advisory maakt hetzelfde punt in zijn eigen bewoordingen en beveelt een gedocumenteerde behandeling van bekende onbekenden en ontbrekende metadata aan. Het doel is de hiaten zichtbaar in plaats van onzichtbaar te maken: vastleggen wat onbekend is, begrijpen waarom, en beslissen of die onzekerheid aanvaardbaar is voor het risicoprofiel van het product. Een medisch apparaat of een industriële besturing rechtvaardigt een lagere tolerantie voor onbekenden dan een interne tool. Een SBOM die eerlijk aangeeft wat hij niet kon bepalen, is betrouwbaarder dan een die volledig oogt omdat de generator stilzwijgend wegliet wat hij niet kon oplossen.
Waar Interlynk past
Deze drie taken zijn verschillend, en ze gescheiden houden is het hele punt.
sbomqs is het startpunt: een open-source manier om de kwaliteit van een SBOM te beoordelen en de zwakke plekken ervan bloot te leggen, de jouwe of die van een leverancier. Het is gratis uit te voeren en het is waar dit soort beoordeling begint.
lynkctl is voor generatie: het genereert build-bewuste SBOM's voor ondersteunde builds en softwareomgevingen en helpt teams transitieve afhankelijkheden, statische bibliotheken, leveranciers-SDK's, gebundelde runtimes en componenten in firmware en container-images vast te leggen die een aanpak op basis van alleen een manifest kan missen. Zo produceert een leverancier in de eerste plaats een SBOM die de bovenstaande controles doorstaat.
Het Interlynk-platform is de operationele laag: het neemt SBOM's en CBOM's op, beoordeelt hun kwaliteit, beoordeelt componenten op risico aan de hand van kwetsbaarheidsdata, beheert de VEX-uitspraken die je positie per product vastleggen, en stelt stakeholders op de hoogte wanneer een nieuwe openbaarmaking de blootstelling verandert van iets dat al is uitgeleverd. Onze gids over het operationaliseren van VEX behandelt die workflow, en onze notitie over de CISA 2026 Minimum Elements legt de baseline vast waarop de kwaliteitscontroles voortbouwen.
Geen van deze vervangt de andere, en een quality score vervangt noch de generatie noch de operationele workflow. Een leverancier of fabrikant heeft eerst een daadwerkelijk bruikbare inventaris nodig en moet die inventaris vervolgens verbinden met producten, releases, kwetsbaarheden en responsbeslissingen. Kwaliteitsscoring helpt je de inventaris te beoordelen die je hebt. Generatie helpt je betere inventarissen te produceren. Het platform verbindt die inventarissen met producten, kwetsbaarheden, VEX-beoordelingen en responsworkflows.
Conclusie
Een leveranciers-SBOM is een bewering over de softwaresamenstelling. Voordat je erop vertrouwt, beoordeel drie dingen: of het bestand geldig is, of de inhoud bruikbaar is, en of het het artefact dat je ontving accuraat vertegenwoordigt.
Vijf controles helpen die beoordeling te structureren: identiteit, dekking, artefactafstemming, actualiteit en handelbaarheid. Een quality scorer als sbomqs kan delen van de beoordeling herhaalbaar maken, maar kan niet certificeren dat de inventaris waar is.
SBOM's verzamelen was nooit het doel. Het doel is het punt te bereiken waarop een nieuwe kwetsbaarheid of een gecompromitteerd pakket een snel, betrouwbaar antwoord oplevert over welke van je producten getroffen zijn. Dat gebeurt alleen wanneer de inventarissen die je hebt goed genoeg zijn om op te handelen. Meet het programma daaraan af, niet aan de omvang van de map.
Veelgestelde vragen`
Hoe weet ik of een SBOM van goede kwaliteit is? Beoordeel hem op drie niveaus: laat hij zich parsen en is hij conform CycloneDX of SPDX, zijn zijn componenten goed genoeg geïdentificeerd en gedocumenteerd om nuttig te zijn, en is er bewijs dat hij het exacte artefact beschrijft dat je geleverd kreeg. Een quality scorer als sbomqs kan veel aspecten van structuur en inhoud snel beoordelen. De werkelijke inventarisdekking beoordelen en de afstemming met het geleverde artefact bevestigen vereist aanvullend bewijs en onderzoek.
Kan ik een SBOM vertrouwen die een leverancier me heeft gegeven? Niet bij ontvangst. Een SBOM is een bewering over de softwaresamenstelling, geen geverifieerd feit. Voer een kwaliteits- en dekkingscontrole uit, bevestig dat hij aan de specifieke release is gekoppeld, en beslis of eventuele hiaten aanvaardbaar zijn voor het risicoprofiel van dat product voordat je erop vertrouwt.
Wat is sbomqs en wat controleert het? sbomqs is een door Interlynk onderhouden open-source tool die de kwaliteit van een CycloneDX- of SPDX-SBOM scoort op een schaal van 0 tot 10, over categorieën waaronder identificatie, volledigheid, structurele conformiteit, integriteit, provenance, licentiëring en kwetsbaarheden, met beschikbare NTIA- en BSI-profielen. Het ENISA-SBOM-advisory noemt het onder de quality-scoring tools in zijn indicatieve toolstack.
Betekent een hoge SBOM-kwaliteitsscore dat de SBOM accuraat is? Nee. Een hoge score wijst op sterke resultaten over de kwaliteitscontroles die in de scoringconfiguratie zijn opgenomen. Het bewijst niet dat de leverancier elk component heeft bekendgemaakt of dat de geleverde binary overeenkomt met de inventaris. Zelfs een hoge score voor integriteitsgerelateerde controles stelt niet vast dat iemand het geleverde artefact tegen de SBOM heeft geverifieerd. Een score legt zwakke plekken bloot; het certificeert geen waarheid.
Wat moet een goede SBOM bevatten? Een nuttige SBOM moet componenten zo precies mogelijk identificeren, versies en afhankelijkheidsrelaties bevatten waar beschikbaar, en metadata over zijn generatie leveren, zoals de tool en het tijdstempel. De dekking moet het product en het beoogde gebruik van de SBOM weerspiegelen. Waar zekerheid op artefactniveau ertoe doet, kunnen hashes, handtekeningen of build-provenance aanvullend bewijs leveren dat de SBOM aan een specifieke release koppelt. De toepasselijke vereisten en de 2026 SBOM Minimum Elements bieden verdere richtlijnen.
Hoe verifieer ik dat een SBOM overeenkomt met de software die ik geleverd kreeg? Vraag of de SBOM is gekoppeld aan een specifiek release-artefact. Verifieer waar mogelijk het geleverde artefact tegen een onafhankelijk geauthenticeerde hash of handtekening, en zoek naar build-provenance of een attestatie die de SBOM aan dat artefact koppelt. Een ondertekende SBOM alleen bewijst niet dat zijn inventaris volledig is of dat hij de geleverde software accuraat vertegenwoordigt.
Bronnen
ENISA, Technical Advisory for Software Bill of Materials (v1.10, oktober 2026)
2026 Minimum Elements for a Software Bill of Materials (CISA en internationale partners, via ACSC)
AWS, "sbomqs and open source tools to quality-check your SBOMs"
Over Interlynk. Interlynk helpt teams SBOM's te genereren, beheren en operationaliseren over de hele software-leveringsketen. sbomqs, de open-source quality scorer, beoordeelt SBOM's aan de hand van NTIA, BSI en andere baselines. lynkctl produceert build-bewuste SBOM's voor embedded- en firmware-software, en legt gebundelde runtimes en transitieve, statische en SDK-componenten vast met precieze identificatoren. Het Interlynk-platform neemt SBOM's en CBOM's op, beoordeelt ze op volledigheid en kwaliteit, beoordeelt componenten op risico aan de hand van kwetsbaarheidsdata, beheert VEX-uitspraken en stelt teams op de hoogte wanneer de blootstelling verandert.
Een demo boeken · Gratis starten
Dit artikel is informatief en vormt geen beveiligings- of juridisch advies. Bevestig actuele standaarden, advisories en toolmogelijkheden aan de hand van de primaire bronnen voordat je handelt.