CISA herschreef de SBOM-regels: wat de 2026 Minimum Elements betekenen, en hoe monsys er al aan voldoet

Op 29 juli 2026 publiceerde CISA de 2026 Minimum Elements for a Software Bill of Materials. Die vervangt de basislijn uit 2021 van de National Telecommunications and Information Administration (NTIA), en is opgesteld door een opvallend brede coalitie: CISA, NSA en FBI samen met het Australische ACSC, het Canadese Cyber Centre, het Tsjechische NÚKIB, het Franse ANSSI, het Duitse BSI, het Nederlandse NCSC-NL en anderen.

Die coalitie is veelzeggend. Ze geeft aan dat "een SBOM" niet langer een Amerikaans aankoopvinkje is. Het wordt de gedeelde, machineleesbare taal die ook Europese toezichthouders verwachten, in lijn met de EU Cyber Resilience Act (CRA) en NIS2.

Genereer je vandaag SBOM's, dan is de lat net verhoogd. Dit is wat er echt veranderde, en wat er nodig is om eraan te voldoen.

Wat de standaard van 2026 vraagt

De basislijn van 2021 had zeven datavelden en een handvol praktijken. De herziening van 2026 behoudt die kernprincipes maar zet er flink meer tanden in. De minimum-elementen vallen nu in drie groepen.

SBOM-metadata (over het document zelf):

Component-data (over elk onderdeel in de software):

Praktijken en processen: Accommodation of Updates, Coverage (alle componenten inclusief transitieve, zonder minimumdiepte), Distribution and Delivery (een API of URL is nu expliciet een aanvaard leverkanaal), Explicitly Identifying Unknown Information, Frequency en Machine-Processable Data. Op dat laatste punt noemt de standaard exact twee aanvaarde formaten: SPDX en CycloneDX.

Waarom het veranderde

Drie krachten dreven de herschrijving.

De tooling liep in. In 2021 was het onrealistisch om te eisen dat elke SBOM ondertekend was of per-component-hashes droeg. In 2026 kan de tooling dat, dus mogen kopers meer eisen.

Integriteit werd het punt. De belangrijkste toevoeging is de SBOM Author Signature. Een niet-ondertekende SBOM is gewoon een tekstbestand dat iedereen kan bewerken. Een ondertekende laat de ontvanger bewijzen dat de inventaris niet onderweg is gemanipuleerd en dat ze komt van wie ze beweert. Dat is het verschil tussen "een lijst" en "bewijs".

Regelgeving convergeerde. De lijst met mede-auteurs leest niet toevallig als een wie-is-wie van Europese cyberagentschappen. De CRA gaat SBOM's vereisen voor producten met digitale elementen, en NIS2-auditors vragen om zicht op de toeleveringsketen. Eén aangescherpte, internationaal mede-ondertekende basislijn is precies wat één SBOM meerdere regimes tegelijk laat dekken.

De standaard voegt zelfs een sectie toe over het koppelen van SBOM's aan security-advisories, met VEX en CSAF expliciet bij naam. Met andere woorden: een inventaris alleen is niet het doel. Je hebt de inventaris plus een exploiteerbaarheidssignaal per kwetsbaarheid nodig. (We schreven over die combinatie toen we VEX uitbrachten; blijkt dat de standaard het nu met ons eens is.)

De onderdelen die echt lastig zijn

De meeste nieuwe velden zijn makkelijk als je generator de host al doorloopt. Drie zijn dat niet.

1. De handtekening. Je hebt een echte sleutel nodig, een canonieke serialisatie zodat de handtekening reproduceerbaar is, en een publiek verificatiepad. Onderteken de verkeerde bytes en elke downstream-verifier wijst ze af.
2. Component-hashes. De standaard wil een hash van elk component-artefact. Een tool die geïnstalleerde metadata inventariseert (pakketnaam en versie) heeft de originele artefact-bytes niet om te hashen. Een hash verzinnen is erger dan er geen opnemen.
3. Eerlijkheid over onbekenden. De standaard van 2026 is expliciet: geef aan wanneer een waarde echt onbekend is in plaats van ze leeg te laten of te gokken. Dat klinkt zacht, maar het is een echte ontwerpbeperking, want het verbiedt de gemakkelijke leugen.

Hoe monsys eraan voldoet

Elke SBOM die monsys genereert, in zowel SPDX 2.3 als CycloneDX 1.5, emitteert de volledige set al. Hier is de mapping, element per element.

De handtekening, zo dat iedereen ze kan controleren

Elke SBOM wordt ondertekend met de Ed25519-sleutel van de hub. CycloneDX gebruikt zijn eigen JSF signature-blok; SPDX draagt de handtekening in een annotatie op documentniveau. Cruciaal: de handtekening dekt de RFC 8785 (JSON Canonicalization Scheme)-vorm van het document zonder de handtekeninghouder. Zo kan een derde partij het bestand opnieuw canoniseren, onze publieke sleutel ophalen en het offline verifiëren, met eender welke standaardbibliotheek. Het is dezelfde sleutel die de maandelijkse Audit Pack ondertekent, dus één publieke sleutel dekt al ons bewijs.

Eerlijk over component-hashes

monsys doet metadata-only host-inventaris: het leest wat de pakketbeheerders rapporteren, het haalt niet elke binary op om die op te slaan. Het kan dus geen echte artefact-hash berekenen, en het zegt dat ook, door Component Hash als unknown te registreren in plaats van een waarde te verzinnen. Dat is precies het gedrag dat het element "Explicitly Identifying Unknown Information" van de standaard vraagt. Voegen we later een bron toe die wél hashes draagt, dan vult het veld zich vanzelf.

Wat je concreet krijgt

Open een host in het dashboard, ga naar het tabblad CVE's, en de Audit-export-balk geeft je vier downloads met één klik:

• SBOM in SPDX 2.3 of CycloneDX 1.5, drie lagen diep: applicatie-afhankelijkheden, OS-pakketten en de draaiende kernel.
• VEX in OpenVEX of CycloneDX-VEX, die per CVE aangeeft of de host echt getroffen is.

Of haal ze rechtstreeks uit de API, die de standaard nu erkent als leverkanaal:

GET /api/v1/agents/{id}/sbom?format=spdx-json
GET /api/v1/agents/{id}/sbom?format=cyclonedx-json
GET /api/v1/agents/{id}/vex?format=openvex

Elke download is ondertekend en offline verifieerbaar, en exact dezelfde data zit in de maandelijkse Audit Pack, zodat je ondertekende bewijs overeenkomt met wat je operators op aanvraag kunnen ophalen.

De kern

De 2026 Minimum Elements tillen de ondergrens van "een componentenlijst" naar "een ondertekende, gelicentieerde, machineverifieerbare inventaris gekoppeld aan een exploiteerbaarheidssignaal". Dat is meer werk voor wie jouw SBOM's genereert. Met monsys is het een download, gegenereerd binnen een in de EU gehost platform op basis van data die de agent al rapporteert, zonder dat er iets naar derden gaat.

Lees de volledige standaard: 2026 Minimum Elements for a Software Bill of Materials (CISA, TLP:CLEAR). SBOM en VEX zijn gedocumenteerd op docs.monsys.ai/nl/security/sbom-vex. Eerste vijf servers gratis: monsys.ai/nl/signup.