De Minimum Elements 2026 van het CISA vervangen de NTIA-baseline van 2021 en leggen de lat aanzienlijk hoger. Compliance is echter slechts één van de vier onafhankelijke tests die een SBOM succesvol moet doorstaan. Deze gids behandelt nauwkeurigheid, volledigheid, structuur en compliance, legt uit waarom de vereisten van de FDA en het BSI van elkaar verschillen, en beschrijft hoe u alle vier de aspecten bij elke build kunt meten met behulp van sbomqs.
SBOM-compliance, -kwaliteit en Minimum Elements
In juli 2026 publiceerden CISA en haar partnerinstanties de 2026 Minimum Elements for a Software Bill of Materials, ter vervanging van de NTIA-basislijn die de categorie sinds 2021 had bepaald. De nieuwe versie voegt meerdere velden toe die de eerdere basislijn niet bevatte, zoals component-hashes, licentie-informatie, de naam van de tool die de SBOM heeft gegenereerd, en de context waarin die is gemaakt. Ook actualiseert die meerdere velden zodat de data makkelijker machinaal te verwerken is. [1]
Dat is een betekenisvolle stap vooruit. En het wordt makkelijk verkeerd begrepen.
Telkens als er een nieuwe set minimum elements verschijnt, is de industrie geneigd die te behandelen als een definitie van hoe een "goede" SBOM eruitziet. Teams controleren of de vereiste velden aanwezig zijn, bevestigen dat het document de validatie doorstaat, en gaan verder.
Precies daar begint het probleem.
Een lijst met minimum elements beantwoordt één vraag: voldoet deze SBOM aan een bepaald kader? Compliance is belangrijk. Het is iets anders dan kwaliteit, en het is geen universeel doel. Verschillende teams, sectoren en toezichthouders verwachten verschillende informatie uit dezelfde SBOM.
Een SBOM moet vier filters doorstaan
In plaats van je af te vragen of een SBOM simpelweg "goed" is, is het nuttiger om te vragen wat je ermee moet kunnen. In de praktijk moet een betrouwbare SBOM vier onafhankelijke tests doorstaan, en elke test kan op een andere manier falen.
Filter | De vraag die het beantwoordt |
|---|---|
Nauwkeurigheid | Vormen de data een accurate weergave van de software die je daadwerkelijk hebt uitgeleverd? |
Volledigheid | Bevat de SBOM genoeg van de juiste informatie voor het beoogde gebruik? |
Structuur | Voldoet die aan de SPDX- of CycloneDX-specificatie waarvan die zegt gebruik te maken? |
Compliance | Voldoet die aan de eisen van het specifieke wettelijke of organisatorische kader dat voor jou geldt? |
Deze filters zijn onafhankelijk van elkaar. Een SBOM kan structureel perfect zijn en toch de verkeerde software beschrijven. Die kan voldoen aan de CISA-2026-basislijn en toch de informatie missen die je team voor kwetsbaarheidsrespons nodig heeft. Die kan intern accuraat en bruikbaar zijn en toch tekortschieten ten opzichte van wat een toezichthouder vereist.
Daarom zijn "wij genereren SBOMs" en "wij genereren SBOMs waarop we kunnen vertrouwen" heel verschillende uitspraken.
1: Nauwkeurigheid
Nauwkeurigheid is het filter waarvan de meeste teams aannemen dat ze het op orde hebben, en één van de minst geteste.
Een SBOM is een verzameling beweringen: deze componenten zijn aanwezig, dit zijn hun versies, dit zijn hun identificatoren. Als die beweringen fout zijn, is elk proces dat erop voortbouwt aangetast. Betere opmaak kan onjuiste data niet repareren.
De problemen zijn vaak subtiel. Een scan op broncodeniveau meldt misschien een bibliotheek die de uiteindelijke build nooit linkt. Een versie wordt afgekapt of gegokt. Een componentnaam wordt aan het verkeerde pakket gekoppeld omdat dezelfde naam in meerdere ecosystemen voorkomt. Het resulterende document kan gezaghebbend ogen, de schemavalidatie doorstaan en toch een openssl-versie vermelden die niet echt in het product zit.
Wanneer de volgende OpenSSL-kwetsbaarheid bekend wordt, kan die ene onjuiste regel je team een release laten onderzoeken die nooit getroffen was. Erger nog, die kan ertoe leiden dat een release die wél getroffen was, wordt afgedaan.
Nauwkeurigheid kun je niet beoordelen door de voltooide SBOM op zichzelf te bekijken. Die moet worden getoetst aan de manier waarop de software daadwerkelijk is gebouwd, wat de genereermethode net zo belangrijk maakt als het bestandsformaat.
Een SBOM uit de verkeerde build-context is geen iets zwakkere versie van de juiste SBOM. Het is een zelfverzekerde beschrijving van software die je niet hebt uitgeleverd.
2: Volledigheid voor het gebruiksdoel
Het woord "volledig" klinkt absoluut, maar SBOM-volledigheid is altijd gebonden aan een doel. Hetzelfde document kan volledig zijn voor de ene workflow en ernstig ontoereikend voor de andere.
Neem twee teams die met dezelfde SBOM werken. Een softwarecomplianceteam heeft misschien licentie-expressies, copyrightverklaringen en bronlocaties voor elke component nodig om de juridische review af te ronden en aan attributieverplichtingen te voldoen. Een productsecurityteam hecht meer waarde aan precieze versies en machinaal oplosbare identificatoren zoals purl en CPE, zodat zijn tools componenten kunnen matchen met bekende kwetsbaarheden.
Een SBOM kan uitgebreide licentie-informatie bevatten en nauwelijks bruikbare purls. Dat maakt die waardevol voor het complianceteam en vrijwel onbruikbaar voor een incident responder. Het omgekeerde komt net zo vaak voor.
De nuttige vraag is niet "is deze SBOM volledig?". Die is "is deze SBOM volledig voor de taak die we ermee moeten uitvoeren?".
Volwassen SBOM-programma's definiëren volledigheid per gebruiksdoel en build-pad. Een containerrelease heeft misschien applicatie-afhankelijkheden, base-image-pakketten en de relaties daartussen nodig. Een licentieworkflow vereist mogelijk een geldige SPDX-expressie voor elke component voordat de release mag worden uitgeleverd. Volledigheid is een bewuste keuze per gebruiksdoel, geen enkel vinkje dat een SBOM zet of mist.
3: Structurele geldigheid
Structurele geldigheid is het smalste van de vier filters en meestal het makkelijkst te automatiseren. De vraag is eenduidig: voldoet het document aan de SPDX- of CycloneDX-specificatie waarvan het zegt gebruik te maken? Dat omvat de juiste velden, de correcte datatypes en validatie tegen het relevante schema.
Het SPDX-project biedt online validatietools, bibliotheken en build-integraties om programmatisch met SBOM-documenten te werken. [2]
Dit filter is essentieel. Een misvormde SBOM kun je niet betrouwbaar inlezen, vergelijken, ondertekenen, opslaan of scannen. Structurele geldigheid is een fundament, en het is geen kwaliteitsscore.
Een schemavalidator kan bevestigen dat een document correct is opgebouwd. Die kan niet zeggen of de componentenlijst accuraat is, of het document genoeg informatie voor je workflow bevat, of dat het voldoet aan de eisen van de toezichthouder aan wie je verantwoording aflegt.
Een validator die alleen de structuur controleert, geeft een groen licht dat veel minder betekent dan het lijkt. Structuur is het filter dat een tool direct kan beantwoorden, en juist daarom wordt het zo vaak voor het geheel aangezien. Als je kiest tussen de twee dominante formaten, laat onze gids CycloneDX vs SPDX zien waar elk het beste past.
4: Kadercompliance
Hier past de CISA-2026-publicatie, en hier ontstaat het grootste misverstand.
Compliance is geen eigenschap die een SBOM in het abstracte bezit. Een SBOM is conform aan een specifiek kader, en die kaders vragen niet allemaal dezelfde informatie.
De CISA 2026 Minimum Elements zijn nu de algemene federale basislijn in de VS. Sectorspecifieke toezichthouders en andere jurisdicties voegen eigen eisen toe, en sommige gaan bewust veel verder. Een SBOM kan aan het ene kader voldoen en het andere niet halen, en veel organisaties moeten aan meer dan één tegelijk voldoen.
Kader | Bouwt voort op | Belangrijke aanvullende eisen | Voor wie het geldt |
|---|---|---|---|
NTIA Minimum Elements (2021) | De oorspronkelijke basislijn | Leverancier, componentnaam en -versie, unieke identificatoren, afhankelijkheden, SBOM-auteur en tijdstempel | De referentiebasislijn die latere kaders uitbreiden |
CISA Minimum Elements (2026) | Vervangt de NTIA-basislijn van 2021 | Component-hashes, componentlicenties, naam van de genereertool, genereercontext en voor automatisering hernoemde velden | De huidige algemene federale basislijn (VS) |
FDA Section 524B | NTIA minimum elements en machineleesbare SBOM-verwachtingen | Support-status per component, end-of-support-datum, bekende kwetsbaarheden en in toenemende mate een VEX-bestand | Premarket-indieningen voor medische hulpmiddelen |
BSI TR-03183 | Gaat ver voorbij NTIA | Machineleesbare makerscontacten, SHA-256-hashes voor executable en broncode, recursief opgeloste afhankelijkheden, SPDX-licentie-identificatoren, bron- en executable-URI's en purls of CPE's | Producten die onder Duitslands CRA-gerichte richtlijn vallen |
De tabel is een nuttige waarschuwing tegen het gebruik van "conform" alsof het één categorie is.
FDA-eisen bouwen nog steeds voort op de NTIA-elementen van 2021 en voegen informatie toe die de CISA-2026-basislijn niet specifiek behandelt. Voor een medisch hulpmiddel kan het belangrijk zijn of een component actief wordt onderhouden, niet meer wordt onderhouden of is verlaten, en of die een bekende uitgebuite kwetsbaarheid heeft. Die verwachtingen behandelen we in FDA-SBOM-vereisten voor medische hulpmiddelen. [3]
BSI TR-03183 gaat op andere punten verder en vraagt om cryptografische hashes en oplosbare artefact-URI's die geautomatiseerde verificatie van de toeleveringsketen onder Europa's veranderende eisen ondersteunen. Onze gids over SBOM-vereisten voor de CRA splitst de TR-03183-velden in detail uit. [4]
Een SBOM die is ontworpen om aan de CISA-2026-basislijn te voldoen, kan alsnog worden afgewezen door een FDA-beoordelaar of tekortschieten ten opzichte van TR-03183.
Waarom "CISA-2026-conform" je toch kwetsbaar kan laten
Samen bezien tonen de vier filters de grens van elke minimum-elements-lijst.
Voldoen aan de CISA-2026-eisen betekent dat de SBOM de compliancetest voor één kader heeft doorstaan. Het zegt niets over de vraag of de componenten accuraat zijn geïdentificeerd, of het document de data bevat die je kwetsbaarheidsworkflow vereist, of dat het voldoet aan FDA- of BSI-eisen die ook op je product van toepassing kunnen zijn.
Niets daarvan is kritiek op de 2026 Minimum Elements. Een basislijn is bedoeld om een ondergrens te leggen en de standaard in de industrie op te tillen, en deze doet dat, vooral door het toevoegen van licentie- en hashdata en door velden beter geschikt te maken voor geautomatiseerde verwerking.
De fout is de ondergrens aanzien voor het plafond. Compliance is noodzakelijk. Op zichzelf is die niet voldoende en niet universeel.
Hoe je alle vier de filters continu meet
Deze filters vereisen geen vier losse programma's. Ze vereisen één workflow die elke dimensie meet en bij elke build draait, zo dicht mogelijk bij waar de SBOM wordt gegenereerd.
Het open-source-tool sbomqs van Interlynk scoort een SBOM over gewogen dimensies die nauw aansluiten bij deze vier filters. Structuur- en schemacontroles adresseren de structuur. Controles op identificatie, volledigheid, provenance, integriteit en licenties helpen nauwkeurigheid en gebruiksdoelvolledigheid te beoordelen. Controles op kwetsbaarheidsgereedheid bevestigen dat de purls en CPE's waarop je scanners leunen aanwezig zijn voordat je op de resultaten vertrouwt. Een aparte compliancemodus valideert tegen een benoemd kader in plaats van tegen een algemeen idee van wat een "goede" SBOM zou moeten bevatten. [5]
Een basaal CI-kwaliteitspoortje kan zo klein zijn als dit:
De juiste drempel hangt af van het risico en het doel van de release. Zet die hoger naarmate de release dichter bij productie en bij een toezichthouder komt, en bevestig de exacte scorebanden aan de hand van de actuele sbomqs-documentatie voordat je erop gate. [5]
Kwaliteitsscoring werkt het best samen met kaderspecifieke validatie. Een build van een medisch hulpmiddel moet worden getoetst aan FDA-verwachtingen. Een product onder Duitse CRA-richtlijn moet worden getoetst aan TR-03183. Geen van beide zou aan een one-size-fits-all-lijst mogen worden afgemeten.
Filter | Vraag die het beantwoordt | Voorbeeldcontrole |
|---|---|---|
Nauwkeurigheid | Zijn de data waar aan wat we hebben uitgeleverd? | Genereer de SBOM uit de echte build-context en scoor identificatie en integriteit. |
Volledigheid voor het gebruiksdoel | Bevat die wat deze workflow nodig heeft? | Vereis purls en CPE's voor kwetsbaarheidswerk, en licentie-expressies voor compliancewerk. |
Structuur | Kunnen machines die lezen en verwerken? | Valideer het opgegeven CycloneDX- of SPDX-document tegen zijn schema. |
Compliance | Bevat die de velden die ons kader vereist? | Draai het benoemde profiel voor NTIA, CISA 2026, FDA, BSI TR-03183 of een andere geldende standaard. |
De aanpak die op termijn standhoudt, is gaten op alle vier de filters en de resultaten voor elke build bewaren. Zo kun je kwaliteitsdrift opsporen voordat een auditor of een beveiligingsincident die als eerste vindt.
De conclusie
De CISA 2026 Minimum Elements zijn een welkome verbetering van de SBOM-basislijn, en organisaties zouden ze serieus moeten nemen. De basislijn is een startpunt, geen eindpunt.
Een minimum-elements-lijst is een compliancecontrole tegen één kader. Compliance is één van vier filters die bepalen of een SBOM echt bruikbaar is.
De SBOMs waarop teams kunnen vertrouwen, doorstaan alle vier de tests. Ze geven de uitgeleverde software accuraat weer. Ze bevatten de informatie voor de taak van dat moment. Ze zijn structureel geldig, zodat machines ze kunnen verwerken. En ze voldoen aan de eisen van het kader dat voor de release geldt, of dat nu CISA 2026, FDA Section 524B, BSI TR-03183 of meerdere tegelijk is.
Wie alleen compliance meet, kan SBOMs blijven produceren die een checklist doorstaan en falen zodra iemand ze daadwerkelijk moet gebruiken.
Wil je zien hoe je SBOMs presteren over alle vier de filters? Draai er één door sbomqs, het open-source-toolkit van Interlynk, en valideer die tegen het kader dat op je product van toepassing is voordat de SBOM in productie of bij een toezichthouder belandt.
Interlynk geeft security- en complianceteams SBOMs waarop ze kunnen vertrouwen: gegenereerd uit de echte build, bij elke build gescoord op kwaliteit, gevalideerd tegen het geldende kader en continu bewaakt over de levenscyclus. Genereer in CycloneDX of SPDX en beantwoord de blootstellingsvraag in minuten. Plan een demo · Gratis starten. Vertrouwd door security- en complianceteams bij meer dan 100 gereguleerde bedrijven.
Referenties
CISA en partnerinstanties, 2026 Minimum Elements for a Software Bill of Materials: https://www.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom
SPDX-project, tools en bibliotheken: https://spdx.dev/use/tools/
Interlynk, FDA-SBOM-vereisten voor medische hulpmiddelen: https://www.interlynk.io/nl/bronnen/fda-sbom-vereisten-medische-hulpmiddelen
Interlynk, SBOM-vereisten voor de CRA (BSI TR-03183): https://www.interlynk.io/nl/bronnen/sbom-vereisten-cra
Interlynk, sbomqs: https://github.com/interlynk-io/sbomqs
Let op: deze Nederlandse versie is een vertaling. Laat die vóór publicatie controleren door een moedertaalspreker met vakkennis. Bevestig ook de interne links naar de gelokaliseerde NL-pagina's zodra hun slugs vaststaan.