SBOM per l’assurance ISO 27001, NIS2 e DORA

Sono le 07:42 di un venerdì quando Amelia, CISO di una FinTech in rapida crescita, riceve l’allerta che nessun responsabile della sicurezza vorrebbe vedere.

Un pacchetto open source ampiamente utilizzato presenta una vulnerabilità critica di esecuzione di codice da remoto. Lo strumento di Software Composition Analysis (SCA) indica che il componente potrebbe essere presente nel servizio di autenticazione, forse nella fatturazione e forse in un wrapper API di terze parti utilizzato dal flusso di pagamento. Il team di engineering ha bisogno di tempo per confermare. Il Legal chiede se sia già iniziato il termine per la notifica NIS2. Il program manager DORA chiede se il servizio interessato supporti una funzione critica o importante per un’entità finanziaria. Le vendite chiedono se questo bloccherà un rinnovo. Il Consiglio di amministrazione pone la domanda più semplice e più difficile: “Siamo esposti?”

Senza una distinta base software, la risposta onesta è spesso: “Non lo sappiamo ancora.”

Nel 2026, questa risposta non è solo una lacuna tecnica. È una debolezza di governance, un rischio contrattuale, un’esposizione in sede di audit e, per i soggetti regolamentati, un problema di resilienza. Gli SBOM sono passati da pratica di igiene DevSecOps a evidenza a livello di Consiglio di amministrazione per l’assurance della catena di fornitura software, il funzionamento dei controlli ISO/IEC 27001:2022, la gestione dei rischi di cibersicurezza NIS2, la governance ICT delle terze parti prevista da DORA, l’accountability GDPR e la due diligence dei clienti.

Il punto non è semplicemente generare un file SBOM. Il punto è dimostrare che i componenti software sono identificati, approvati, monitorati, classificati in base al rischio, sottoposti a patch, disciplinati contrattualmente e tracciabili verso proprietari responsabili. È qui che la libreria di politiche Clarysec, Zenith Blueprint: roadmap dell’auditor in 30 passaggi e Zenith Controls: guida alla cross-compliance trasformano un artefatto per sviluppatori in evidenza di conformità difendibile.

Perché gli SBOM sono ora evidenze di assurance della catena di fornitura software

Un SBOM è un inventario dei componenti software, inclusi pacchetti open source, librerie commerciali, versioni, fonti, licenze e relazioni di dipendenza. Un SBOM utile aiuta a rispondere a quattro domande che autorità di regolamentazione, clienti e Consigli di amministrazione considerano ormai rilevanti:

1. Che cosa è contenuto nel nostro software?
2. Dove è distribuito?
3. È vulnerabile, non supportato, privo di licenza o non approvato?
4. Chi è responsabile della remediation, della mitigazione o dell’accettazione del rischio?

Queste domande si collegano direttamente alle aspettative legali e normative moderne.

NIS2 si applica a molte entità medie e grandi nei settori essenziali e importanti, incluse infrastrutture digitali, fornitori di servizi di cloud computing, fornitori di servizi di data center, fornitori di servizi gestiti, fornitori di servizi di sicurezza gestiti, marketplace online, motori di ricerca, piattaforme di social networking e alcuni fornitori digitali. Può applicarsi anche in base alla designazione nazionale e al recepimento settoriale. Per le entità rientranti nell’ambito di applicazione, NIS2 richiede agli organi di gestione di approvare le misure di gestione dei rischi di cibersicurezza e di vigilare sulla loro attuazione. Article 21 include sicurezza della catena di fornitura, acquisizione sicura, sviluppo sicuro e manutenzione, trattamento e divulgazione delle vulnerabilità, gestione degli incidenti, continuità operativa, gestione degli asset, controllo degli accessi, crittografia, valutazione dell’efficacia e cyber hygiene.

DORA, applicabile dal 17 gennaio 2025, istituisce un quadro uniforme dell’UE per la resilienza operativa digitale delle entità finanziarie. Copre gestione del rischio ICT, segnalazione degli incidenti connessi all’ICT, test di resilienza, gestione del rischio ICT di terze parti, accordi contrattuali e vigilanza sui fornitori terzi critici di servizi ICT. DORA si attende che le entità finanziarie identifichino asset ICT, funzioni aziendali supportate dall’ICT, dipendenze, interconnessioni, vulnerabilità, scenari di rischio, modifiche e processi supportati da terze parti.

