Din SOC 2-plattform visar att kontrollen körs. CRACI registrerar vad bygget innehöll.

Lösningen den här sidan handlar om

Många SaaS-team hamnar i samma upplägg. En generator som Syft eller Trivy tar fram en SBOM i CI, en sårbarhetsskanner bevakar repona, och en plattform för efterlevnadsautomation ansluter till GitHub och molnkontot för att samla in bevis för SOC 2. Det fungerar. Revisorer godtar det, och ingen ägnar veckan före en revision åt att ta skärmdumpar.

De plattformarna är bra på det här. Vanta säger att det "connects read-only to your cloud, identity, code, and device tools" och "automatically pulls evidence, maps it to controls," med fler än 1 200 automatiserade tester som körs varje timme. Drata ansluter till "cloud infrastructure, identity providers, HR systems, code repositories, ticketing tools, and more" för att samla in bevis och koppla dem till SOC 2-kontroller. Om målet är en ren SOC 2-rapport är det rätt verktyg för jobbet.

Den här sidan handlar om en smalare fråga: vad de bevisen säger om själva SBOM:en.

Vad en SOC 2-kontroll faktiskt frågar efter

SOC 2-granskningar rapporterar mot AICPA:s Trust Services Criteria. Det kriterium som ligger närmast SBOM:er är 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 ett resultat. Metoden, och hur djup komponentinventeringen bakom den är, lämnar det till dig och din revisor. Ett automatiserat test frågar därför oftast om kontrollen finns och fungerar: är en skanner ansluten, kördes den, hanterades fynden enligt din policy. Det är en rimlig fråga, och det är kryssrutan.

Vad kontrollen inte frågar är om SBOM:en bakom skanningen listade allt som releasen innehöll. En sårbarhet i en komponent som SBOM:en aldrig listade kan inte matchas mot något, så skanningen ser ren ut och kontrollen visas fortfarande som grön.

Där en grön kontroll och en komplett SBOM går isär

SBOM-generatorer utgår från filerna framför dem, och deras egen dokumentation visar var det lämnar luckor:

• På expressjs/express 5.2.1, som inte checkar in någon lockfile, har en generator som löser beroenden från lockfiler inget att lösa. Den kan ändå returnera ett dokument som listar vad den annars känner igen, till exempel GitHub Actions och arbetsflödesfiler, men inget av npm-beroendena som deklareras i package.json.
• Olika generatorer returnerar olika listor från samma utcheckning, eftersom var och en själv avgör vad som räknas som en komponent. GitHubs export av beroendegrafen ligger ännu längre bort: den bygger på vad GitHub vet om repot och läser standardgrenen i stället för den låsta commiten.
• NTIA:s leverantörsfält är tomt i de flesta dokument, eftersom de flesta generatorer saknar en källa för det.

Inget av de verktygen är trasigt. Vart och ett läste filerna det pekades mot, och vart och ett tog fram ett giltigt dokument i ett standardformat, enligt schema. För ett efterlevnadstest fungerade kontrollen. SBOM:en beskrev ändå inte programvaran.

Vad CRACI tillför bevisen

CRACI ersätter GitHub Actions-runnern. Du ändrar runs-on till craci, och körningar syns fortfarande i GitHubs gränssnitt. SBOM:en genereras inne i runnern medan bygget pågår: en paketmedveten proxy observerar trafik till paketkällor, så registreringen återspeglar vad jobbet hämtade snarare än vad en fil säger att det borde hämta.

Fullständigheten anges, den antas inte

Varje jobb och varje cache får en av fem fullständighetsstatusar: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Beroendebevisen följer med cachar, så paket som återställs från en varm cache följer med i stället för att tyst försvinna. När en registrering är ofullständig säger den det.

Det stämmer med vart standarderna är på väg. 2026 års SBOM minimum elements från CISA och dess partner ber SBOM-författare att "explicitly state whether the information is unknown to the SBOM author" i stället för att tyst lämna fält tomma.

Bevis i format som revisorer tar emot

SBOM:er exporteras som CycloneDX eller SPDX, inklusive sårbarheterna som hittats i deras komponenter. Det publika REST-API:t returnerar SBOM:en, jobbets nätverksspårning och proveniensdata, så att samma registreringar kan gå dit dina revisionsbevis finns.

En inventering av vad som är driftsatt var

CRACI:s inventeringsvy visar exakt vilka programvaruversioner som är driftsatta i vilka produkter, globalt. När en ny sårbarhet dyker upp ser du vilka produkter som kör den berörda versionen i stället för att pussla ihop det från release notes och kalkylblad.

Behåll SOC 2-plattformen

CRACI är ingen plattform för efterlevnadsautomation och ersätter inte en sådan. Det hanterar inte policyer, åtkomstgranskningar, enhetskontroller eller leverantörsenkäter. De två besvarar olika frågor. Din efterlevnadsplattform visar att en kontroll finns och körs. CRACI registrerar vad bygget drog in och om den registreringen är komplett.

Skillnaden växer när du säljer programvara i EU. Cyber Resilience Act kräver att tillverkare identifierar och dokumenterar komponenter, bland annat genom att upprätta en programvaruförteckning i ett vanligt förekommande och maskinläsbart format som åtminstone omfattar produktens beroenden på högsta nivå (bilaga I, del II). Bilaga VII placerar SBOM:en i den tekniska dokumentationen och låter en marknadskontrollmyndighet begära den. En SOC 2-rapport intygar hur din organisation sköter sina kontroller. En SBOM för CRA beskriver en specifik produkt. Vår översikt över CRA går igenom tidslinjen, och sidan om CRA-efterlevnad går igenom vad CRACI automatiserar. CRACI automatiserar en betydande del av den insyn i och de bevis om leveranskedjan som ett bredare arbete med CRA-efterlevnad behöver; det gör dig inte regelefterlevande på egen hand.

Så provar du utan att röra din revision

1. Välj ett repo vars SBOM redan matar dina SOC 2-bevis.
2. Peka dess release-arbetsflöde mot CRACI genom att ändra runs-on till craci.
3. Jämför den registrerade SBOM:en med den du genererar i dag, komponent för komponent, och kontrollera jobbets fullständighetsstatus.
4. Avgör om skillnaden hör hemma i dina bevis.

Du kan läsa mer om SBOM-generering under bygget och CRA-bevis, eller se hur vi dokumenterar våra egna kontroller på vår säkerhetssida.