SOC 2-plattformen din viser at kontrollen kjører. CRACI registrerer hva bygget inneholdt.

Oppsettet denne siden handler om

Mange SaaS-team ender opp med samme ordning. En generator som Syft eller Trivy produserer en SBOM i CI, en sårbarhetsskanner følger med på repositoriene, og en plattform for compliance-automatisering kobler seg til GitHub og skykontoen for å samle inn dokumentasjon til SOC 2. Det fungerer. Revisorer godtar det, og ingen bruker uken før en revisjon på å ta skjermbilder.

Disse plattformene er gode på dette. Vanta sier at plattformen "connects read-only to your cloud, identity, code, and device tools" og "automatically pulls evidence, maps it to controls," med mer enn 1 200 automatiserte tester som kjører hver time. Drata kobler seg til "cloud infrastructure, identity providers, HR systems, code repositories, ticketing tools, and more" for å samle inn dokumentasjon og knytte den til SOC 2-kontroller. Hvis målet er en ren SOC 2-rapport, er det riktig verktøy for jobben.

Denne siden handler om et smalere spørsmål: hva den dokumentasjonen sier om selve SBOM-en.

Hva en SOC 2-sjekk faktisk spør om

SOC 2-revisjoner rapporterer mot AICPA Trust Services Criteria. Kriteriet nærmest SBOM-er er 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

Kriteriet beskriver et resultat. Metoden, og dybden i komponentinventaret bak den, overlater det til deg og revisoren din. En automatisert test spør derfor vanligvis om kontrollen er på plass og i drift: Er en skanner tilkoblet, kjørte den, ble funn håndtert innenfor policyen din? Det er et rimelig spørsmål, og det er avkrysningen.

Det sjekken ikke spør om, er om SBOM-en bak skanningen listet opp alt utgivelsen inneholdt. En sårbarhet i en komponent SBOM-en aldri listet opp, kan ikke matches mot noe, så skanningen kommer tilbake ren, og kontrollen står fortsatt som grønn.

Der en grønn sjekk og en fullstendig SBOM skiller lag

SBOM-generatorer jobber ut fra filene foran seg, og deres egen dokumentasjon viser hvor det gir hull:

• På expressjs/express 5.2.1, som ikke committer noen lockfile, har en generator som løser avhengigheter fra lockfiler, ingenting å løse. Den kan likevel returnere et dokument som lister opp det andre den kjenner igjen, for eksempel GitHub Actions og workflow-filer, og ingen av npm-avhengighetene deklarert i package.json.
• Ulike generatorer returnerer ulike lister fra samme checkout, fordi hver av dem selv avgjør hva som teller som en komponent. Eksporten av GitHubs avhengighetsgraf ligger enda lenger unna: Den er bygget fra det GitHub vet om repositoriet, og leser standardgrenen i stedet for den festede commiten.
• NTIA-feltet for leverandør er tomt i de fleste dokumenter, fordi de fleste generatorer ikke har noen kilde til det.

Ingen av disse verktøyene er ødelagt. Hvert av dem leste filene det ble pekt mot, og hvert av dem produserte et gyldig dokument i et standardformat, til rett tid. For en compliance-test var kontrollen i drift. SBOM-en beskrev likevel ikke programvaren.

Hva CRACI tilfører dokumentasjonen

CRACI erstatter GitHub Actions-runneren. Du endrer runs-on til craci, og kjøringer vises fortsatt i GitHub-grensesnittet. SBOM-en genereres inne i den runneren mens bygget kjører: En pakkebevisst proxy observerer trafikk til pakkekilder, så registreringen gjenspeiler hva jobben hentet, ikke hva en fil sier at den burde hente.

Fullstendighet angis, den antas ikke

Hver jobb og hver cache får én av fem fullstendighetsstatuser: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Dokumentasjonen av avhengigheter følger med cacher, så pakker gjenopprettet fra en varm cache blir ført videre i stedet for å forsvinne i det stille. Når en registrering er ufullstendig, sier den fra.

Det stemmer med retningen standardene går i. Minimumselementene for SBOM fra 2026 fra CISA og partnerne ber SBOM-forfattere om å "explicitly state whether the information is unknown to the SBOM author" i stedet for å la felter stå tomme i det stille.

Dokumentasjon i formater revisorer godtar

SBOM-er eksporteres som CycloneDX eller SPDX, inkludert sårbarhetene som er funnet i komponentene. Det offentlige REST API-et returnerer SBOM-en, jobbens nettverksspor og provenance-data, så de samme registreringene kan gå dit revisjonsdokumentasjonen din ligger.

En oversikt over hva som er rullet ut hvor

Inventarvisningen i CRACI viser nøyaktig hvilke programvareversjoner som er rullet ut til hvilke produkter, globalt. Når en ny sårbarhet dukker opp, kan du se hvilke produkter som kjører den berørte versjonen, i stedet for å pusle det sammen fra utgivelsesnotater og regneark.

Behold SOC 2-plattformen

CRACI er ikke en plattform for compliance-automatisering og erstatter ikke en. Det håndterer ikke policyer, tilgangsgjennomganger, enhetssjekker eller leverandørspørreskjemaer. De to svarer på ulike spørsmål. Compliance-plattformen din viser at en kontroll finnes og kjører. CRACI registrerer hva bygget hentet inn, og om den registreringen er fullstendig.

Forskjellen vokser når du selger programvare inn i EU. Cyber Resilience Act krever at produsenter identifiserer og dokumenterer komponenter ved å utarbeide en programvarestykkliste i et alminnelig brukt, maskinlesbart format som minst dekker avhengighetene på øverste nivå i produktene (vedlegg I del II). Vedlegg VII plasserer SBOM-en i den tekniske dokumentasjonen og lar en markedstilsynsmyndighet be om den. En SOC 2-rapport attesterer hvordan organisasjonen din driver kontrollene sine. En CRA-SBOM beskriver et bestemt produkt. Oversikten vår over CRA dekker tidslinjen, og siden om CRA-samsvar dekker hva CRACI automatiserer. CRACI automatiserer en betydelig del av innsynet i leverandørkjeden og dokumentasjonen som en bredere CRA-samsvarsprosess trenger; det gjør deg ikke samsvarende på egen hånd.

Slik prøver du det uten å røre revisjonen

1. Velg ett repositorium der SBOM-en allerede inngår i SOC 2-dokumentasjonen din.
2. Pek utgivelses-workflowen mot CRACI ved å endre runs-on til craci.
3. Sammenlign den registrerte SBOM-en med den du genererer i dag, komponent for komponent, og sjekk jobbens fullstendighetsstatus.
4. Avgjør om forskjellen hører hjemme i dokumentasjonen din.

Du kan lese mer om SBOM-generering under bygget og CRA-dokumentasjon, eller se hvordan vi dokumenterer våre egne kontroller på sikkerhetssiden.