SBOM's als nalevingsbewijs: ISO 27001, SOC 2 en NIS2

Bewijs is geen naleving

Aan een control wordt voldaan door een proces dat werkt. Bewijs laat zien dat het werkt. Een SBOM laat één specifiek ding zien: wat een bepaalde release bevatte. Over toegangsbeheer, incidentrespons of de vraag of iemand iets met een bevinding heeft gedaan, zegt hij niets.

Hij kan ook fout zijn op een manier die niemand opmerkt. Een generator die de verkeerde bestanden heeft gelezen, maakt een geldige SBOM die het halve product mist. De kwetsbaarheidsscan van die SBOM is schoon, het nalevingsplatform ziet dat er een scan is gedraaid, en elke check staat op groen. Wat een groene SOC 2-SBOM-check verifieert loopt die fout in detail door.

Bewijs uit een SBOM telt als hij:

1. Aan een release is gekoppeld. Eén SBOM per versie die u hebt uitgebracht, niet één voor de repository.
2. Volledig is, of zegt wat hij heeft gemist. Een SBOM die zijn gaten benoemt, is betrouwbaar voor wat hij wel vermeldt.
3. Bewaard wordt voor de periode die de audit beslaat. Een auditor die een steekproef uit maart vorig jaar neemt, heeft de SBOM van maart vorig jaar nodig.
4. Opnieuw wordt gecontroleerd als er nieuwe kwetsbaarheden verschijnen. Een lijst die niemand met nieuwe advisories vergelijkt, bewijst weinig over kwetsbaarheidsbeheer.

Wat een SBOM bevat, leest u in wat is een SBOM. Voor de frameworks voor veilige ontwikkeling van industriële producten en Amerikaanse overheidssoftware, zie IEC 62443-4-1 en NIST SSDF.

ISO/IEC 27001:2022

ISO/IEC 27001 is de norm waartegen een managementsysteem voor informatiebeveiliging wordt gecertificeerd (woordenlijst). Annex A noemt 93 controls; een organisatie kiest de controls die haar risicobeoordeling vraagt en legt ze vast in haar Statement of Applicability. ISO/IEC 27002:2022 geeft de implementatierichtlijnen. Geen van beide noemt een SBOM. De tabel citeert alleen de (Engelse) titels van de controls en zegt kort waar elke control over gaat.

Control	Waar het over gaat	Hoe een SBOM of buildrecord als bewijs dient	Wat het niet dekt
5.9 "Inventory of information and other associated assets"	Weten welke bedrijfsmiddelen u hebt en wie de eigenaar is	De software die u levert en draait, is een bedrijfsmiddel. Een componentenlijst per release is de inventaris van wat erin zit.	Hardware, data, mensen en diensten
5.19 "Information security in supplier relationships", 5.20 "Addressing information security within supplier agreements", 5.21 "Managing information security in the ICT supply chain", 5.22 "Monitoring, review and change management of supplier services"	Het risico beheersen dat leveranciers en de ICT-toeleveringsketen meebrengen	Twee richtingen. Als afnemer kunt u SBOM's van leveranciers eisen en die monitoren. Als leverancier is uw SBOM precies waar het ketenproces van uw gecertificeerde klant om vraagt. Open-sourcecomponenten horen bij de ICT-toeleveringsketen, maar komen zonder leveranciersovereenkomst, en juist daarom doet een inventaris ervan ertoe.	Contracten, leveranciersbeoordelingen en reviews
8.8 "Management of technical vulnerabilities"	Informatie over kwetsbaarheden verkrijgen, uw blootstelling beoordelen en ernaar handelen	Een actuele componentenlijst die tegen advisories wordt gematcht en opnieuw wordt beoordeeld als er nieuwe verschijnen, plus een record van welke releases een kwetsbare versie bevatten en sinds wanneer	Het patchen van uw infrastructuur, het scannen van hosts, en de beslissingen zelf
8.25 "Secure development life cycle"	Regels voor het veilig ontwikkelen van software en systemen	Een vastgelegd, herhaalbaar releaseproces: elke release gebouwd in dezelfde pipeline, met zijn SBOM	Het grootste deel van de control: training, omgevingen, ontwerp en review
8.26 "Application security requirements", 8.27 "Secure system architecture and engineering principles", 8.28 "Secure coding"	Eisen, ontwerp en code	Niet direct. Deze gaan over wat u schrijft, niet over wat u binnenhaalt.	Alles: code review, SAST en ontwerpdocumentatie zijn hier het bewijs
8.29 "Security testing in development and acceptance"	Beveiliging testen vóór de release	Een policy gate die een build op een kwetsbaarheidsbevinding blokkeert, is een vastgelegde test met een uitkomst	Functionele beveiligingstests, penetratietests
8.30 "Outsourced development"	Uitbestede ontwikkeling aansturen en monitoren	Uitbestede code die in uw pipeline wordt gebouwd, krijgt dezelfde SBOM en checks als uw eigen code	Het contract, de eigen werkwijze van de leverancier

