Uw SOC 2-platform toont dat de control draait. CRACI legt vast wat er in de build zat.

De opzet waar deze pagina over gaat

Veel SaaS-teams komen uit op dezelfde opzet. Een generator zoals Syft of Trivy maakt een SBOM in CI, een kwetsbaarheidsscanner houdt de repositories in de gaten, en een platform voor compliance-automatisering koppelt met GitHub en het cloudaccount om bewijs voor SOC 2 te verzamelen. Het werkt. Auditors accepteren het, en niemand besteedt de week voor een audit aan screenshots maken.

Die platforms zijn hier goed in. Vanta zegt dat het "connects read-only to your cloud, identity, code, and device tools" en "automatically pulls evidence, maps it to controls," met meer dan 1.200 geautomatiseerde tests die elk uur draaien. Drata koppelt met "cloud infrastructure, identity providers, HR systems, code repositories, ticketing tools, and more" om bewijs te verzamelen en aan SOC 2-controls te koppelen. Is het doel een schoon SOC 2-rapport, dan is dat de juiste tool voor de taak.

Deze pagina gaat over een smallere vraag: wat dat bewijs zegt over de SBOM zelf.

Wat een SOC 2-controle echt vraagt

SOC 2-onderzoeken rapporteren aan de hand van de AICPA Trust Services Criteria. Het criterium dat het dichtst bij SBOM's ligt, is CC7.1:

"To meet its objectives, the entity 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."

AICPA, 2017 Trust Services Criteria, CC7.1

Het criterium beschrijft een uitkomst. De methode en de diepte van de componenteninventaris erachter laat het aan u en uw auditor over. Een geautomatiseerde test vraagt dus meestal of de control aanwezig is en werkt: is er een scanner gekoppeld, heeft die gedraaid, zijn bevindingen binnen uw beleid afgehandeld. Dat is een redelijke vraag, en het is het vinkje.

Wat de controle niet vraagt, is of de SBOM achter de scan alles vermeldde wat de release bevatte. Een kwetsbaarheid in een component dat nooit in de SBOM stond, kan aan niets worden gekoppeld, dus de scan komt schoon terug en de control blijft groen.

Waar een groen vinkje en een volledige SBOM uiteengaan

SBOM-generatoren werken vanuit de bestanden die ze voor zich hebben, en hun eigen documentatie laat zien waar dat gaten achterlaat:

• Op expressjs/express 5.2.1, dat geen lockfile commit, heeft een generator die afhankelijkheden uit lockfiles haalt niets om op te lossen. Hij kan nog steeds een document teruggeven met wat hij verder herkent, zoals GitHub Actions en workflowbestanden, en geen van de npm-afhankelijkheden die in package.json zijn gedeclareerd.
• Verschillende generatoren geven uit dezelfde checkout verschillende lijsten terug, omdat elk zelf bepaalt wat als component telt. De dependency graph-export van GitHub staat er nog verder vanaf: die is gebouwd uit wat GitHub over de repository weet en leest de standaardbranch in plaats van de vastgepinde commit.
• Het NTIA-veld voor de leverancier blijft in de meeste documenten leeg, omdat de meeste generatoren daar geen bron voor hebben.

Geen van die tools is kapot. Elk las de bestanden waarop hij was gericht, en elk maakte op schema een geldig document in een standaardformaat. Voor een compliancetest heeft de control gewerkt. De SBOM beschreef de software nog steeds niet.

Wat CRACI aan het bewijs toevoegt

CRACI vervangt de GitHub Actions-runner. U wijzigt runs-on in craci, en runs blijven in de GitHub-interface verschijnen. De SBOM wordt in die runner gegenereerd terwijl de build plaatsvindt: een proxy die pakketten herkent, observeert het verkeer naar pakketbronnen, dus de vastlegging weerspiegelt wat de job heeft binnengehaald en niet wat een bestand zegt dat hij zou moeten binnenhalen.

Volledigheid wordt vermeld, niet aangenomen

Elke job en elke cache krijgt een van vijf volledigheidsstatussen: Complete, Complete with connections, Incomplete, Unavailable of Not recorded. Het bewijs van afhankelijkheden reist mee met caches, dus pakketten die uit een warme cache worden teruggezet, worden meegenomen in plaats van stilletjes weg te vallen. Is een vastlegging onvolledig, dan staat dat erbij.

Dat past bij de richting van de standaarden. De SBOM minimum elements van 2026 van CISA en zijn partners vragen SBOM-auteurs om "explicitly state whether the information is unknown to the SBOM author" in plaats van velden stilzwijgend leeg te laten.

Bewijs in formaten die auditors accepteren

SBOM's worden geëxporteerd als CycloneDX of SPDX, inclusief de kwetsbaarheden die in hun componenten zijn gevonden. De openbare REST API levert de SBOM, de netwerktrace van de job en herkomstgegevens, zodat dezelfde gegevens terecht kunnen waar uw auditbewijs staat.

Een inventaris van wat waar is uitgerold

De inventarisweergave van CRACI toont precies welke softwareversies in welke producten zijn uitgerold, wereldwijd. Wordt er een nieuwe kwetsbaarheid bekend, dan ziet u welke producten de getroffen versie draaien, in plaats van het bij elkaar te zoeken uit release notes en spreadsheets.

Houd het SOC 2-platform

CRACI is geen platform voor compliance-automatisering en vervangt er geen. Het beheert geen beleid, toegangsreviews, apparaatcontroles of leveranciersvragenlijsten. De twee beantwoorden verschillende vragen. Uw complianceplatform toont dat een control bestaat en draait. CRACI legt vast wat de build binnenhaalde en of die vastlegging volledig is.

Het verschil wordt groter zodra u software in de EU verkoopt. De Cyber Resilience Act verplicht fabrikanten componenten te identificeren en te documenteren door een software bill of materials op te stellen in een algemeen gebruikt, machineleesbaar formaat die ten minste de afhankelijkheden op het hoogste niveau van de producten dekt (bijlage I, deel II). Bijlage VII plaatst de SBOM in de technische documentatie en laat een markttoezichtautoriteit erom vragen. Een SOC 2-rapport verklaart hoe uw organisatie haar controls uitvoert. Een CRA-SBOM beschrijft een specifiek product. Ons overzicht van de CRA behandelt de tijdlijn, en de pagina over CRA-naleving behandelt wat CRACI automatiseert. CRACI automatiseert een aanzienlijk deel van het inzicht in de keten en het bewijs dat een breder CRA-nalevingsproces nodig heeft; het maakt u niet op zichzelf compliant.

Zo probeert u het zonder uw audit aan te raken

1. Kies één repository waarvan de SBOM al uw SOC 2-bewijs voedt.
2. Richt de releaseworkflow op CRACI door runs-on te wijzigen in craci.
3. Vergelijk de vastgelegde SBOM per component met de SBOM die u vandaag genereert, en controleer de volledigheidsstatus van de job.
4. Bepaal of het verschil in uw bewijs thuishoort.

U kunt meer lezen over SBOM-generatie tijdens de build en CRA-bewijs, of op onze beveiligingspagina zien hoe we onze eigen controls documenteren.