GDPR aggiunge un livello privacy. Se un componente vulnerabile interessa sistemi che trattano dati personali, la domanda diventa se tali dati personali possano essere stati consultati, alterati, persi, divulgati o altrimenti compromessi. Titolari e responsabili del trattamento devono disporre di evidenze che dimostrino la capacità di identificare sistemi interessati, flussi di dati, sub-responsabili e impatto della violazione.

NIST CSF 2.0 rafforza lo stesso modello operativo attraverso GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER. I suoi risultati attesi per la catena di fornitura richiedono responsabilità dei fornitori, criticità, requisiti contrattuali, due diligence, monitoraggio, pianificazione degli incidenti e disposizioni di fine rapporto.

Quando il Consiglio di amministrazione chiede ad Amelia se la FinTech è esposta, un’organizzazione supportata da SBOM può rispondere con evidenze:

• Quali prodotti e rilasci contengono il componente vulnerabile
• Quali ambienti distribuiti sono interessati
• Quali clienti, regioni, funzioni e flussi di dati sono collegati
• Quale fornitore o proprietario interno è responsabile
• Quali controlli compensativi sono attivi
• Se possono essere attivate soglie NIS2, DORA, GDPR o contrattuali
• Quale correzione, mitigazione, eccezione o accettazione del rischio è stata approvata

Questa è la differenza tra un elenco di componenti e un sistema di controllo.

ISO 27001:2022 è la dorsale della governance degli SBOM

ISO/IEC 27001:2022 è una base solida per la governance degli SBOM perché è uno standard per sistemi di gestione, non una semplice checklist tecnica. Le sue clausole richiedono alle organizzazioni di definire contesto, parti interessate, ambito di applicazione, impegno della leadership, politica, ruoli, valutazione del rischio, trattamento del rischio, obiettivi, valutazione delle prestazioni, audit interno, riesame di direzione e miglioramento continuo.

I programmi SBOM falliscono quando restano fuori dal SGSI. Il team di engineering può generare file, ma nessuno applica SLA di remediation delle vulnerabilità, obblighi dei fornitori, conservazione delle evidenze, accettazione del rischio o regole di comunicazione ai clienti. ISO 27001 risolve questo problema trasformando gli SBOM in parte del sistema di gestione del rischio dell’organizzazione.

Ai sensi delle clausole da 4.1 a 4.4, l’organizzazione determina fattori interni ed esterni, requisiti delle parti interessate, obblighi legali e normativi, aspettative contrattuali e campo di applicazione del SGSI. Per l’assurance SBOM, il campo di applicazione dovrebbe includere esplicitamente:

• Prodotti e servizi forniti ai clienti
• Ambienti di produzione cloud e SaaS
• Pipeline CI/CD, repository del codice sorgente e registry degli artefatti
• Componenti software open source e commerciali
• Partner di sviluppo esternalizzato e integrazione
• Fornitori ICT terzi e subappaltatori
• Requisiti di sicurezza dei clienti ai sensi di DORA, NIS2, GDPR e dei contratti

Le clausole da 5.1 a 5.3 trasformano il rischio della catena di fornitura software in una responsabilità della leadership. La direzione deve allineare gli obiettivi di sicurezza alla direzione aziendale, fornire risorse, assegnare responsabilità e comunicare la politica. Le clausole 6.1.2 e 6.1.3 trasformano le risultanze SBOM in evidenze di valutazione del rischio e trattamento del rischio. Un componente critico vulnerabile in un servizio di autenticazione esposto a Internet non è solo un ticket. È uno scenario di rischio che incide su riservatezza, integrità, disponibilità, impegni contrattuali, segnalazione normativa e resilienza operativa.

I controlli dell’Allegato A di ISO/IEC 27001:2022 più rilevanti per l’assurance SBOM sono:

Clarysec mappa queste relazioni tramite gli attributi ISO/IEC 27002:2022 in Zenith Controls. Ad esempio, Zenith Controls tratta il controllo ISO/IEC 27002:2022 5.21, “Gestione della sicurezza delle informazioni nella catena di fornitura ICT”, come preventivo, a protezione di riservatezza, integrità e disponibilità, allineato al concetto di cibersicurezza Identify e operativo nei domini di governance, ecosistema e protezione. Tratta il controllo 8.25, “Ciclo di vita di sviluppo sicuro”, come preventivo e allineato a Protect. Tratta il controllo 8.8, “Gestione delle vulnerabilità tecniche”, come preventivo e allineato a Identify e Protect, collegando la gestione delle vulnerabilità a governance, ecosistema, protezione e difesa.

Questa traduzione è importante perché revisori diversi pongono domande diverse. Un auditor ISO può chiedere se il rischio dei componenti sia incluso nella Dichiarazione di Applicabilità. Un revisore DORA può chiedere se un componente supporti una funzione critica o importante. Un cliente può chiedere se le vulnerabilità irrisolte superino gli SLA contrattuali. La stessa evidenza SBOM può supportare tutte e tre le esigenze, se è governata correttamente.

Il livello delle politiche Clarysec per SBOM pronti per l’audit

Un programma SBOM affidabile richiede linguaggio di policy. Gli sviluppatori devono sapere che cosa deve essere registrato. La funzione Acquisti deve sapere che cosa devono fornire i fornitori. La sicurezza deve sapere quali risultanze attivano l’escalation. La conformità deve sapere quali evidenze devono essere conservate.

Per le organizzazioni più piccole, la Politica di sviluppo sicuro - PMI crea il controllo SBOM minimo efficace:

Il GM o uno sviluppatore designato deve mantenere un elenco di tutti i componenti esterni utilizzati, inclusi: 6.6.2.1 Versione e fonte 6.6.2.2 Vulnerabilità note o stato della patch 6.6.2.3 Data dell’ultimo aggiornamento o riesame

Il requisito è semplice, ma efficace. Stabilisce visibilità delle versioni, tracciabilità delle fonti, stato delle vulnerabilità e cadenza di riesame.

La Politica sui requisiti di sicurezza delle applicazioni - PMI aggiunge il riesame del ciclo di vita:

Qualsiasi strumento, plugin o libreria di codice esterna di terze parti utilizzata in un’applicazione deve essere registrata e riesaminata annualmente per l’impatto sulla sicurezza e lo stato delle patch.

La Politica di gestione delle vulnerabilità e delle patch - PMI collega gli SBOM alla remediation:

Gli sviluppatori devono monitorare e aggiornare le librerie di terze parti (ad es. pacchetti open source)

Per gli ambienti enterprise, la Politica di sviluppo sicuro innalza l’aspettativa:

L’uso di codice open source o di terze parti deve essere approvato, tracciato e convalidato tramite:

Rende inoltre obbligatoria la scansione:

Tutti i componenti di terze parti devono essere sottoposti a scansione delle vulnerabilità prima del deployment e durante l’esecuzione mediante strumenti automatizzati.

Lo sviluppo esternalizzato deve seguire lo stesso standard. La Politica sullo sviluppo esternalizzato richiede:

Uso sicuro delle librerie open source, soggetto a scansione delle vulnerabilità e approvazione

I contratti con i fornitori richiedono diritti alle evidenze che possano essere fatti valere. La Politica di sicurezza delle terze parti e dei fornitori - PMI richiede clausole contrattuali relative a riservatezza, obblighi di sicurezza, tempistiche di notifica della violazione, diritto di audit, restrizioni al subappalto e cessazione sicura:

I contratti devono includere clausole obbligatorie relative a: 5.3.1 Riservatezza e non divulgazione 5.3.2 Obblighi di sicurezza delle informazioni 5.3.3 Tempistiche di notifica della violazione dei dati (ad es. entro 24–72 ore) 5.3.4 Diritto di audit o disponibilità di evidenze di conformità 5.3.5 Restrizioni all’ulteriore subappalto senza approvazione 5.3.6 Condizioni di risoluzione, inclusa la restituzione o distruzione sicura dei dati

Per i clienti enterprise, la Politica di sicurezza delle terze parti e dei fornitori include:

Diritto di audit, ispezione e richiesta di evidenze di sicurezza

