La Sua piattaforma SOC 2 mostra che il controllo funziona. CRACI registra che cosa conteneva la build.

La configurazione di cui parla questa pagina

Molti team SaaS finiscono con lo stesso assetto. Un generatore come Syft o Trivy produce una SBOM in CI, uno scanner di vulnerabilità sorveglia i repository e una piattaforma di compliance automation si collega a GitHub e all'account cloud per raccogliere le evidenze per SOC 2. Funziona. Gli auditor lo accettano e nessuno passa la settimana prima di un audit a fare screenshot.

Queste piattaforme fanno bene il loro lavoro. Vanta afferma che "connects read-only to your cloud, identity, code, and device tools" e che "automatically pulls evidence, maps it to controls", con più di 1.200 test automatizzati eseguiti ogni ora. Drata si collega a "cloud infrastructure, identity providers, HR systems, code repositories, ticketing tools, and more" per raccogliere le evidenze e associarle ai controlli SOC 2. Se l'obiettivo è un report SOC 2 pulito, è lo strumento giusto.

Questa pagina riguarda una domanda più ristretta: che cosa dicono quelle evidenze sulla SBOM stessa.

Che cosa chiede davvero un controllo SOC 2

Gli esami SOC 2 fanno riferimento agli AICPA Trust Services Criteria. Il criterio più vicino alle SBOM è 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

Il criterio descrive un risultato. Lascia a Lei e al Suo auditor il metodo e la profondità dell'inventario dei componenti che lo sostiene. Per questo un test automatizzato di solito chiede se il controllo è in atto e operativo: uno scanner è collegato, è stato eseguito, i risultati sono stati gestiti secondo la Sua policy? È una domanda legittima, ed è la casella da spuntare.

Ciò che il controllo non chiede è se la SBOM alla base della scansione elencava tutto ciò che la release conteneva. Una vulnerabilità in un componente che la SBOM non ha mai elencato non può essere associata a nulla, quindi la scansione risulta pulita e il controllo resta verde.

Dove un controllo verde e una SBOM completa divergono

I generatori di SBOM lavorano sui file che hanno davanti, e la loro stessa documentazione mostra dove restano le lacune:

• Su expressjs/express 5.2.1, che non include alcun lockfile, un generatore che risolve le dipendenze dai lockfile non ha nulla da risolvere. Può comunque restituire un documento, elencando qualsiasi altra cosa riconosca, come GitHub Actions e file di workflow, e nessuna delle dipendenze npm dichiarate in package.json.
• Generatori diversi restituiscono elenchi diversi dallo stesso checkout, perché ciascuno decide da sé che cosa conta come componente. L'esportazione del dependency graph di GitHub si allontana ancora di più: è costruita a partire da ciò che GitHub sa del repository e legge il branch predefinito anziché il commit fissato.
• Il campo supplier dell'NTIA risulta vuoto nella maggior parte dei documenti, perché la maggior parte dei generatori non ha una fonte per questo dato.

Nessuno di questi strumenti è difettoso. Ciascuno ha letto i file su cui era puntato e ha prodotto un documento valido in un formato standard, nei tempi previsti. Per un test di conformità, il controllo ha funzionato. La SBOM però non descriveva il software.

Che cosa aggiunge CRACI alle evidenze

CRACI sostituisce il runner GitHub Actions. Lei cambia runs-on in craci, e le esecuzioni continuano a comparire nell'interfaccia di GitHub. La SBOM viene generata all'interno di quel runner durante la build: un proxy che riconosce i pacchetti osserva il traffico verso le sorgenti dei pacchetti, quindi il record riflette ciò che il job ha scaricato e non ciò che un file dice che dovrebbe scaricare.

La completezza è dichiarata, non presunta

Ogni job e ogni cache riceve uno dei cinque stati di completezza: Complete, Complete with connections, Incomplete, Unavailable o Not recorded. Le evidenze sulle dipendenze viaggiano con le cache, quindi i pacchetti ripristinati da una warm cache vengono riportati nel record invece di scomparire silenziosamente. Quando un record è incompleto, lo dichiara.

Questo corrisponde alla direzione degli standard. Gli SBOM minimum elements 2026 di CISA e dei suoi partner chiedono agli autori di SBOM di "explicitly state whether the information is unknown to the SBOM author" invece di lasciare campi vuoti senza dirlo.

Evidenze nei formati accettati dagli auditor

Le SBOM si esportano in CycloneDX o SPDX, comprese le vulnerabilità rilevate nei loro componenti. L'API REST pubblica restituisce la SBOM, la traccia di rete del job e i dati di provenance, quindi gli stessi record possono andare ovunque si trovino le Sue evidenze di audit.

Un inventario di che cosa è distribuito e dove

La vista inventario di CRACI mostra esattamente quali versioni del software sono distribuite in quali prodotti, a livello globale. Quando arriva una nuova vulnerabilità, può vedere quali prodotti eseguono la versione interessata invece di ricostruirlo da note di rilascio e fogli di calcolo.

Mantenga la piattaforma SOC 2

CRACI non è una piattaforma di compliance automation e non ne sostituisce una. Non gestisce policy, revisioni degli accessi, controlli sui dispositivi o questionari per i vendor. I due rispondono a domande diverse. La Sua piattaforma di compliance mostra che un controllo esiste e funziona. CRACI registra ciò che la build ha scaricato e se quel record è completo.

La differenza cresce quando vende software nell'UE. Il Cyber Resilience Act impone ai fabbricanti di identificare e documentare i componenti redigendo una distinta base del software in un formato di uso comune e leggibile da dispositivo automatico, che comprenda almeno le dipendenze di primo livello dei prodotti (allegato I, parte II). L'allegato VII colloca la SBOM nella documentazione tecnica e consente a un'autorità di vigilanza del mercato di richiederla. Un report SOC 2 attesta come la Sua organizzazione gestisce i propri controlli. Una SBOM per il CRA descrive un prodotto specifico. La nostra panoramica del CRA illustra le scadenze, e la pagina sulla conformità al CRA illustra che cosa automatizza CRACI. CRACI automatizza una parte significativa della visibilità e delle evidenze sulla supply chain di cui ha bisogno un più ampio processo di conformità al CRA; da solo non La rende conforme.

Come provarlo senza toccare il Suo audit

1. Scelga un repository la cui SBOM alimenta già le Sue evidenze SOC 2.
2. Punti il suo workflow di release su CRACI cambiando runs-on in craci.
3. Confronti la SBOM registrata con quella che genera oggi, componente per componente, e controlli lo stato di completezza del job.
4. Decida se la differenza debba entrare nelle Sue evidenze.

Può approfondire la generazione di SBOM in fase di build e le evidenze per il CRA, oppure vedere come documentiamo i nostri controlli nella nostra pagina sulla sicurezza.