Le SBOM come evidenza di conformità: ISO 27001, SOC 2 e NIS2

L'evidenza non è la conformità

Un controllo è soddisfatto da un processo che funziona. L'evidenza dimostra che funziona. Una SBOM dimostra una cosa precisa: che cosa conteneva una determinata release. Non dice nulla sul controllo degli accessi, sulla risposta agli incidenti o sul fatto che qualcuno abbia agito su un risultato.

Può anche essere sbagliata senza che nessuno se ne accorga. Un generatore che ha letto i file sbagliati produce una SBOM valida che manca metà del prodotto. La scansione delle vulnerabilità di quella SBOM è pulita, la piattaforma di compliance vede che una scansione è stata eseguita e tutti i controlli risultano verdi. Che cosa verifica un controllo SBOM SOC 2 verde descrive questo errore nel dettaglio.

L'evidenza tratta da una SBOM conta quando è:

1. Legata a una release. Una SBOM per ogni versione consegnata, non una per il repository.
2. Completa, o dichiara che cosa le manca. Una SBOM che dichiara le proprie lacune è affidabile per ciò che elenca.
3. Conservata per il periodo coperto dall'audit. Un auditor che campiona lo scorso marzo ha bisogno della SBOM dello scorso marzo.
4. Rivalutata quando compaiono nuove vulnerabilità. Un elenco che nessuno confronta con i nuovi advisory dimostra poco sulla gestione delle vulnerabilità.

Per sapere che cosa contiene una SBOM, veda che cos'è una SBOM. Per i framework di sviluppo sicuro dei prodotti industriali e del software federale statunitense, veda IEC 62443-4-1 e NIST SSDF.

ISO/IEC 27001:2022

ISO/IEC 27001 è la norma rispetto alla quale si certifica un sistema di gestione della sicurezza delle informazioni (glossario). L'Annex A elenca 93 controlli; un'organizzazione sceglie quelli richiesti dalla sua valutazione del rischio e li registra nella dichiarazione di applicabilità (Statement of Applicability). ISO/IEC 27002:2022 fornisce la guida all'attuazione. Nessuna delle due nomina le SBOM. La tabella cita solo i titoli dei controlli, nella versione inglese, e riassume l'oggetto di ciascuno.

Controllo	Di che cosa tratta	Come una SBOM o un registro di build fa da evidenza	Che cosa non copre
5.9 "Inventory of information and other associated assets"	Sapere quali asset possiede e chi ne è responsabile	Il software che consegna ed esegue è un asset. Un elenco dei componenti per release è l'inventario di ciò che contiene.	Hardware, dati, persone e servizi
5.19 "Information security in supplier relationships", 5.20 "Addressing information security within supplier agreements", 5.21 "Managing information security in the ICT supply chain", 5.22 "Monitoring, review and change management of supplier services"	Gestire il rischio legato ai fornitori e alla supply chain ICT	In due direzioni. Come acquirente, può richiedere SBOM ai fornitori e monitorarle. Come fornitore, la Sua SBOM è ciò che Le chiede il processo di supply chain del Suo cliente certificato. I componenti open source fanno parte della supply chain ICT ma non hanno alcun accordo con un fornitore, ed è proprio per questo che il loro inventario conta.	Contratti, valutazioni e revisioni dei fornitori
8.8 "Management of technical vulnerabilities"	Ottenere informazioni sulle vulnerabilità, valutare la propria esposizione e agire	Un elenco dei componenti aggiornato, confrontato con gli advisory e rivalutato quando ne escono di nuovi, più un registro di quali release contenevano una versione vulnerabile e da quando	L'applicazione di patch alla Sua infrastruttura, la scansione degli host e le decisioni stesse
8.25 "Secure development life cycle"	Regole per sviluppare software e sistemi in modo sicuro	Un processo di release registrato e ripetibile: ogni release compilata nella stessa pipeline, con la sua SBOM	La maggior parte del controllo: formazione, ambienti, progettazione e revisione
8.26 "Application security requirements", 8.27 "Secure system architecture and engineering principles", 8.28 "Secure coding"	Requisiti, progettazione e codice	Non direttamente. Riguardano ciò che Lei scrive, non ciò che integra.	Tutto: qui l'evidenza sono la code review, il SAST e la documentazione di progetto
8.29 "Security testing in development and acceptance"	Testare la sicurezza prima della release	Un policy gate che blocca una build su un risultato di vulnerabilità è un test registrato con un esito	Test di sicurezza funzionali, penetration test
8.30 "Outsourced development"	Indirizzare e monitorare lo sviluppo esternalizzato	Il codice esternalizzato compilato nella Sua pipeline riceve la stessa SBOM e gli stessi controlli del Suo	Il contratto, le pratiche proprie del fornitore

