SBOM-strategie en attestatie voor OSS-projecten: een best practices-gids voor 2026
| Jason Smith — CEO, ShiftLeftCyber
Het open source-ecosysteem staat voor een ongekende verschuiving op regelgevend en operationeel vlak. Open source-beheerders zijn nu verantwoordelijk voor dezelfde eisen aan de toeleveringsketen als commerciële leveranciers. Tussen de handhaving van de EU Cyber Resilience Act (CRA), de premarketrichtlijnen van de Amerikaanse FDA en NIS2 geldt als uitgangspunt dat software niet kan worden uitgebracht zonder een onderhouden Software Bill of Materials (SBOM) en verifieerbaar bewijs van hoe ze is gebouwd.
Voor een OSS-project komt het halen van die lat neer op twee dingen: een duidelijke SBOM-strategie (wat u produceert, in welk formaat en hoe) en een veerkrachtig attestatiemodel (hoe afnemers kunnen vertrouwen op wat u hebt geproduceerd). Wanneer een downstreamfabrikant aan wereldwijde regelgeving moet voldoen, schuift hij die eisen door naar boven in de keten. Levert uw project een hoogwaardige SBOM, dan blijft u in hun materiaallijst. Zo niet, dan wordt u het beveiligingsgat waar ze omheen moeten werken.
Deze gids beschrijft het overkoepelende SBOM-raamwerk en de praktijken die in 2026 bestand zijn tegen compliancestandaarden op ondernemingsniveau.
✅ TL;DR: een checklist voor SBOM en attestatie bij OSS
Kies een SBOM-formaat (CycloneDX of SPDX)
Genereer SBOM's in CI-pipelines (bij elke build/release)
Bouw het trustmodel (provenance + handtekeningen)
Distribueer ze waar afnemers ze daadwerkelijk vinden
Verrijk met dynamische VEX-informatie
Plan voor de langetermijnlevenscyclus en -bewaring
📄 Stap 1: kies een SBOM-formaat en houd eraan vast
De formaatoorlog is het verkeerde om over te piekeren. Beide grote formaten (CycloneDX en SPDX) zijn wereldwijd erkende standaarden, breed geaccepteerd en worden snel gemoderniseerd. Kies er één als uw canonieke uitvoer en converteer op aanvraag als een afnemer het andere nodig heeft. Volledigheid en automatisering zijn veel belangrijker dan de keuze van het formaat.
Kenmerk | CycloneDX | SPDX |
|---|---|---|
Belangrijkste kracht | Application security, VEX, gedefinieerde handtekeningstandaard | Licentiecompliance, juridische beoordeling, standaardisatie op ISO-niveau |
Standaard | ||
Nieuwste versie | 1.7 | 3.0 |
Veelvoorkomend ecosysteem | AppSec en geautomatiseerde toeleveringsketentools | Juridische compliance in ondernemingen en gereguleerde sectoren |
Ondersteunde formaten | JSON / XML / Protobuf Let op: CycloneDX schakelt naar verwachting in versie 2.0 – die later in 2026 wordt verwacht – over op uitsluitend JSON. | JSON-LD, XML, RDF |
🛠️ Stap 2: genereer uw SBOM's automatisch in CI bij elke build
Een handgemaakte of handmatig opgestelde SBOM is verouderd zodra uw afhankelijkheidsboom verandert. De enige duurzame praktijk is om de SBOM te behandelen als een centraal build-artefact.
Automatiseer de pipeline: voer SBOM-generatie uit als een native CI-stap (GitHub Actions, GitLab CI enzovoort), gekoppeld aan uw release-tag of commit. Als de SBOM-generatie mislukt, mislukt de build.
Genereer vanuit het artefact, niet alleen vanuit het manifest: manifesten en lockbestanden missen vaak transitieve, tijdelijke of buildtimecomponenten. Dit geldt vooral voor complexe setups zoals C/C++, waarbij de SBOM moet worden afgeleid uit het werkelijke buildproces in plaats van uit een statische pakketbeheerder.
Strikte versie-afstemming: een release-SBOM moet expliciet worden voorzien van een versie, getagd en bijgehouden naast de exacte buildversie die ze vertegenwoordigt (bijv. v1.4.2-sbom.json die overeenkomt met v1.4.2.tar.gz).
🛡️ Stap 3: bouw het trustmodel
Een SBOM vertelt afnemers wat erin zit. Een attestatie vertelt hun dat ze het kunnen geloven. Dit is de cruciale stap die de meeste projecten overslaan, en het is precies wat toezichthouders steeds vaker vragen.
Een attestatiemodel voor een OSS-project bestaat uit drie lagen:
Provenance: een verklaring van hoe de artefacten en SBOM's zijn gebouwd. De in-toto-/SLSA-raamwerken definiëren dit. Veel CI-systemen kunnen SLSA-provenance native uitgeven.
Ondertekening: onderteken de SBOM en de provenance zodat manipulatie detecteerbaar is en de ondertekenaar verifieerbaar is.
Zelfattestatie: voor projecten die de Amerikaanse federale toeleveringsketens voeden, is het Secure Software Development Attestation Form de gestandaardiseerde manier om conformiteit met veilige ontwikkelpraktijken te verklaren.
Samen veranderen deze "hier is een JSON-bestand" in "hier is een ondertekend, verifieerbaar record van wat we hebben uitgebracht en hoe" – precies waar de raamwerken CRA, FDA en NIS2 naar op zoek zijn.
📦 Stap 4: distribueer ze waar afnemers ze daadwerkelijk vinden
De meest voorkomende fout is niet het genereren van een SBOM, maar het kwijtraken ervan. Een los JSON-bestand aan een GitHub-releasepagina hangen maakt het onzichtbaar voor geautomatiseerde scanners en beveiligingstools van ondernemingen. GitHub-releases zijn de plek waar SBOM's sterven.
Betere distributiepraktijken:
Hang de ondertekende SBOM rechtstreeks aan het artefactregister (bijv. als OCI-/registerattestatie of pakketmetadata) zodat ze met de software meereist.
Gebruik een stabiele, voorspelbare URL of API per release.
Houd historische SBOM's beschikbaar. Afnemers die een oude versie auditen, hebben de SBOM nodig die bij die build hoort.
✨ Stap 5: verrijk met dynamische VEX-informatie
Een SBOM is een statische inventaris. De ingrediënten van een specifieke release zullen nooit veranderen. Kwetsbaarheidsgegevens zijn echter zeer dynamisch. Een component die vandaag als volkomen veilig wordt beschouwd, kan morgen een kritieke zero-day blijken te hebben.
Het matchen van een ruwe SBOM tegen een kwetsbaarheidsdatabase kan een stortvloed aan valse positieven opleveren. Om dit op te lossen, vult u uw strategie aan met VEX (Vulnerability Exploitability eXchange). Met VEX kunt u per kwetsbaarheid aangeven of uw product daadwerkelijk getroffen is, waardoor de SBOM verandert van een ruisgenerator in een beslissingstool voor degenen die ze gebruiken.
Vestig een continu ritme: onderhoud een levend, dynamisch VEX-begeleidingsbestand of -endpoint. Voer geautomatiseerde dagelijkse of per-commit kwetsbaarheidsscans uit op actieve branches en werk uw VEX-gegevens bij, zodat afnemers een echte, bruikbare exploiteerbaarheidsstatus zien in plaats van ruwe CVE-ruis.
🔁 Stap 6: plan voor de langetermijnlevenscyclus en -bewaring
Het genereren van een SBOM is een momentopname, maar het beheren ervan is een verplichting van meerdere jaren. Onder wereldwijde raamwerken zoals de EU Cyber Resilience Act (CRA) hebben softwarefabrikanten te maken met een strikte bewaarplicht van tien jaar voor gegevens nadat de levenscyclus van een product is afgelopen. Uw artefacten moeten transformeren van tijdelijke pipeline-uitvoer naar een permanent compliance-archief.
Historische SBOM's moeten stabiel, voorspelbaar en adresseerbaar blijven. Als een afnemer over tien jaar een oude versie moet auditen, moet die specifieke bijbehorende SBOM op te halen zijn.
Hoe Interlynk helpt
Interlynk automatiseert deze hele levenscyclus voor OSS- en productteams: generatie over ecosystemen heen (inclusief lastige gevallen zoals C/C++), formaatconversie, ondertekening en attestatie, VEX en versiebeheer per release. Zo draait de bovenstaande strategie in CI in plaats van met de hand. Begin gratis of boek een demo.
Verder lezen
ShiftLeftCyber, een trotse partner van Interlynk, biedt met zijn SecureSBOM-oplossing digitale ondertekening en verificatie van SBOM's. U kunt meer inzichten van ShiftLeftCyber ontdekken op de ShiftLeftCyber-blog, of volg Jason op LinkedIn voor regelmatige updates over de beveiliging van de softwaretoeleveringsketen.