Wees eerlijk over 8.25 tot en met 8.30: het meeste waar die controls om vragen, valt buiten een SBOM. Meer claimen is de snelste manier om het vertrouwen van een auditor in de rest te verliezen.

Uitgewerkt voorbeeld: een auditor vraagt naar 8.8

"Hoe weet u wanneer een nieuwe kwetsbaarheid een product raakt dat u al hebt geleverd?" Dit is de bewijsketen voor één advisory, en wie elke schakel levert.

Stap	Bewijs	Komt van
1. De inhoud van de release	De SBOM van versie 4.2, vastgelegd door de build die hem heeft opgeleverd	Uw buildtooling
2. De match met de advisory	Een nieuwe CVE, gepubliceerd voor een library in die SBOM, gematcht op zijn package URL	Uw kwetsbaarheidsmonitoring
3. De blootstellingsperiode	Elke build die de kwetsbare versie bevatte, en de datum van de eerste	Uw buildgeschiedenis
4. De beslissing	Wie het heeft beoordeeld, wanneer, en de uitkomst: oplossen, mitigeren of niet getroffen, met de reden	Uw proces en de bijbehorende records
5. De fix	Versie 4.2.1, waarvan de SBOM de kwetsbare versie niet meer bevat	Uw buildtooling

Tools kunnen stap 1, 2, 3 en 5 leveren. Stap 4 is uw proces, en dat is de stap die auditors het nauwkeurigst lezen.

SOC 2

Een SOC 2-rapport stelt vast of controls voldoen aan de Trust Services Criteria van het AICPA (2017, met in 2022 herziene points of focus). De criteria zijn uitkomstformuleringen. Ze noemen geen SBOM's, en bij twee ervan helpen SBOM's.

• CC7.1 vraagt dat de entiteit "uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities". Bewijs: een SBOM per release, opnieuw beoordeeld tegen nieuwe advisories, en een record van hoe elke bevinding is afgehandeld.
• CC8.1 gaat over change management: hoe wijzigingen in infrastructuur, data, software en procedures worden geautoriseerd, ontwikkeld of verworven, getest, goedgekeurd en geïmplementeerd. Bewijs: elke release gebouwd in een vastgelegde pipeline, de verandering in de afhankelijkheden zichtbaar van de ene build naar de volgende, en policy gates als control op wat mag worden uitgebracht.

De criteria worden herzien. In oktober 2026 publiceerde het AICPA een exposure draft van de Trust Services Criteria 2027, met een gerichte herstructurering van de criteria, een reactietermijn tot 15 januari 2027 en een voorgestelde ingangsdatum voor opdrachten die op of na 31 december 2027 beginnen. Het is een concept, en de nummers van criteria kunnen veranderen: controleer de definitieve tekst voordat u bewijs aan de nieuwe nummers koppelt.

Gebruikt u al een SOC 2-platform, houd het dan. De vraag is wat de SBOM achter de checks laat zien: SOC 2-SBOM-checks vergeleken.

NIS2

De NIS 2-richtlijn (EU) 2022/2555 geldt voor essentiële en belangrijke entiteiten in de sectoren die ze noemt. Leest u dit als leverancier van software of apparaten, dan valt u er meestal zelf niet onder. Uw klant wel, en diens verplichtingen bereiken u als vragen. Artikel 21 legt de maatregelen voor het beheer van cyberbeveiligingsrisico's vast, en drie passages leveren de meeste van die vragen op:

• Artikel 21, lid 2, punt d): de beveiliging van de toeleveringsketen, inclusief de beveiligingsaspecten van de relaties tussen elke entiteit en haar rechtstreekse leveranciers of dienstverleners.
• Artikel 21, lid 2, punt e): beveiliging bij het verwerven, ontwikkelen en onderhouden van netwerk- en informatiesystemen, inclusief de behandeling en bekendmaking van kwetsbaarheden.
• Artikel 21, lid 3: entiteiten moeten rekening houden met de kwetsbaarheden die specifiek zijn voor elke rechtstreekse leverancier en dienstverlener, en met de algemene kwaliteit van de producten en cyberbeveiligingspraktijken van hun leveranciers en dienstverleners, inclusief hun procedures voor veilige ontwikkeling. Dit is de zin die als vragenlijst op uw bureau belandt.