Se un fornitore SaaS, un partner di sviluppo esternalizzato o un fornitore di software commerciale non fornisce evidenze di sicurezza, stato delle vulnerabilità, impegni di notifica o accesso all’audit, l’assurance della catena di fornitura software presenta un punto cieco.

La Politica di gestione del rischio di dipendenza dai fornitori trasforma la concentrazione delle dipendenze in un rischio di resilienza misurabile:

Registro delle dipendenze dai fornitori: il VMO deve mantenere un registro aggiornato di tutti i fornitori critici, includendo dettagli quali servizi/prodotti forniti; se il fornitore è a fornitura esclusiva; fornitori alternativi disponibili o sostituibilità; condizioni contrattuali correnti; e una valutazione dell’impatto in caso di fallimento o compromissione del fornitore. Il registro deve identificare chiaramente i fornitori ad alta dipendenza (ad es. quelli per i quali non esiste un’alternativa rapida).

Quel registro dovrebbe essere collegato agli SBOM. Se una libreria critica proviene da un fornitore a fornitura esclusiva, supporta un flusso di lavoro cliente regolamentato e non dispone di un sostituto rapido, non è solo un pacchetto. È una dipendenza di resilienza.

Dal file SBOM al controllo operativo in uno sprint

Un programma SBOM pratico dovrebbe partire da una linea di prodotto e da un ambiente di produzione. Non cercare di inventariare l’intera impresa il primo giorno. Se la FinTech di Amelia inizia con il flusso di onboarding clienti e pagamento, il team può creare un modello di evidenze ripetibile prima di scalarlo.

Passaggio 1: definire l’ambito SBOM all’interno del SGSI

Crea una dichiarazione dell’ambito di applicazione collegata al campo di applicazione del SGSI e ai driver normativi:

• Prodotto: piattaforma SaaS per onboarding clienti e pagamenti
• Ambiente: produzione UE
• Repository: auth-service, billing-service, payment-api, reporting-api, frontend-app
• Sistemi di build: provider Git, piattaforma CI/CD, registry dei container
• Deployment: cluster Kubernetes, database gestito, object storage
• Dati: dati degli account, log di autenticazione, metadati di fatturazione, riferimenti di pagamento
• Clienti: entità finanziarie UE e clienti commerciali
• Driver normativi: ISO 27001:2022, assurance clienti NIS2, due diligence ICT di terze parti DORA, accountability di sicurezza GDPR

Ciò è allineato alla logica dell’ambito di applicazione della clausola 4 di ISO 27001 e alla definizione del profilo NIST CSF.

Passaggio 2: generare e archiviare gli SBOM in fase di build

Configura le pipeline CI/CD per generare un SBOM per ogni artefatto di build, incluse le immagini container. Formati standard come CycloneDX e SPDX sono comunemente utilizzati. Archivia ogni SBOM in un repository di evidenze controllato, collegato all’ID di build, all’hash del commit, alla registrazione di deployment e alla versione di rilascio.

Questo supporta direttamente il requisito della Politica di sviluppo sicuro - PMI di mantenere versione, fonte, vulnerabilità note o stato della patch e data di riesame.

Passaggio 3: arricchire i dati SBOM con sfruttabilità e contesto aziendale

Non fermarti a un elenco di pacchetti. Aggiungi il contesto di rischio operativo:

• Il componente è vulnerabile?
• La funzione vulnerabile è raggiungibile?
• Il servizio è esposto a Internet?
• Il servizio tratta dati personali?
• Supporta una funzione critica o importante per un cliente DORA?
• È disponibile una patch?
• Esiste un controllo compensativo?
• L’accettazione del rischio è stata approvata dal proprietario del rischio?

Una CVE critica in un pacchetto usato solo per test è diversa da una CVE critica in un servizio di autenticazione in produzione. Le clausole ISO 27001 sulla valutazione del rischio e sul trattamento del rischio aiutano a rendere difendibile questa distinzione.

Passaggio 4: collegare gli SBOM ai controlli sui fornitori e sullo sviluppo esternalizzato

Se un componente è fornito da un fornitore commerciale o da un partner di sviluppo esternalizzato, aggiorna la registrazione del fornitore:

Ciò supporta le aspettative di NIS2 Article 21 sulla sicurezza della catena di fornitura e di DORA Article 28 in materia di strategia per il rischio ICT di terze parti, due diligence, misure contrattuali di sicurezza, registri delle informazioni, pianificazione degli audit, diritti di risoluzione e strategie di uscita.

Passaggio 5: definire regole ed evidenze di remediation

Collega gli SLA di remediation all’impatto aziendale, non solo ai punteggi CVSS.

È qui che gli SBOM diventano utili per NIS2, DORA e GDPR. Un flusso di remediation deve considerare il potenziale di incidente significativo, l’impatto di un incidente ICT rilevante, i criteri di violazione dei dati personali, gli obblighi contrattuali di notifica e l’impatto sulla resilienza operativa.

Passaggio 6: aggiungere un gate di rilascio

Prima del deployment, richiedi alla pipeline o al processo di modifica di confermare che:

• SBOM generato correttamente
• Non rimangano vulnerabilità critiche non approvate
• I nuovi componenti di terze parti siano approvati
• La verifica della policy sulle licenze sia stata superata
• SCA, SAST, DAST o altri test richiesti siano completati
• Il ticket di modifica sia collegato
• Il piano di rollback sia documentato per i rilasci ad alto rischio

Questo collega A.8.25 sviluppo sicuro, A.8.29 test di sicurezza e A.8.32 gestione delle modifiche in un unico flusso verificabile in audit.

Passaggio 7: costruire il pacchetto di evidenze del rilascio

Per ogni rilascio, conserva:

• File SBOM
• ID di build e hash del commit
• Output della scansione SCA
• Registrazione del triage delle vulnerabilità
• Eccezioni approvate
• Approvazione della modifica
• Registrazione di deployment
• Risultati dei test
• Evidenze del fornitore, se applicabile
• Registrazione di incidente o problema se il rilascio ha rimediato una vulnerabilità

Quando un auditor chiede come vengono gestite in produzione le librerie di terze parti, il team di Amelia non deve cercare nelle conversazioni Slack. Apre il pacchetto di evidenze del rilascio.

Mappatura cross-compliance: un programma SBOM, molti obblighi

Il valore commerciale di un programma SBOM aumenta quando viene mappato una sola volta e riutilizzato in più quadri di riferimento. L’approccio cross-compliance di Clarysec evita duplicazioni traducendo la stessa evidenza nei diversi linguaggi dell’assurance.

La segnalazione degli incidenti NIS2 può procedere rapidamente quando lo sfruttamento causa, o è in grado di causare, una grave interruzione operativa, una perdita finanziaria o un danno materiale o immateriale considerevole. NIS2 utilizza una segnalazione per fasi, che include un preallarme entro 24 ore dalla consapevolezza, una notifica dell’incidente entro 72 ore e una relazione finale entro un mese dalla notifica dell’incidente. Gli SBOM aiutano a determinare se il componente interessato è presente, se i servizi dei clienti sono interessati e se è plausibile un impatto transfrontaliero.

DORA utilizza un ciclo di vita strutturato degli incidenti ICT, che include rilevazione, registrazione, classificazione, analisi della causa radice, escalation, piani di comunicazione, escalation verso l’organo di gestione e segnalazione normativa per gli incidenti ICT rilevanti. Le evidenze SBOM supportano la classificazione perché collegano un componente vulnerabile ai clienti interessati, al downtime, alla diffusione geografica, alle perdite di dati, alla criticità del servizio e all’impatto economico.

NIST CSF 2.0 aggiunge un linguaggio utile per l’assurance dei clienti. Zenith Controls mappa A.5.21 a risultati di governance della catena di fornitura come GV.SC-05, in cui i requisiti di cibersicurezza per i fornitori sono stabiliti, comunicati e integrati nei contratti e in altri accordi. Richiedere SBOM, divulgazione delle vulnerabilità, evidenze di audit e tempistiche di remediation diventa un controllo contrattuale, non una richiesta ad hoc.

Come Zenith Blueprint sequenzia il lavoro

Zenith Blueprint trasforma il linguaggio dei controlli in una roadmap di attuazione.

Nella fase Risk Management, il passaggio 14 collega sviluppo sicuro, controlli CI/CD, scansione delle dipendenze, gestione delle modifiche, gestione degli incidenti e formazione degli sviluppatori. Nella fase Controls in Action, il passaggio 20 è esplicito sui componenti di terze parti e open source:

Questo controllo si applica anche ai componenti di terze parti e open source. Affidarsi a librerie esterne è prassi standard, ma ogni inclusione è una decisione di fiducia. Gli sviluppatori dovrebbero valutare le dipendenze in base a reputazione, frequenza di manutenzione, vulnerabilità note e restrizioni di licenza. Strumenti come gli SBOM (Software Bill of Materials) sono sempre più essenziali per tracciare ciò che è incorporato nel proprio stack.

Il passaggio 21 inquadra il test di sicurezza come guidato dal contesto e raccomanda test stratificati per sistemi critici per l’operatività aziendale o esposti a Internet, inclusi Software Composition Analysis (SCA) per le librerie di terze parti, analisi statica e dinamica, test di penetrazione, convalida della modellazione delle minacce, test dei casi di uso improprio, fuzzing e test esplorativi manuali.

Il passaggio 23 affronta gli accordi con i fornitori, inclusi obblighi di riservatezza, responsabilità di controllo degli accessi, misure tecniche e organizzative, tempistiche di segnalazione degli incidenti, diritto di audit, controlli sui subappaltatori e disposizioni di fine contratto.

La lezione pratica è semplice. Gli SBOM appartengono a gestione del rischio, sviluppo sicuro, test, governance dei fornitori, risposta agli incidenti e reportistica direzionale.

La lente dell’audit: cosa testeranno i diversi revisori

Un programma SBOM maturo deve reggere diversi stili di audit.

Un auditor ISO 27001:2022 partirà dal SGSI. Chiederà se il rischio della catena di fornitura software è nel campo di applicazione, se i requisiti delle parti interessate includono NIS2, clienti DORA, GDPR e contratti, se il rischio dei componenti fa parte della metodologia di rischio, se la Dichiarazione di Applicabilità include i controlli pertinenti dell’Allegato A e se le politiche sono attuate nel tempo. Potrebbe campionare un rilascio e tracciarlo dalla politica alla pipeline, all’SBOM, alla scansione delle vulnerabilità, all’approvazione della modifica, al deployment e al monitoraggio post-rilascio.

Un revisore DORA o un cliente finanziario si concentrerà sulla resilienza operativa e sul rischio ICT di terze parti. Potrebbe chiedere quali componenti supportano il servizio utilizzato dall’entità finanziaria, se il servizio supporta una funzione critica o importante, come sono documentati asset e dipendenze ICT, se le vulnerabilità sono monitorate, se i test annuali coprono i sistemi critici e se i contratti includono assistenza, diritto di audit, notifica degli incidenti, localizzazione dei dati, subappalto e condizioni di risoluzione.

Un valutatore NIST CSF cercherà i risultati. In GOVERN, testerà governance legale, normativa, contrattuale, privacy e della catena di fornitura. In IDENTIFY, si aspetterà visibilità su asset, software e servizi. In PROTECT, testerà sviluppo sicuro e controlli di pipeline. In DETECT e RESPOND, esaminerà allarmi sulle vulnerabilità, analisi, escalation e comunicazioni. In RECOVER, chiederà in che modo la compromissione di un componente incide sul ripristino e sulle comunicazioni ai clienti.

Un auditor in stile COBIT o ISACA si concentrerà su governance, accountability, titolarità del rischio, progettazione dei controlli e affidabilità delle evidenze. Potrebbe testare se gli SBOM sono completi, se i ticket di vulnerabilità vengono chiusi entro i termini di policy, se le eccezioni scadono, se le evidenze dei fornitori sono aggiornate e se la direzione riceve report significativi.

Errori comuni dei programmi SBOM da evitare

I programmi SBOM di solito falliscono per motivi prevedibili.

Il primo errore è generare SBOM senza archiviarli come evidenze controllate. Se il file viene sovrascritto a ogni build e non può essere collegato a un rilascio, è un’evidenza di audit debole.

Il secondo errore è separare gli SBOM dalla gestione delle vulnerabilità. Un elenco di componenti senza triage, titolarità, remediation o accettazione del rischio non dimostra il funzionamento del controllo.