Sia onesto su 8.25-8.30: la maggior parte di ciò che questi controlli chiedono è al di fuori di una SBOM. Rivendicare di più è il modo più rapido per perdere la fiducia di un auditor su tutto il resto.

Esempio pratico: un auditor chiede dell'8.8

«Come fate a sapere quando una nuova vulnerabilità riguarda un prodotto che avete già consegnato?» Ecco la catena di evidenze per un advisory, e chi fornisce ciascun anello.

Passaggio	Evidenza	Proviene da
1. Il contenuto della release	La SBOM della versione 4.2, registrata dalla build che l'ha prodotta	I Suoi strumenti di build
2. La corrispondenza con l'advisory	Una nuova CVE pubblicata per una libreria di quella SBOM, individuata tramite il suo package URL	Il Suo monitoraggio delle vulnerabilità
3. La finestra di esposizione	Ogni build che conteneva la versione vulnerabile, e la data della prima	La Sua cronologia delle build
4. La decisione	Chi l'ha valutata, quando, e con quale esito: correggere, mitigare o non interessato, con la motivazione	Il Suo processo e i relativi registri
5. La correzione	La versione 4.2.1, la cui SBOM non contiene più la versione vulnerabile	I Suoi strumenti di build

Gli strumenti possono fornire i passaggi 1, 2, 3 e 5. Il passaggio 4 è il Suo processo, ed è quello che gli auditor leggono con più attenzione.

SOC 2

Un report SOC 2 indica se i controlli soddisfano i Trust Services Criteria dell'AICPA (2017, con punti di attenzione rivisti nel 2022). I criteri descrivono risultati. Non nominano le SBOM, e due di essi sono quelli in cui le SBOM aiutano.

• CC7.1 chiede che l'entità utilizzi procedure di rilevamento e monitoraggio per identificare (1) le modifiche di configurazione che introducono nuove vulnerabilità e (2) l'esposizione a vulnerabilità appena scoperte. Evidenza: una SBOM per release, rivalutata rispetto ai nuovi advisory, e un registro di come è stato gestito ogni risultato.
• CC8.1 riguarda la gestione delle modifiche: come le modifiche a infrastruttura, dati, software e procedure vengono autorizzate, sviluppate o acquisite, testate, approvate e implementate. Evidenza: ogni release compilata in una pipeline registrata, le variazioni delle dipendenze visibili da una build all'altra, e i policy gate come controllo su ciò che può essere rilasciato.

I criteri sono in revisione. Nell'ottobre 2026 l'AICPA ha pubblicato una bozza (exposure draft) dei Trust Services Criteria 2027, con una ristrutturazione mirata dei criteri, commenti entro il 15 gennaio 2027 e una data di efficacia proposta per gli incarichi che iniziano il 31 dicembre 2027 o dopo. È una bozza e la numerazione dei criteri può cambiare: verifichi il testo definitivo prima di associare le evidenze ai nuovi numeri.

Se usa già una piattaforma SOC 2, la mantenga. La domanda è che cosa mostra la SBOM dietro i suoi controlli: i controlli SBOM SOC 2 a confronto.

NIS2

La direttiva (UE) 2022/2555 (direttiva NIS 2) si applica ai soggetti essenziali e importanti dei settori che elenca. Se legge questa pagina come fornitore di software o di dispositivi, di solito non rientra direttamente nel suo ambito. Il Suo cliente sì, e i suoi obblighi Le arrivano sotto forma di domande. L'articolo 21 stabilisce le misure di gestione dei rischi di cibersicurezza, e tre passaggi generano la maggior parte di queste domande:

• Articolo 21, paragrafo 2, lettera d): «sicurezza della catena di approvvigionamento, compresi aspetti relativi alla sicurezza riguardanti i rapporti tra ciascun soggetto e i suoi diretti fornitori o fornitori di servizi».
• Articolo 21, paragrafo 2, lettera e): «sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informatici e di rete, compresa la gestione e la divulgazione delle vulnerabilità».
• Articolo 21, paragrafo 3: i soggetti tengono conto «delle vulnerabilità specifiche per ogni diretto fornitore e fornitore di servizi e della qualità complessiva dei prodotti e delle pratiche di cibersicurezza dei propri fornitori e fornitori di servizi, comprese le loro procedure di sviluppo sicuro». È la frase che diventa un questionario sulla Sua scrivania.

