Din SOC 2-platform viser, at kontrollen kører. CRACI registrerer, hvad buildet indeholdt.

Den opsætning, denne side handler om

Mange SaaS-teams ender med samme arrangement. En generator som Syft eller Trivy producerer en SBOM i CI, en sårbarhedsscanner holder øje med repositories, og en platform til compliance-automatisering forbinder sig til GitHub og cloud-kontoen for at samle dokumentation til SOC 2. Det virker. Auditorer accepterer det, og ingen bruger ugen før en audit på at tage skærmbilleder.

De platforme er gode til det her. Vanta siger, at det "connects read-only to your cloud, identity, code, and device tools" og "automatically pulls evidence, maps it to controls," med mere end 1.200 automatiserede tests, der kører hver time. Drata forbinder sig til "cloud infrastructure, identity providers, HR systems, code repositories, ticketing tools, and more" for at samle dokumentation og knytte den til SOC 2-kontroller. Er målet en ren SOC 2-rapport, er det det rigtige værktøj til opgaven.

Denne side handler om et snævrere spørgsmål: hvad den dokumentation siger om selve SBOM'en.

Hvad et SOC 2-tjek faktisk spørger om

SOC 2-undersøgelser rapporterer i forhold til AICPA Trust Services Criteria. Det kriterium, der ligger tættest på 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 af den komponentoversigt, der ligger bag, overlader det til dig og din auditor. Derfor spørger en automatiseret test som regel, om kontrollen er på plads og kører: Er en scanner forbundet, kørte den, blev fund håndteret inden for din politik? Det er et rimeligt spørgsmål, og det er afkrydsningsfeltet.

Det, tjekket ikke spørger om, er, om SBOM'en bag scanningen angav alt, hvad releasen indeholdt. En sårbarhed i en komponent, som SBOM'en aldrig angav, kan ikke matches med noget, så scanningen kommer tilbage ren, og kontrollen står stadig som grøn.

Hvor et grønt tjek og en komplet SBOM skilles

SBOM-generatorer arbejder ud fra de filer, de har foran sig, og deres egen dokumentation viser, hvor det efterlader huller:

• På expressjs/express 5.2.1, som ikke committer nogen lockfile, har en generator, der resolver afhængigheder fra lockfiles, intet at resolve. Den kan stadig returnere et dokument, der angiver, hvad den ellers genkender, såsom GitHub Actions og workflow-filer, og ingen af de npm-afhængigheder, der er deklareret i package.json.
• Forskellige generatorer returnerer forskellige lister fra det samme checkout, fordi hver af dem selv afgør, hvad der tæller som en komponent. GitHubs eksport af afhængighedsgrafen afviger endnu mere: Den er bygget ud fra det, GitHub ved om repositoriet, og læser default-branchen i stedet for det fastlåste commit.
• NTIA-feltet for leverandør er tomt i de fleste dokumenter, fordi de fleste generatorer ikke har nogen kilde til det.

Ingen af de værktøjer er i stykker. Hvert af dem læste de filer, det blev sat til at læse, og hvert af dem producerede et gyldigt dokument i et standardformat, til tiden. For en compliance-test har kontrollen kørt. SBOM'en beskrev stadig ikke softwaren.

Hvad CRACI tilføjer til dokumentationen

CRACI erstatter GitHub Actions-runneren. Du ændrer runs-on til craci, og kørsler vises stadig i GitHubs brugerflade. SBOM'en genereres inde i den runner, mens buildet kører: En pakkebevidst proxy observerer trafik til pakkekilder, så registreringen afspejler, hvad jobbet hentede, og ikke hvad en fil siger, det burde hente.

Fuldstændighed angives, den antages ikke

Hvert job og hver cache får én af fem fuldstændighedsstatusser: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Dokumentationen for afhængighederne følger med caches, så pakker gendannet fra en varm cache føres videre i stedet for ubemærket at falde ud. Er en registrering ufuldstændig, siger den det.

Det stemmer med den retning, standarderne går i. 2026-udgaven af SBOM minimum elements fra CISA og dets partnere beder SBOM-forfattere om at "explicitly state whether the information is unknown to the SBOM author" i stedet for uden videre at lade felter stå tomme.

Dokumentation i formater, auditorer tager imod

SBOM'er eksporteres som CycloneDX eller SPDX, inklusive de sårbarheder, der er fundet i deres komponenter. Det offentlige REST API returnerer SBOM'en, jobbets netværkstrace og provenance-data, så de samme registreringer kan gå derhen, hvor din audit-dokumentation ligger.

Et overblik over, hvad der er udrullet hvor

CRACI's inventaroversigt viser præcis, hvilke softwareversioner der er udrullet til hvilke produkter, globalt. Når en ny sårbarhed dukker op, kan du se, hvilke produkter der kører den berørte version, i stedet for at stykke det sammen fra release notes og regneark.

Behold SOC 2-platformen

CRACI er ikke en platform til compliance-automatisering og erstatter ikke en sådan. Det administrerer ikke politikker, adgangsgennemgange, enhedstjek eller leverandørspørgeskemaer. De to besvarer forskellige spørgsmål. Din compliance-platform viser, at en kontrol findes og kører. CRACI registrerer, hvad buildet trak ind, og om den registrering er komplet.

Forskellen vokser, når du sælger software i EU. Cyber Resilience Act kræver, at producenter identificerer og dokumenterer komponenter ved at udarbejde en softwarestykliste i et almindeligt anvendt og maskinlæsbart format, der som minimum dækker produkternes afhængigheder på øverste niveau (bilag I, del II). Bilag VII placerer SBOM'en i den tekniske dokumentation og lader en markedsovervågningsmyndighed anmode om den. En SOC 2-rapport attesterer, hvordan din organisation driver sine kontroller. En CRA-SBOM beskriver et bestemt produkt. Vores overblik over CRA dækker tidslinjen, og siden om CRA-compliance dækker, hvad CRACI automatiserer. CRACI automatiserer en væsentlig del af den synlighed i og dokumentation for forsyningskæden, som en bredere CRA-compliance-proces har brug for; det gør dig ikke compliant alene.

Sådan prøver du det uden at røre din audit

1. Vælg ét repository, hvis SBOM allerede indgår i din SOC 2-dokumentation.
2. Peg dets release-workflow mod CRACI ved at ændre runs-on til craci.
3. Sammenlign den registrerede SBOM med den, du genererer i dag, komponent for komponent, og tjek jobbets fuldstændighedsstatus.
4. Afgør, om forskellen hører hjemme i din dokumentation.

Du kan læse mere om SBOM-generering under buildet og CRA-dokumentation eller se, hvordan vi dokumenterer vores egne kontroller, på vores sikkerhedsside.