Uitvoeringsverordening (EU) 2024/2690

Uitvoeringsverordening (EU) 2024/2690 van de Commissie van 17 oktober 2024 legt de technische en methodologische eisen vast van de maatregelen uit artikel 21, lid 2, voor DNS-dienstverleners, registers voor topleveldomeinnamen, aanbieders van cloudcomputingdiensten, aanbieders van datacentrumdiensten, aanbieders van netwerken voor contentlevering, aanbieders van beheerde diensten, aanbieders van beheerde beveiligingsdiensten, onlinemarktplaatsen, onlinezoekmachines, platforms voor sociale netwerkdiensten en verleners van vertrouwensdiensten. Ze bindt de andere NIS2-sectoren niet, maar is de meest gedetailleerde openbare beschrijving van wat ketenbeveiliging betekent, en andere afnemers lenen eruit. De punten die leveranciers bereiken:

Punt in de bijlage	Wat het zegt	Wat een leverancier wordt gevraagd
5.1.2(a)	Bij de selectie van leveranciers wordt rekening gehouden met de cyberbeveiligingspraktijken van de leveranciers en dienstverleners, inclusief hun procedures voor veilige ontwikkeling	Hoe ontwikkelt u veilig, en hoe weet u wat er in uw product gaat?
5.1.4(e) en (f)	Contracten leggen waar passend het recht vast om te auditen of auditrapporten te ontvangen, en een verplichting voor leveranciers en dienstverleners om kwetsbaarheden te behandelen die een risico voor de entiteit vormen	Behandelt u kwetsbaarheden in wat u levert, en mogen we het bewijs zien?
5.2	Een register van rechtstreekse leveranciers, met een lijst van de ICT-producten, ICT-diensten en ICT-processen die elk van hen levert	Welke producten en versies levert u aan ons?
6.1.2(c)	Voor de verwerving van ICT-diensten of ICT-producten: informatie over de hardware- en softwarecomponenten die in de ICT-diensten of ICT-producten worden gebruikt	Welke hardware- en softwarecomponenten bevat uw product? Dichter bij een SBOM komt geen enkele tekst op deze pagina, en ook deze noemt er geen.
6.10	Behandeling van kwetsbaarheden: informatie over kwetsbaarheden monitoren via kanalen zoals aankondigingen van CSIRT's of informatie van leveranciers of dienstverleners (6.10.2(a)), en waar een kwetsbaarheid geen herstel nodig heeft, de reden documenteren en onderbouwen (6.10.3)	Hoe informeert u ons over kwetsbaarheden, en waarom is deze geen probleem?

Het laatste punt beschrijft een verklaring dat een product niet getroffen is, met de reden. Dat is wat een VEX-document bevat, al noemt de verordening geen formaat.

Uitgewerkt voorbeeld: een vragenlijst van een NIS2-klant

Vijf vragen van het soort dat een klant uit die punten afleidt, met het bewijs dat een leverancier kan bijvoegen. Sommige antwoorden komen uit records die uw tooling bijhoudt; andere zijn beleid dat u zelf schrijft.

Vraag	Bij te voegen bewijs	Record of beleid
"Noem de softwarecomponenten in de productversie die u aan ons levert." (6.1.2(c))	De SBOM van die versie, in CycloneDX of SPDX, met de volledigheid vermeld	Record
"Beschrijf uw behandeling van kwetsbaarheden en de termijnen." (5.1.4(f))	Uw procedure voor de behandeling van kwetsbaarheden, met ernstniveaus en streeftijden	Beleid
"Welke van de versies die wij draaien bevatten de kwetsbare library, en sinds wanneer?" (6.10)	Buildgeschiedenis die elke build toont die het component bevatte, met datums	Record
"Waarom raakt deze CVE ons niet?" (6.10)	Een verklaring van niet-getroffen zijn met de onderbouwing, zoals "de kwetsbare code is niet aanwezig"	Record, op basis van uw beoordeling
"Hoe kunnen onderzoekers kwetsbaarheden in uw producten melden?" (5.1.2(a))	Uw beleid voor coordinated vulnerability disclosure	Beleid