Regolamento di esecuzione (UE) 2024/2690

Il regolamento di esecuzione (UE) 2024/2690 della Commissione del 17 ottobre 2024 stabilisce i requisiti tecnici e metodologici delle misure dell'articolo 21, paragrafo 2, per i fornitori di servizi DNS, i gestori di registri dei nomi di dominio di primo livello, i fornitori di servizi di cloud computing, i fornitori di servizi di data center, i fornitori di reti di distribuzione dei contenuti, i fornitori di servizi gestiti, i fornitori di servizi di sicurezza gestiti, i mercati online, i motori di ricerca online, le piattaforme di servizi di social network e i prestatori di servizi fiduciari. Non vincola gli altri settori NIS2, ma è la descrizione pubblica più dettagliata di che cosa significhi «sicurezza della catena di approvvigionamento», e altri acquirenti vi si ispirano. I punti che arrivano ai fornitori:

Punto dell'allegato	Che cosa dice	Che cosa si chiede al fornitore
5.1.2, lettera a)	I criteri di selezione dei fornitori includono «le pratiche in materia di cibersicurezza dei fornitori e dei fornitori di servizi, comprese le loro procedure di sviluppo sicuro»	Come sviluppa in modo sicuro, e come sa che cosa entra nel Suo prodotto?
5.1.4, lettere e) e f)	I contratti specificano, se del caso, il diritto a effettuare audit o a ricevere relazioni di audit, e «l'obbligo per i fornitori e i fornitori di servizi di gestire le vulnerabilità che presentano un rischio» per il soggetto	Gestirà le vulnerabilità di ciò che consegna, e possiamo vederne l'evidenza?
5.2	Un registro dei diretti fornitori, con «un elenco di prodotti TIC, servizi TIC e processi TIC» forniti da ciascuno	Quali prodotti e quali versioni ci fornisce?
6.1.2, lettera c)	Per l'acquisizione di servizi TIC o prodotti TIC: «informazioni che descrivono i componenti hardware e software utilizzati nei servizi TIC o nei prodotti TIC»	Quali componenti hardware e software contiene il Suo prodotto? Il testo di questa pagina che si avvicina di più a una SBOM, e comunque non la nomina.
6.10	Gestione delle vulnerabilità: monitorare le informazioni sulle vulnerabilità attraverso canali come i bollettini dei CSIRT o «le informazioni messe a disposizione da fornitori o fornitori di servizi» (6.10.2, lettera a)) e, quando una vulnerabilità non richiede rimedio, documentare e motivare «la ragione per cui la vulnerabilità non richiede alcun rimedio» (6.10.3)	Come ci informerà delle vulnerabilità, e perché questa non è un problema?

L'ultimo punto descrive una dichiarazione di non interessato con la sua motivazione. È ciò che contiene un documento VEX, anche se il regolamento non indica alcun formato.

Esempio pratico: il questionario di un cliente soggetto a NIS2

Cinque domande del tipo che un cliente ricava da questi punti, con l'evidenza che un fornitore può allegare. Alcune risposte vengono da registri conservati dai Suoi strumenti; altre sono policy che scrive Lei.

Domanda	Evidenza da allegare	Registro o policy
«Elenchi i componenti software della versione del prodotto che ci consegna.» (6.1.2, lettera c))	La SBOM di quella versione, in CycloneDX o SPDX, con la sua completezza dichiarata	Registro
«Descriva la Sua gestione delle vulnerabilità e i relativi tempi.» (5.1.4, lettera f))	La Sua procedura di gestione delle vulnerabilità, con livelli di gravità e tempi obiettivo	Policy
«Quali delle versioni che usiamo contenevano la libreria vulnerabile, e da quando?» (6.10)	La cronologia delle build, con ogni build che conteneva il componente e le date	Registro
«Perché questa CVE non ci riguarda?» (6.10)	Una dichiarazione di non interessato con la sua giustificazione, per esempio «il codice vulnerabile non è presente»	Registro, basato sulla Sua valutazione
«Come possono i ricercatori segnalare vulnerabilità nei Suoi prodotti?» (5.1.2, lettera a))	La Sua policy di divulgazione coordinata delle vulnerabilità	Policy