Il terzo errore è escludere le dipendenze transitive. Le vulnerabilità spesso si nascondono sotto il livello delle dipendenze dirette.

Il quarto errore è lasciare lo sviluppo esternalizzato fuori dal processo. Se un fornitore consegna codice senza disclosure dei componenti, evidenze di scansione o registrazioni di approvazione, la catena di fornitura software presenta un punto cieco non gestito.

Il quinto errore è firmare contratti con i fornitori senza diritti sulle evidenze. La funzione Acquisti firma l’accordo, l’engineering consuma il servizio e la sicurezza scopre in seguito che non esiste diritto di audit, né obbligo di divulgazione delle vulnerabilità, né restrizione ai subappaltatori, né supporto all’uscita.

Il sesto errore è non mappare i componenti ai servizi aziendali. Un pacchetto vulnerabile significa poco finché non sai se incide su autenticazione, pagamenti, reporting, dati dei pazienti, amministrazione cloud, onboarding clienti o un flusso finanziario regolamentato.

Il settimo errore è nascondere alla leadership vulnerabilità critiche irrisolte. NIS2 e DORA rendono entrambe esplicita l’accountability della direzione. Il rischio critico dei componenti deve essere visibile nei forum di governance, non sepolto nei backlog di engineering.

Come si presenta un buon programma nel 2026

Un programma SBOM pronto per l’audit presenta caratteristiche visibili.

Esiste una politica approvata che richiede che i componenti di terze parti e open source siano approvati, tracciati, sottoposti a scansione e riesaminati. La pipeline CI/CD genera automaticamente gli SBOM. Le scansioni SCA vengono eseguite prima del deployment e durante l’esecuzione, ove applicabile. Le vulnerabilità critiche attivano un’escalation definita. Le eccezioni hanno proprietari, date di scadenza, controlli compensativi e accettazione del rischio.

I contratti con i fornitori includono obblighi di sicurezza, tempistiche di notifica della violazione, diritto di audit, controlli sul subappalto e disposizioni di risoluzione. I fornitori critici sono riesaminati almeno annualmente. I rischi di dipendenza dai fornitori e di concentrazione sono visibili. I team di sviluppo esternalizzato seguono le stesse regole di sviluppo sicuro e approvazione dei componenti dei team interni.

La reportistica direzionale collega il rischio tecnico all’impatto aziendale:

• Componenti critici vulnerabili per prodotto
• Esposizione per cliente o servizio regolamentato
• Remediation aperte oltre lo SLA
• Componenti senza fonte approvata
• Librerie non supportate o a fine vita
• Lacune nelle evidenze dei fornitori
• Eccezioni in attesa di rinnovo o chiusura
• Incidenti collegati a vulnerabilità dei componenti

È in questo momento che gli SBOM smettono di essere un artefatto di conformità e diventano uno strumento di gestione.

Trasformare gli SBOM in evidenze di conformità difendibili

La prossima volta che un’allerta su un componente critico arriva alle 07:42, la risposta non dovrebbe essere: “Ci servono due ore per capire dove si trova.”

Dovrebbe essere: “Questo è il componente interessato, questi sono i servizi, questi sono i clienti, questa è la classificazione del rischio, questo è il piano di remediation e queste sono le evidenze.”

Clarysec può aiutarti a progettare quel sistema di controllo. Aiutiamo le organizzazioni a definire l’ambito SBOM all’interno del SGSI, mappare i controlli dell’Allegato A di ISO 27001:2022 alle aspettative di audit in stile NIS2, DORA, GDPR, NIST CSF 2.0 e COBIT, applicare politiche di sviluppo sicuro e sui fornitori, costruire pacchetti di evidenze di rilascio e preparare assurance pronta per l’audit utilizzando Zenith Controls e Zenith Blueprint.

Vuoi trasformare la tua catena di fornitura software da fonte di incertezza a dimostrazione di resilienza?

Scarica le politiche Clarysec pertinenti, usa Zenith Blueprint per sequenziare l’attuazione e Zenith Controls per mappare le evidenze su ISO 27001:2022, NIS2, DORA e requisiti di assurance dei clienti. Contatta Clarysec per iniziare con una valutazione mirata della preparazione SBOM e costruire un programma pratico di assurance della catena di fornitura software pronto per l’audit.