Eén onderscheid om vast te houden: voor producten met digitale elementen die in de EU worden verkocht, vereist de Cyber Resilience Act wel een SBOM. NIS2 niet.

DORA, als u aan financiële entiteiten verkoopt

De Digital Operational Resilience Act, Verordening (EU) 2022/2554, geldt voor financiële entiteiten, niet rechtstreeks voor hun leveranciers. Financiële entiteiten moeten hun ICT-activa en de onderlinge afhankelijkheden identificeren en documenteren en er inventarissen van bijhouden (artikel 8, leden 1, 4 en 6), het ICT-risico van derden beheren als onderdeel van hun ICT-risico (artikel 28, lid 1), een register bijhouden met informatie over al hun contracten voor ICT-diensten (artikel 28, lid 3), en minimale bepalingen in die contracten opnemen (artikel 30). DORA noemt geen SBOM's. Voor een leverancier van software aan een bank helpt een componentenlijst per release de klant om aan artikel 8 te voldoen.

Eén bewijskaart voor alle frameworks

Rijen zijn stukken bewijs; elke cel geeft de control, het criterium of het punt dat ze ondersteunen, of "niet direct".

Bewijs	ISO/IEC 27001:2022	SOC 2	NIS2 en 2024/2690	DORA
1. Een SBOM per release, met de volledigheid vermeld	5.9, 5.21, 8.8	CC7.1	Art. 21(2)(d); 6.1.2(c)	Art. 8 (de inventaris van de klant)
2. Doorlopende herbeoordeling tegen nieuwe advisories	8.8	CC7.1	Art. 21(2)(e); 6.10	Niet direct
3. Buildgeschiedenis: welke releases een component bevatten, en sinds wanneer	8.8	CC7.1, CC8.1	6.10	Niet direct
4. Records van triage en toewijzing	8.8	CC7.1	Art. 21(2)(e); 6.10	Niet direct
5. Verklaringen van niet-getroffen zijn, met redenen	8.8	CC7.1	6.10	Niet direct
6. Policy gates die een build blokkeren	8.25, 8.29	CC8.1	Art. 21(2)(e)	Niet direct
7. SBOM's van leveranciers, gemonitord samen met uw eigen	5.19, 5.21, 5.22	CC7.1	Art. 21(2)(d), 21(3); 5.2, 6.10	Art. 28(1)
8. Egressbeleid en netwerkrecords voor de build	8.25	CC8.1	Art. 21(2)(d)	Niet direct

Wat een SBOM niet bewijst

• Uw toegangsbeheer, incidentrespons, bedrijfscontinuïteit, personeelsbeveiliging, cryptografie of fysieke beveiliging.
• Dat iemand iets heeft opgelost. Dat is uw proces, met de bijbehorende records.
• Dat uw eigen code vrij is van fouten. Code review, SAST en tests zijn daarvoor het bewijs.
• Wat er in binaries zit die u zonder SBOM hebt ontvangen.
• Dat u gecertificeerd bent. Een SBOM is geen certificaat, en een certificaat van uw toolleverancier certificeert het eigen managementsysteem van die leverancier, niet u.

Waar CRACI past

CRACI vervangt uw door GitHub gehoste runners en legt vast wat elke build heeft binnengehaald, zodat de SBOM uit de releasebuild zelf komt, met een volledigheidsstatus voor elke job.

• Gemonitorde SBOM's worden doorlopend opnieuw beoordeeld zodra nieuwe kwetsbaarheden worden gepubliceerd (kwetsbaarheden volgen).
• Buildgeschiedenis toont binnen uw bewaartermijn welke builds een kwetsbare afhankelijkheid bevatten, en dus de periode waarin u blootgesteld was. Beslaat uw audit een langere periode, exporteer dan de SBOM van elke release en bewaar hem bij de release.
• Securityteams beoordelen de gevonden kwetsbaarheden (triage) en sturen ze naar de teams die de fix bezitten, en CRACI ondersteunt VEX om vast te leggen welke producten een kwetsbaarheid niet raakt.
• Policy gates kunnen een build op bevindingen blokkeren, ook een build die een specifieke CVE bevat.
• SBOM's van derden kunnen worden toegevoegd, zodat ingekochte componenten samen met uw eigen builds worden gemonitord.
• SBOM's worden geëxporteerd als CycloneDX of SPDX, en de API levert SBOM's, netwerktraces en herkomstgegevens. Het egressbeleid legt vast en beperkt waarmee elke build verbinding mag maken.