Una distinzione da tenere presente: per i prodotti con elementi digitali venduti nell'UE, il Cyber Resilience Act (regolamento sulla ciberresilienza) richiede invece una SBOM. NIS2 no.

DORA, se vende a entità finanziarie

Il regolamento (UE) 2022/2554 relativo alla resilienza operativa digitale (DORA) si applica alle entità finanziarie, non direttamente ai loro fornitori. Le entità finanziarie devono individuare e documentare i loro asset ICT e le relative interdipendenze e tenerne inventari (articolo 8, paragrafi 1, 4 e 6), gestire il rischio derivante da terzi fornitori di servizi ICT nell'ambito del loro rischio informatico (articolo 28, paragrafo 1), tenere un registro di informazioni su tutti i contratti per servizi ICT (articolo 28, paragrafo 3) e inserire disposizioni minime in tali contratti (articolo 30). DORA non nomina le SBOM. Per un fornitore di software a una banca, un elenco dei componenti per release aiuta il cliente a rispettare l'articolo 8.

Un'unica mappa delle evidenze per tutti

Le righe sono evidenze; ogni cella indica il controllo, il criterio o il punto che supportano, oppure «non direttamente».

Evidenza	ISO/IEC 27001:2022	SOC 2	NIS2 e 2024/2690	DORA
1. Una SBOM per release, con la sua completezza dichiarata	5.9, 5.21, 8.8	CC7.1	Art. 21(2)(d); 6.1.2(c)	Art. 8 (l'inventario del cliente)
2. Rivalutazione continua rispetto ai nuovi advisory	8.8	CC7.1	Art. 21(2)(e); 6.10	Non direttamente
3. Cronologia delle build: quali release contenevano un componente, e da quando	8.8	CC7.1, CC8.1	6.10	Non direttamente
4. Registri di triage e assegnazione	8.8	CC7.1	Art. 21(2)(e); 6.10	Non direttamente
5. Dichiarazioni di non interessato con motivazione	8.8	CC7.1	6.10	Non direttamente
6. Policy gate che bloccano una build	8.25, 8.29	CC8.1	Art. 21(2)(e)	Non direttamente
7. SBOM dei fornitori monitorate insieme alle Sue	5.19, 5.21, 5.22	CC7.1	Art. 21(2)(d), 21(3); 5.2, 6.10	Art. 28(1)
8. Policy di egress e registri di rete della build	8.25	CC8.1	Art. 21(2)(d)	Non direttamente

Che cosa una SBOM non dimostrerà

• Il Suo controllo degli accessi, la risposta agli incidenti, la continuità operativa, la sicurezza delle risorse umane, la crittografia o la sicurezza fisica.
• Che qualcuno abbia corretto qualcosa. Questo è il Suo processo, con i suoi registri.
• Che il Suo codice sia privo di difetti. L'evidenza per questo sono la code review, il SAST e i test.
• Che cosa c'è nei binari ricevuti senza SBOM.
• Che Lei è certificato. Una SBOM non è un certificato, e un certificato detenuto dal fornitore dei Suoi strumenti certifica il sistema di gestione di quel fornitore, non Lei.

Il ruolo di CRACI

CRACI sostituisce i Suoi runner ospitati da GitHub e registra ciò che ogni build ha scaricato, così la SBOM proviene dalla build di release stessa, con uno stato di completezza per ogni job.

• Le SBOM monitorate vengono rivalutate di continuo man mano che vengono pubblicate nuove vulnerabilità (tracciamento delle vulnerabilità).
• La cronologia delle build mostra quali build contenevano una dipendenza vulnerabile, e quindi il periodo in cui era esposto, entro il Suo periodo di conservazione. Se il Suo audit copre un periodo più lungo, esporti la SBOM di ogni release e la conservi insieme alla release.
• I team di sicurezza fanno il triage delle vulnerabilità individuate e le inviano ai team responsabili della correzione, e CRACI supporta VEX per registrare quali prodotti una vulnerabilità non interessa.
• I policy gate possono bloccare una build in base ai risultati, compresa una build che contiene una CVE specifica.
• È possibile aggiungere SBOM di terze parti, così i componenti acquistati vengono monitorati insieme alle Sue build.
• Le SBOM si esportano in CycloneDX o SPDX, e l'API restituisce SBOM, tracce di rete e dati di provenienza. La policy di egress registra e limita le destinazioni a cui ogni build può connettersi.

CRACI fornisce evidenze per questi controlli. Non La rende conforme a ISO 27001 o SOC 2 né pronto per NIS2, e non è una piattaforma di compliance automation. Il certificato di CRACI è un fatto distinto: il sistema di gestione della sicurezza delle informazioni di CRACI Corporation Oy per lo sviluppo e l'esercizio della piattaforma CRACI è certificato ISO/IEC 27001, rilasciato da Into Certification. Copre il modo in cui CRACI gestisce il proprio servizio, non la Sua organizzazione né i Suoi prodotti. Veda la sicurezza in CRACI, e come funziona CRACI per l'intera piattaforma.

Quando CRACI non è la risposta

• Le Sue build non girano su GitHub Actions. È l'unica CI che CRACI supporta oggi; altri sistemi di CI sono nella roadmap.
• Le serve una piattaforma di compliance automation per policy, revisioni degli accessi e flusso di lavoro con gli auditor. Ne mantenga o ne acquisti una; veda i controlli SBOM SOC 2 a confronto.
• Le Sue lacune di evidenza sono soprattutto organizzative: policy, formazione, risposta agli incidenti.
• Il Suo principale rischio legato ai fornitori sono i binari ricevuti senza SBOM. Qui la risposta è l'analisi binaria.

Sta rispondendo alla richiesta di un cliente? Veda come rispondere a una richiesta di SBOM di un cliente, la guida per i fornitori di componenti e la checklist che applicherà il Suo cliente.

Le SBOM come evidenza di conformità: domande frequenti

ISO 27001 richiede una SBOM?

No. ISO/IEC 27001:2022 non nomina le SBOM. I controlli 5.9 (inventario), 5.21 (supply chain ICT) e 8.8 (vulnerabilità tecniche) dell'Annex A chiedono risultati che una SBOM supporta, e sono l'organizzazione e il suo auditor a decidere quale evidenza basti.

SOC 2 richiede una SBOM?

No. I Trust Services Criteria descrivono risultati e non nominano le SBOM. Una SBOM per release, rivalutata rispetto ai nuovi advisory, è evidenza per CC7.1, e una pipeline di build registrata supporta CC8.1 sulla gestione delle modifiche.

NIS2 richiede una SBOM?

No. L'articolo 21, paragrafo 2, lettera d), chiede la sicurezza della catena di approvvigionamento e la lettera e) la gestione delle vulnerabilità, senza nominare le SBOM. Il regolamento di esecuzione (UE) 2024/2690, che riguarda alcuni fornitori di servizi digitali, chiede al punto 6.1.2, lettera c), informazioni sui componenti hardware e software dei prodotti TIC, sempre senza la parola SBOM.

Quali controlli dell'Annex A di ISO 27001 supporta una SBOM?

Soprattutto 5.9 (inventario delle informazioni e degli altri asset associati), da 5.19 a 5.22 (fornitori e supply chain ICT) e 8.8 (gestione delle vulnerabilità tecniche). Un registro di build tocca in parte 8.25, 8.29 e 8.30. I controlli da 8.26 a 8.28 riguardano requisiti, progettazione e codice, al di fuori di una SBOM.

Che cosa chiedono i clienti soggetti a NIS2 ai loro fornitori di software?

Di solito una descrizione dello sviluppo sicuro, i componenti della versione consegnata, l'impegno a gestire le vulnerabilità, un canale per ricevere informazioni sulle vulnerabilità e le motivazioni quando una vulnerabilità non si applica. Queste domande derivano dall'articolo 21, paragrafo 3, e, per alcuni settori, dai punti sui fornitori del regolamento di esecuzione 2024/2690.

Una SBOM basta come evidenza per il controllo 8.8 di ISO 27001?

No. Mostra che cosa contiene ogni release. Il controllo 8.8 richiede anche evidenza che Lei ottiene informazioni sulle vulnerabilità, valuta la Sua esposizione e agisce. Affianchi alla SBOM una rivalutazione continua, un registro delle release interessate e le decisioni prese.

Qual è la differenza tra essere conformi e avere evidenze?

Essere conformi significa che i Suoi processi soddisfano i requisiti del framework, secondo il giudizio di un auditor o di un cliente. L'evidenza è ciò che dimostra che quei processi funzionano. Una SBOM è evidenza per alcuni controlli. Non La rende conforme ad alcun framework.