De meeste teams die ik spreek, kunnen een SBOM genereren. Veel minder teams kunnen vertellen of die compleet is, wie hem heeft ondertekend, waar de versie van vorig jaar staat, of wat er gebeurt als een nieuwe CVE matcht met een van de componenten. In oktober 2026 publiceerde ENISA de Technical Advisory for Software Bill of Materials, en over die tweede reeks vragen gaat het. Dit artikel vat het advies samen en voegt aantekeningen uit ons eigen SCA-werk toe.
Wat het advies is, en wat niet
Het advies is de definitieve versie van een document dat begon als concept onder de titel “SBOM Landscape Analysis: Towards an implementation guide”. ENISA legde dat concept tussen 17 december 2025 en 23 januari 2026 ter consultatie voor en ontving 67 reacties. Het baseerde zich ook op de enquête SBOM Adoption State of Play 2026, gepubliceerd in juni 2026, en op een review door de SBOM-werkstroom van de CRA Expert Group tussen 31 juli en 11 september 2026. De feedback overtuigde ENISA om het concept om te zetten in een technisch advies, hetzelfde format als het advies over veilig gebruik van package managers.
Een paar dingen om te weten voordat u het leest:
- Het is geschreven voor organisaties die net met SBOM’s beginnen, vooral mkb-bedrijven en beheerders van open source. Het biedt bewust geen volwassenheidsmodel.
- Het is een handreiking. De aanbevelingen zijn niet verplicht, ENISA zegt dat het document geen juridische interpretatie van de CRA is, en sommige praktijken gaan verder dan wat de CRA eist.
- Het gaat alleen over software. Stuklijsten voor AI, hardware en cryptografie vallen erbuiten.
- Het valt onder de licentie CC BY 4.0 en volgt de principes van ENISA’s Secure by Design and Default Playbook.
ENISA gebruikt de CRA-definitie van een SBOM: een formeel register met details en toeleveringsketenrelaties van de componenten in de software-elementen van een product met digitale elementen. Daarna maakt het een punt dat het herhalen waard is voor iedereen die SBOM’s als compliancedocument behandelt. SBOM’s zijn volgens ENISA een fundamentele datalaag, geen complete beveiligingsoplossing. De waarde zit in wat u ermee doet: patchen, gedocumenteerde beslissingen over kwetsbaarheden, licentiecontroles en inkoop.
Het gat tussen wat afnemers nodig hebben en wat ze krijgen
Het advies citeert de State of Play-enquête door het hele document, en de cijfers verklaren waarom het meer tijd besteedt aan de levenscyclus dan aan het genereren.
| SBOM-diepte | Organisaties die dit nodig hebben | Organisaties die dit ontvangen |
|---|---|---|
| Alle primaire componenten en directe afhankelijkheden, met gedeclareerde known unknowns | 36% | 29% |
| Volledige diepteanalyse | 24% | 14% |
| Diepteanalyse inclusief gedeclareerde known unknowns | 27% | 12% |
Een “known unknown” is een component waarvan de afhankelijkheden niet konden worden bepaald, en dat als zodanig in de SBOM staat in plaats van stilzwijgend weggelaten te worden. Afnemers willen weten waar de blinde vlekken zitten.
Automatisering vertelt hetzelfde verhaal. 41% van de respondenten wil het genereren van SBOM’s voor elke build of release volledig automatiseren, maar slechts 26% verwacht SBOM-updates gedurende de hele ondersteuningsperiode volledig te automatiseren, en ongeveer 23% verwacht dat gedeeltelijk te doen. Een SBOM genereren is grotendeels een opgelost probleem. Hem nauwkeurig houden zolang het product wordt ondersteund, is dat niet.
Wat er in een SBOM hoort
ENISA definieert geen eigen lijst met velden. Het brengt de twee baselines in kaart waar de meeste organisaties mee te maken krijgen: TR-03183-2 van het Duitse BSI (versie 2.1.0) en de 2026 Minimum Elements for a Software Bill of Materials van CISA, in de zomer van 2026 gepubliceerd als gezamenlijke richtlijn met de NSA, de FBI en partnerorganisaties in andere landen.
De kern is in beide gelijk: wie de SBOM heeft gemaakt en wanneer, en per component de maker, naam, versie, identifiers, hash, licentie en afhankelijkheden. De verschillen zitten in de details.
| Alleen in BSI TR-03183-2 | Alleen in de CISA 2026 minimum elements |
|---|---|
| SBOM-URI | SBOM-versie |
| Aparte URI's voor de broncode van een component en de uitrolbare vorm | Naam en versie van het SBOM-dataformaat |
| Hash van de broncode van het component (optioneel) | Handtekening van de SBOM-auteur |
| Distributie-, oorspronkelijke en effectieve licentie als aparte velden | Naam en versie van de tool die de SBOM heeft gegenereerd |
| Eigenschappen voor executable, archief en gestructureerde data | Generatiecontext: vóór, tijdens of na de build |
| URL van de security.txt van de maker van het component (optioneel) | Hashalgoritme |
BSI wil ook een e-mailadres van de maker van de SBOM en van elke componentmaker, of een URL als er geen e-mailadres is. CISA vraagt om een naam.
Levert u aan klanten in Duitsland en de VS, genereer dan de vereniging van beide lijsten. Toolnaam en -versie, formaat en tijdstempel komen uit elke fatsoenlijke generator. De BSI-specifieke eigenschappen, de effectieve licentie en de handtekening vragen extra stappen in uw pipeline.
Formaten en typen
73% van de organisaties in de enquête gebruikt CycloneDX of SPDX, en het advies vergelijkt de huidige versies van beide.
| SPDX 3.0.1 | CycloneDX 1.7 | |
|---|---|---|
| Standaardisatie | SPDX 2.2.1 is ISO/IEC 5962:2021, SPDX 3.0 is een OMG-standaard, en SPDX 3 is in behandeling bij ISO | Bekrachtigd als ECMA-424, onderhouden via Ecma TC54, en in de fast track van ISO/IEC JTC 1 |
| Focus | Gedetailleerde componentmetadata voor licenties, herkomst en risicoanalyse over productlijnen heen | Securitytoepassingen: kwetsbaarheden volgen met native VEX, services en API's, cryptografische integriteit |
Voor de CRA werken ze allebei. Kies het formaat dat uw klanten en uw tools lezen. OWASP Dependency-Track neemt bijvoorbeeld alleen CycloneDX op. Hebt u beide nodig, dan zet Protobom van OpenSSF ze in elkaar om.
Het formaat is de helft van het verhaal. Wanneer u de SBOM genereert, bepaalt wat erin staat. ENISA gebruikt de zes SBOM-typen van CISA:
| Type | Gegenereerd uit | Typisch gebruik |
|---|---|---|
| Design | Het beoogde ontwerp, inclusief componenten die misschien nog niet bestaan | Architectuurbeslissingen, licentie-inkoop, threat modeling |
| Source | De ontwikkelomgeving, bronbestanden en gedeclareerde afhankelijkheden | Zicht op afhankelijkheden, vroege detectie van kwetsbaarheden |
| Build | Het buildproces: bronbestanden, opgeloste afhankelijkheden, gebouwde componenten en builddata | Naleving van regelgeving, kwetsbaarheidsbeoordeling, transparantie |
| Analyzed | Analyse van afgeronde artefacten zoals executables, pakketten, containers en VM-images, meestal met heuristieken; soms een third-party SBOM genoemd | Licentienaleving, verificatie van herkomst, risico's in de toeleveringsketen |
| Deployed | De software op een systeem, door SBOM's te combineren met analyse van de configuratie | Asset-inventaris, patchmanagement, configuratiebeheer |
| Runtime | Instrumentatie van het draaiende systeem, inclusief dynamisch geladen bibliotheken, plug-ins en geïnjecteerde agents | Dreigingsdetectie, beoordeling van het aanvalsoppervlak, runtimemonitoring |
Het nieuwe veld voor generatiecontext van CISA bestaat zodat een afnemer kan zien naar welk type hij kijkt. Voor een minimale werkende implementatie is ENISA duidelijk: begin met de build-SBOM, want dan zijn de afhankelijkheden het nauwkeurigst bekend.
De SBOM-levenscyclus
Het advies beschrijft de SBOM als een levenscyclus in zeven fasen, gebouwd rond vier principes: continu, betrouwbaar, bruikbaar en actueel.
- Build
- Genereren
- Valideren
- Ondertekenen
- Opslaan
- Gebruiken
- Onderhouden en bijwerken
Daarna maakt het van de levenscyclus een referentiearchitectuur voor een CI/CD-pipeline. Elke fase is een poort. Faalt die, dan stopt de pipeline en gaat er een melding uit.
- Genereren detecteert componenten en hun directe en transitieve afhankelijkheden, legt metadata vast zoals versies, licenties en PURL’s, bouwt de dependency graph, normaliseert pakketnamen en versieformaten, en schrijft SPDX of CycloneDX.
- Valideren controleert het schema, de metadata, de consistentie van identifiers en verwijzingen naar afhankelijkheden, optioneel een profiel zoals de verplichte velden van BSI, en of de SBOM overeenkomt met het artefact. ENISA noemt de identifiers van componenten expliciet als iets wat u moet valideren.
- Ondertekenen canonicaliseert de SBOM, berekent een SHA-256-digest, ondertekent die, koppelt de handtekening aan een identiteit via een X.509-certificaat of Sigstore, en voegt een tijdstempel toe.
- Opslaan zet de ondertekende SBOM in een onveranderlijke, geversioneerde repository met toegangscontrole, manipulatiebewijs, back-ups en een bewaarbeleid.
- Gebruiken voedt kwetsbaarheidsbeheer, licentienaleving, leveranciersrisicobeheer, open-sourcegovernance, naleving van regelgeving en software-assetmanagement.
- Onderhouden genereert de SBOM opnieuw bij elke wijziging: een nieuwe build of release, updates van afhankelijkheden, securitypatches, updates van OS-pakketten, toegevoegde of verwijderde bibliotheken, of een gewijzigde buildconfiguratie.
In het diagram van de levenscyclus staan markttoezichtautoriteiten tussen de afnemers, naast security-, ontwikkel- en complianceteams, leveranciers en klanten. Onder de CRA kan een autoriteit om uw SBOM vragen, en dan wilt u de SBOM overhandigen die hoort bij precies de productversie waar het om gaat.
Tools voor elke fase
Het advies koppelt opensourcetools aan de fasen van de levenscyclus. Een op de drie organisaties in de enquête vertrouwt op opensourcetools, en ENISA presenteert de lijst als indicatief, niet als uitputtend.
| Fase | CycloneDX | SPDX |
|---|---|---|
| Genereren | cyclonedx-maven-plugin, @cyclonedx/cyclonedx-npm, cyclonedx-gomod, CycloneDX .NET tool, cdxgen, Syft, SBOMit | spdx-gradle-plugin, spdx-maven-plugin, SPDX-tools voor Python, Java en Go, Yocto, Linux (make spdx), Zephyr (west spdx), kubernetes-sigs/bom, GitHub SBOM, Microsoft sbom-tool, Syft, Trivy, ORT, SBOMit |
| Schemavalidatie | CycloneDX CLI | SPDX online validator en NTIA checker |
| Kwaliteitsscore | sbomqs, sbom-scorecard | |
| Ondertekenen | GitHub CLI attestations, Cosign met keyless signing via Sigstore | |
| Opslaan | Workflow-artefacten van GitHub Actions (actions/upload-artifact) | |
| Gebruiken | Grype, Trivy, OWASP Dependency-Check, OWASP Dependency-Track, GitHub Dependency Review, OWASP dep-scan, OSV-Scanner, CVE Binary Tool | Fossology, sbomify, sbom-cve-check, SPDX 3 visualizer, GitHub Dependency Review |
Bij twee items hoort een kanttekening. OWASP Dependency-Check scant projectbestanden en afhankelijkheden rechtstreeks en is niet gemaakt om SBOM’s op te nemen. De OWASP-tool die SBOM’s leest en bewaakt is Dependency-Track, en onze gids voor het uitrollen van Dependency-Track laat zien hoe u die op uw eigen infrastructuur draait.
Workflow-artefacten verlopen bovendien na hun bewaartermijn, wat niet past bij het eigen advies over onveranderlijke opslag en bewaring. De CRA verwacht dat u de technische documentatie ten minste tien jaar bewaart nadat het product in de handel is gebracht, of gedurende de ondersteuningsperiode als die langer is. Bewaar SBOM’s in een artefactrepository die u zelf beheert.
Een threat model voor de SBOM-pipeline
Het advies bevat een threat model volgens STRIDE. Dat dekt het hele SBOM-ecosysteem, niet alleen het bestand: de generatoren, de diensten voor validatie en ondertekening, de repositories en de pipelines die SBOM’s gebruiken.
| STRIDE | Voorbeelden van dreigingen | Indicatieve maatregelen |
|---|---|---|
| Spoofing | Een nagebootste SBOM-auteur, een valse afnemer die een beperkte SBOM opvraagt, een vervalste CI/CD-pipeline of generatietool, gestolen ondertekeningscertificaten, een gecompromitteerde mirror van de repository | Digitale handtekeningen, verificatie van de identiteit van leverancier en afnemer, buildattestaties, geauthenticeerde pipelines, sleutelbeheer, intrekking van certificaten |
| Tampering | Componenten, versies of afhankelijkheden gewijzigd na het genereren; metadata gewijzigd vóór het genereren; aangepaste hashes, herkomst, PURL's of CPE's | Verificatie van integriteit en handtekeningen, ondertekende attestaties, verificatie van externe verwijzingen |
| Repudiation | Een producent ontkent een SBOM te hebben gegenereerd, gepubliceerd of verspreid | Handtekeningen, tijdstempels, audit- en repositorylogs, ondertekende releases |
| Information disclosure | De SBOM onthult de technologiestack, eigen componenten, leveranciersrelaties, de dependency graph, exacte versies, of interne certificaten en releaseprocessen | Gecontroleerd delen, toegangscontrole, auditlogging |
| Denial of service | Een onbereikbare repository, zeer grote of diep geneste SBOM's die parsers uitputten, een SBOM-volume dat opslag vult en pipelines laat vastlopen | Redundantie en DDoS-bescherming, groottelimieten, geharde parsers, een bewaarbeleid |
| Elevation of privilege | Escalatie van rechten in de buildpipeline, de SBOM-repository of de ondertekeningsinfrastructuur | Toegangscontrole, harding van pipelines, sleutelbeheer |
Twee rijen verdienen meer aandacht dan ze meestal krijgen. Information disclosure is de reden dat u onder de CRA de SBOM in uw technische documentatie mag houden in plaats van hem te publiceren: een lijst met exacte versies is een lijst met CVE’s om uit te proberen. Bepaal per klant wat u deelt en onder welke voorwaarden. En de denial of service op parsers telt zodra u SBOM’s van leveranciers accepteert. Behandel die als onbetrouwbare invoer.
Gebruik de tabel als startpunt, niet als uw threat model. Uw pipeline heeft eigen vertrouwensgrenzen, en de vragen die ze blootleggen zijn dezelfde als voor elk ander systeem. Het Secure by Design and Default Playbook biedt een lichte manier om dat te doen als uw team nog nooit een threat model van het buildsysteem heeft gemaakt.
Tien risico’s die SBOM’s minder bruikbaar maken
Naast de dreigingen noemt het advies algemene risico’s die de nauwkeurigheid, integriteit of bruikbaarheid van SBOM’s ondermijnen.
| Risico | Hoe het eruitziet | Indicatieve maatregel |
|---|---|---|
| Niet-standaard formaat | Een eigen of maatwerkformaat | Gebruik SPDX of CycloneDX |
| Niet machineleesbaar | Een pdf of spreadsheet voor mensen | Een machineleesbaar formaat dat geschikt is voor geautomatiseerde verwerking |
| Onvolledige SBOM | Componenten of afhankelijkheden ontbreken | Automatisch genereren bij de release, integratie in CI/CD, gedocumenteerde known unknowns en ontbrekende metadata |
| Verouderde SBOM | De SBOM klopt niet meer met de software | Opnieuw genereren bij de onderhoudstriggers |
| Slechte identificatie van componenten | Componenten zijn niet te matchen over ecosystemen heen | De URL van de upstream-repository, of een PURL met namespace, exacte versie en hashes, of een consequent toegepaste CPE met exacte versie en hashes |
| Onvoldoende nauwkeurigheid | Heuristieken voegen componenten toe die er niet zijn, missen componenten die er wel zijn, of melden verkeerde versies | Kies de generatietechniek per ecosysteem en type artefact, valideer SBOM's tegen artefacten, controleer volledigheid en identifiers |
| Zwakke koppeling tussen SBOM en artefact | Het is onduidelijk welke build, image of welk pakket de SBOM beschrijft | Koppel de SBOM aan het artefact met een hash of onveranderlijke digest en verifieer die koppeling |
| Beperkt operationeel gebruik | SBOM's worden gegenereerd maar nooit gebruikt | Gebruik ze voor asset-, kwetsbaarheids- en licentiebeheer |
| Onvoldoende bewaring | Oude SBOM's, handtekeningen en VEX-documenten zijn weg | Een bewaarbeleid, SBOM's per release, versiegeschiedenis, herleidbaarheid van SBOM naar artefact, vernietigingsprocedures |
| Geen prioritering van kwetsbaarheden | Elke bevinding wordt als even urgent behandeld | Combineer SBOM-data met VEX, de kritikaliteit van assets en blootstelling in een risicogebaseerd proces |
Slechte identificatie van componenten kom ik het vaakst tegen. Voor C en C++ is het de standaardsituatie: generatoren voegen hooguit een PURL toe, terwijl de NVD kwetsbaarheden in bibliotheken als OpenSSL en zlib onder CPE’s registreert. De maatregel van ENISA, een consequent toegepaste CPE met de exacte versie, is de aanpak uit ons artikel over CPE-verrijking voor C++-bibliotheken in Conan-builds.
Bewaring is het risico dat teams te laat ontdekken. Als er een CVE uitkomt voor een bibliotheek, is de vraag niet alleen of de build van vandaag geraakt is, maar welke geleverde versies. Die vraag kunt u alleen beantwoorden met de SBOM’s van die versies. Voor prioritering laat de mitigatiefase in ons artikel over package managers zien hoe EPSS, de KEV-catalogus, VEX en bereikbaarheid samenhangen.
Waar u begint: integratie tijdens de build
Het advies van ENISA voor een minimale werkende implementatie is om bij de build te beginnen en de CI-infrastructuur te gebruiken die u al hebt. Het verdeelt dat in zes stappen:
- Bepaal de integratiepunten in de huidige pipeline, zoals na het compileren, vóór het verpakken en bij de voorbereiding van de release.
- Configureer het genereren: formaat, detailniveau, scope van componenten, diepte van het doorlopen van afhankelijkheden, en omgevingsvariabelen voor consistente runs.
- Voeg een aparte pipelinestap toe die draait na de buildtaken waar hij van afhangt, met foutafhandeling die voorkomt dat een onvolledige SBOM-generatie kritieke paden blokkeert.
- Definieer triggers, bijvoorbeeld merges naar main, getagde releases en geplande baselineruns, en sla wijzigingen die alleen documentatie raken over.
- Bewaar SBOM’s dicht bij de buildartefacten, met versienummering die aansluit op uw softwareversies en een bewaartermijn die past bij de levenscyclus van het artefact.
- Valideer het formaat, controleer of verplichte velden zijn ingevuld, en verifieer handtekeningen waar u attestaties gebruikt.
Stap 3 staat wat ongemakkelijk naast de referentiearchitectuur, waarin elke gefaalde fase de pipeline stopt. Allebei zijn ze logisch, dus bepaal vooraf welke SBOM-fouten een release blokkeren en welke alleen een melding geven. Een ontbrekende SBOM voor een releasekandidaat moet blokkeren. Een wisselvallige kwaliteitsscore waarschijnlijk niet.
Het advies beschrijft twee integratiepatronen. Integratie tijdens de build genereert de SBOM direct na een geslaagde compilatie, terwijl de buildcontext nog beschikbaar is. Buildsystemen als Yocto, Kubernetes, Linux en Zephyr hebben SBOM-generatie al ingebouwd, dus u hoeft die alleen aan te zetten. Generatie op basis van events gebruikt webhooks van de repository bij commits, pull requests en releases, met een wachtrij voor gelijktijdige verzoeken en een generatiegeschiedenis voor audits.
Het algemene configuratieadvies is praktisch: een aparte map voor SBOM’s, bron-SBOM’s gescheiden van gegenereerde, naamgevingsconventies die elke SBOM aan zijn component koppelen, ignore-patronen zodat SBOM’s niet in builds belanden, herbruikbare pipelinetemplates, en validatiecontroles voordat er iets wordt gepubliceerd. Kwetsbaarheden die via de SBOM worden gevonden, moeten gekoppeld worden aan hersteltermijnen, ernstdrempels en escalatiepaden, met termijnen op basis van ernst, uitbuitbaarheid, blootstelling, kritikaliteit van het product, beschikbaarheid van patches en compenserende maatregelen.
Twee laatste aanbevelingen springen eruit. SBOM-processen moeten bewijs opleveren voor interne audits, conformiteitsbeoordelingen, incidentrespons en verzoeken van toezichthouders: generatielogs, validatieresultaten, handtekeningen, tijdstempels, koppelingen met releases en bewaarregistraties. En organisaties moeten de bekende hiaten, uitzonderingen en known unknowns in hun SBOM-dekking documenteren, vooral waar afhankelijkheden niet te identificeren zijn, leveranciersinformatie ontbreekt of componenten die alleen als binary bestaan niet volledig te analyseren zijn.
Beveiligingsmaatregelen voor de pipeline
Het advies sluit af met beveiligingsmaatregelen voor de hele SBOM-pipeline. Voor alle fasen noemt het rolgebaseerde toegangscontrole, MFA, least privilege, TLS 1.3 met certificaatvalidatie, auditlogging, meldingen bij mislukte validaties en handtekeningen, code review en branch protection voor pipelinedefinities, configuratie onder versiebeheer, en het verifiëren van de integriteit van generatoren en andere tools voordat ze draaien. Genereren voegt daar vertrouwde registers en verifieerbare buildherkomst aan toe. Ondertekenen en opslaan voegen geheimen in een vault toe, cryptografische koppeling tussen SBOM en artefact, manipulatiebestendige opslag, integriteitsmonitoring, versiegeschiedenis, en back-up en herstel voor repositories, ondertekeningsmateriaal en auditlogs.
Niets hiervan is specifiek voor SBOM’s. Het is de harding die uw buildsysteem hoe dan ook nodig heeft. Een SBOM is maar zo betrouwbaar als de pipeline die hem heeft gemaakt.
Wat het betekent voor de CRA
Bijlage I deel II van de Cyber Resilience Act verplicht fabrikanten om kwetsbaarheden en componenten in producten met digitale elementen te identificeren en te documenteren, onder meer met een softwarestuklijst in een algemeen gebruikt en machineleesbaar formaat die ten minste de afhankelijkheden op het hoogste niveau van de producten dekt. Artikel 13, lid 5, voegt zorgvuldigheid toe voor componenten van derden, open source inbegrepen. De SBOM maakt deel uit van de technische documentatie, die een markttoezichtautoriteit kan opvragen (bijlage VII, punt 8). Artikel 13, lid 24, staat de Commissie toe om het formaat en de elementen van de SBOM in een uitvoeringshandeling vast te leggen. De verplichting geldt vanaf 11 december 2027, samen met de rest van bijlage I.
Het advies interpreteert die verplichtingen niet, maar vult veel van het hoe in. Twee dingen zijn het meenemen waard. Het wettelijke minimum is de afhankelijkheden op het hoogste niveau, terwijl de enquête laat zien dat afnemers om diepte vragen, dus uw klanten leggen de lat hoger dan de verordening. En bijna elke aanbeveling levert bewijs op: logs, validatieresultaten, handtekeningen, bewaarregistraties. Dat is het materiaal waar een conformiteitsbeoordelingsinstantie of autoriteit om zal vragen.
Aan de kant van de normen dekt EN 40000-1-3 de eisen voor kwetsbaarheidsbeheer uit bijlage I deel II, waar de SBOM-verplichting staat. Ons overzicht van geharmoniseerde normen volgt de status ervan, en onze CRA-gids voor het mkb behandelt de andere verplichtingen.
Onze kijk
Dit is het praktischste SBOM-document dat een EU-instantie tot nu toe heeft gepubliceerd. De vergelijking van BSI en CISA bespaart iedereen die beide markten bedient een dag spreadsheetwerk, de referentiearchitectuur voor CI/CD geeft teams een beeld om naartoe te werken, en het STRIDE-model behandelt de SBOM-pipeline als aanvalsoppervlak, wat de meeste organisaties nog steeds niet doen.
Er zitten gaten in. Het is geschreven vanuit de producent: de kwaliteit controleren van SBOM’s die u van leveranciers ontvangt, en wat u doet als die tekortschieten, krijgt weinig aandacht, en daar gaan veel mkb-bedrijven hun tijd aan besteden zodra leveranciers CRA-SBOM’s gaan leveren. VEX komt voor in de risicotabel, maar niet in de levenscyclus of de pipeline. En de tooltabel verdient een kritische blik voordat u hem overneemt.
Begint u bij nul, volg dan de volgorde van het advies. Genereer tijdens de build in CI een SBOM in CycloneDX of SPDX, valideer het schema en de identifiers van componenten, onderteken hem, bewaar hem op een plek die u beheert, en bewaak hem continu met een tool als Dependency-Track. Krijg dat werkend voor één product voordat u aan runtime-SBOM’s denkt.
Bronnen: ENISA, Technical Advisory for Software Bill of Materials, oktober 2026; ENISA, SBOM Adoption State of Play 2026; BSI TR-03183-2, versie 2.1.0; CISA, 2026 Minimum Elements for a Software Bill of Materials; Verordening (EU) 2024/2847, de Cyber Resilience Act.