CRACI levert bewijs voor deze controls. Het maakt u niet compliant met ISO 27001 of SOC 2 of klaar voor NIS2, en het is geen platform voor nalevingsautomatisering. Het eigen certificaat van CRACI is een apart feit: het managementsysteem voor informatiebeveiliging van CRACI Corporation Oy voor de ontwikkeling en exploitatie van het CRACI-platform is gecertificeerd volgens ISO/IEC 27001, uitgegeven door Into Certification. Het dekt hoe CRACI zijn dienst runt, niet uw organisatie of uw producten. Zie beveiliging bij CRACI, en hoe CRACI werkt voor het hele platform.

Wanneer CRACI niet het antwoord is

• Uw builds draaien niet op GitHub Actions. Dat is vandaag de enige CI die CRACI ondersteunt; andere CI-systemen staan op de roadmap.
• U hebt een platform voor nalevingsautomatisering nodig voor beleid, toegangsreviews en de workflow met de auditor. Houd er een of koop er een; zie SOC 2-SBOM-checks vergeleken.
• Uw tekort aan bewijs is vooral organisatorisch: beleid, training, incidentrespons.
• Uw grootste leveranciersrisico zijn binaries die u zonder SBOM ontvangt. Binaire analyse geeft daar het antwoord.

Beantwoordt u het verzoek van één klant? Zie hoe u een SBOM-verzoek van een klant beantwoordt, de gids voor leveranciers van componenten en de checklist die uw klant zal toepassen.

SBOM's als nalevingsbewijs: veelgestelde vragen

Vereist ISO 27001 een SBOM?

Nee. ISO/IEC 27001:2022 noemt geen SBOM's. De Annex A-controls 5.9 (inventaris), 5.21 (ICT-toeleveringsketen) en 8.8 (technische kwetsbaarheden) vragen om uitkomsten die een SBOM ondersteunt, en de organisatie en haar auditor bepalen welk bewijs volstaat.

Vereist SOC 2 een SBOM?

Nee. De Trust Services Criteria zijn uitkomstformuleringen en noemen geen SBOM's. Een SBOM per release, opnieuw beoordeeld tegen nieuwe advisories, is bewijs voor CC7.1, en een vastgelegde buildpipeline ondersteunt CC8.1 over change management.

Vereist NIS2 een SBOM?

Nee. Artikel 21, lid 2, punt d) vraagt om beveiliging van de toeleveringsketen en punt e) om behandeling van kwetsbaarheden, zonder SBOM's te noemen. Uitvoeringsverordening (EU) 2024/2690, die bepaalde digitale dienstverleners dekt, vraagt in punt 6.1.2(c) om informatie over de hardware- en softwarecomponenten van ICT-producten, nog steeds zonder het woord SBOM.

Welke Annex A-controls van ISO 27001 ondersteunt een SBOM?

Vooral 5.9 (inventaris van informatie en andere bijbehorende bedrijfsmiddelen), 5.19 tot en met 5.22 (leveranciers en de ICT-toeleveringsketen) en 8.8 (beheer van technische kwetsbaarheden). Een buildrecord raakt deels aan 8.25, 8.29 en 8.30. 8.26 tot en met 8.28 gaan over eisen, ontwerp en code, buiten een SBOM.

Wat vragen NIS2-klanten aan hun softwareleveranciers?

Meestal een beschrijving van veilige ontwikkeling, de componenten in de geleverde versie, een toezegging om kwetsbaarheden te behandelen, een manier om informatie over kwetsbaarheden te ontvangen, en redenen als een kwetsbaarheid niet van toepassing is. Die vragen komen uit artikel 21, lid 3, en voor sommige sectoren uit de leverancierspunten van Uitvoeringsverordening 2024/2690.

Is een SBOM genoeg bewijs voor control 8.8 van ISO 27001?

Nee. Hij laat zien wat elke release bevat. Control 8.8 vraagt ook om bewijs dat u informatie over kwetsbaarheden verkrijgt, uw blootstelling beoordeelt en ernaar handelt. Combineer de SBOM met doorlopende herbeoordeling, een record van getroffen releases en de beslissingen die u hebt genomen.

Wat is het verschil tussen compliant zijn en bewijs hebben?

Compliant zijn betekent dat uw processen aan de eisen van het framework voldoen, zoals beoordeeld door een auditor of een klant. Bewijs is wat laat zien dat die processen werken. Een SBOM is bewijs voor een paar controls. Hij maakt u met geen enkel framework compliant.