Il Cyber Supply Chain Risk Management (SCRM) è la disciplina che si occupa di identificare, valutare e mitigare i rischi di sicurezza che si propagano attraverso la catena di fornitura del software.

Il suo oggetto è specifico e distinto dal Vendor Risk Management tradizionale: non si occupa dell’organizzazione del vendor nella sua globalità, ma del software che quel vendor produce, distribuisce o aggiorna e delle vulnerabilità, intenzionali o accidentali, che quel software può introdurre nei sistemi dell’organizzazione che lo adotta.

Cyber Supply Chain Risk Management: definizione e perimetro

La distinzione è importante sul piano operativo. Un vendor può avere una certificazione ISO 27001 impeccabile, un programma VRM ben strutturato e contratti SLA rigorosi, eppure distribuire software contenente vulnerabilità critiche o, nei casi più gravi, componenti malevoli inseriti deliberatamente nella catena di build.

L’SCRM risponde a questa categoria di rischio con strumenti e metodologie specifici: l’analisi della composizione del software, il controllo dell’integrità della pipeline di sviluppo e distribuzione, la verifica delle dipendenze open source, il monitoraggio continuo delle vulnerabilità nei componenti installati.

Il perimetro dell’SCRM abbraccia tre categorie di software, ciascuna con un profilo di rischio distinto.

• Il software commerciale off-the-shelf (COTS) (sistemi operativi, suite di produttività, piattaforme ERP, soluzioni di sicurezza) è distribuito da vendor strutturati con processi di sviluppo formali, ma la sua complessità e la vastità della base di installazione lo rendono un bersaglio privilegiato per gli attaccanti.
• Il software open source (presente in quasi ogni applicazione moderna come dipendenza diretta o transitiva) offre la trasparenza del codice sorgente ma espone al rischio di dipendenze non presidiate e di manutenzione discontinua.
• Il software sviluppato internamente con componenti terze parti (la categoria più diffusa nelle organizzazioni di media e grande dimensione) accumula i rischi di entrambe le categorie precedenti, con la variabile aggiuntiva della responsabilità diretta dello sviluppatore sull’integrazione.

Dunque, per costruire correttamente un perimetro SCRM occorre completare le seguenti azioni:

1. Censire tutte le categorie di software in uso: COTS, open source, sviluppo interno con dipendenze terze. Trattare ogni categoria con metodologie di risk assessment specifiche.
2. Estendere il perimetro SCRM ai software di sicurezza stessi (EDR, SIEM, scanner): sono tra i componenti con accesso più privilegiato ai sistemi e quindi tra i più appetibili come vettori di attacco supply chain.
3. Includere nell’SCRM i plugin, le estensioni e le integrazioni di terze parti nelle piattaforme SaaS: spesso ignorati nei programmi di sicurezza, rappresentano un vettore di rischio significativo.

Il software come vettore di attacco: i casi che hanno ridefinito lo SCRM

La storia degli attacchi alla supply chain software è, negli ultimi anni, una sequenza di eventi che hanno progressivamente alzato il livello di allerta globale e ridefinito ciò che le organizzazioni devono aspettarsi dai propri vendor.

Analizzarli non è un esercizio retorico: è il modo più efficace per comprendere concretamente quali vettori lo SCRM deve presidiare.

SolarWinds (2020) rimane il caso di riferimento per gli attacchi alla build pipeline. Gli attaccanti (attribuiti a un gruppo di intelligence russo) compromisero il sistema di build di SolarWinds e inserirono codice malevolo (SUNBURST) nell’aggiornamento legittimo della piattaforma Orion, distribuito a circa 18.000 organizzazioni tra cui agenzie governative statunitensi, aziende Fortune 500 e istituzioni europee.

La lezione fondamentale: un aggiornamento software firmato digitalmente e distribuito attraverso canali ufficiali può contenere malware se la pipeline di build è compromessa. La firma del codice è necessaria ma non sufficiente.

Log4Shell (2021) ha rivelato la vulnerabilità sistemica delle dipendenze open source. La vulnerabilità critica nella libreria Log4j (presente come dipendenza in decine di migliaia di applicazioni Java, spesso senza che gli sviluppatori ne fossero consapevoli) ha esposto simultaneamente una frazione enorme dell’infrastruttura IT globale.

Il problema non era il codice delle singole organizzazioni: era una dipendenza transitiva che nessuno monitorava. XZ Utils (2024) ha mostrato uno scenario ancora più sofisticato: un attore malevolo ha trascorso due anni a guadagnarsi la fiducia della comunità open source di un progetto critico per inserire una backdoor in una libreria di compressione ampiamente utilizzata nei sistemi Linux.

MOVEit (2023) ha dimostrato come una singola vulnerabilità in un software di trasferimento file diffusissimo possa diventare il punto di ingresso per una campagna ransomware su scala globale, colpendo centinaia di organizzazioni attraverso un unico vettore condiviso.

Il filo comune di questi incidenti è la fiducia implicita: le organizzazioni si fidavano del software perché proveniva da vendor conosciuti, era firmato digitalmente, o era ampiamente adottato dalla comunità. Lo SCRM nasce esattamente dalla necessità di sostituire questa fiducia implicita con una verifica esplicita e continua.

Le lezioni che impariamo dagli incidenti SCRM sono, dunque, i seguenti:

1. Non fidarsi della sola firma digitale degli aggiornamenti: verificare anche l’integrità della build pipeline del vendor (attestazioni SLSA, Sigstore).
2. Mappare le dipendenze transitive, non solo quelle dirette: Log4Shell ha colpito principalmente organizzazioni che non sapevano di usare Log4j.
3. Monitorare le vulnerabilità nei componenti open source con strumenti SCA (Software Composition Analysis) integrati nella pipeline CI/CD.
4. Valutare il rischio di concentrazione: quante applicazioni critiche dipendono dallo stesso componente o dallo stesso vendor? Un singolo punto di fallimento nella supply chain software è un rischio sistemico.

Il modello SCRM per il software vendor: le quattro fasi

Per costruire correttamente un modello SCRM valido ed efficace occorre, quindi, portare a termine le seguenti quattro fasi operative.

Vendor identification e Software Bill of Materials (SBOM)

Il primo passo di qualsiasi programma SCRM è sapere cosa è installato. Una risposta che sembra ovvia, ma che nella pratica è sorprendentemente rara: la maggior parte delle organizzazioni non dispone di un inventario completo e aggiornato del software in uso, men che meno delle sue dipendenze.

Il Software Bill of Materials (SBOM) è lo strumento che colma questo gap: un documento strutturato che elenca tutti i componenti software di un’applicazione, incluse le dipendenze di terze parti, le librerie open source e le loro versioni, con le relative informazioni di licenza e provenienza.

L’SBOM non è una novità concettuale, ma è diventato un requisito normativo esplicito dopo l’Executive Order 14028 del presidente Biden (maggio 2021), che ha reso obbligatorio per i vendor software che forniscono alla pubblica amministrazione statunitense la produzione e la condivisione di SBOM in formato standardizzato.

Questa spinta regolatoria ha avuto un effetto di trascinamento globale: oggi ENISA raccomanda esplicitamente l’adozione degli SBOM come strumento di trasparenza nella supply chain software, e le linee guida NIS2 ne incoraggiano l’utilizzo nei settori critici.

In Europa, il Cyber Resilience Act (il regolamento sulla sicurezza dei prodotti con elementi digitali approvato nel 2024) introduce requisiti di trasparenza sulla composizione del software che si avvicinano concettualmente all’SBOM, anticipando una futura obbligatorietà anche nel contesto normativo europeo.

Threat modeling e risk assessment del codice

Con l’inventario dei componenti software disponibile, il passo successivo è la valutazione del rischio associato a ciascuno di essi.

Il threat modeling applicato alla supply chain software non è diverso nella logica dal threat modeling applicato alle architetture di sistema: si tratta di identificare i punti di ingresso potenziali per un attaccante, valutare la probabilità e l’impatto di una compromissione, e prioritizzare i controlli di mitigazione in funzione del rischio effettivo.

Per il software COTS e open source, il risk assessment si concentra su tre dimensioni:

1. la criticità del componente nell’architettura dell’applicazione (un componente con accesso a dati sensibili o con privilegi elevati ha un profilo di rischio più alto di uno periferico);
2. la qualità del processo di sviluppo e manutenzione del vendor o della comunità open source (frequenza dei rilasci, responsività alle segnalazioni di vulnerabilità, presenza di un programma di vulnerability disclosure);
3. la storia delle vulnerabilità note (componenti con CVE critici ricorrenti hanno un profilo di rischio strutturalmente più elevato).

Per le dipendenze open source, un indicatore utile aggiuntivo è il livello di mantenimento attivo del progetto: una libreria con l’ultimo commit di tre anni fa e senza maintainer attivi è un rischio latente indipendentemente dalla sua storia di vulnerabilità.

Controlli tecnici: SAST, DAST, SCA e code signing

I controlli tecnici per la sicurezza della supply chain software si articolano lungo l’intera pipeline di sviluppo e distribuzione.

L’analisi statica del codice sorgente (SAST, Static Application Security Testing) identifica le vulnerabilità nel codice prima della compilazione, analizzando il sorgente alla ricerca di pattern noti di insicurezza: SQL injection, buffer overflow, gestione non sicura della memoria, uso di funzioni deprecate.

L’analisi della composizione del software (SCA, Software Composition Analysis) è il controllo specificamente dedicato alle dipendenze open source: identifica i componenti di terze parti presenti nel codice, verifica la presenza di vulnerabilità note (CVE) nelle versioni utilizzate e segnala le licenze non compatibili con i requisiti dell’organizzazione.

L’analisi dinamica (DAST, Dynamic Application Security Testing) completa il quadro testando l’applicazione in esecuzione, simulando attacchi reali per identificare vulnerabilità che non emergono dall’analisi del codice statico.

Il code signing (la firma crittografica del codice eseguibile e dei pacchetti di aggiornamento) è il controllo che garantisce l’integrità del software dal momento della compilazione al momento dell’esecuzione. La firma del codice non previene la compromissione della build pipeline (come SolarWinds ha dimostrato), ma garantisce che il software non sia stato alterato dopo la firma. Per i vendor critici, è importante verificare non solo che il codice sia firmato, ma anche che il processo di firma sia protetto: certificati conservati in HSM, accesso alla chiave di firma limitato e auditato, procedure di revoca in caso di compromissione.

La seguente è una checklist non esaustiva con i controlli tecnici SCRM per effettuare una verifica dei vendor:

• Verificare che il vendor abbia integrato strumenti SAST nella pipeline CI/CD con policy di blocco del rilascio in presenza di vulnerabilità critiche.
• Verificare l’utilizzo di strumenti SCA per il monitoraggio delle dipendenze open source, con aggiornamento automatico dell’inventario delle CVE.
• Verificare la presenza di test DAST periodici sull’applicazione in produzione, con report disponibile su richiesta.
• Verificare che tutto il codice distribuito sia firmato digitalmente con certificati validi e che il processo di firma sia protetto da accessi non autorizzati.
• Verificare l’esistenza di un processo di code review obbligatorio per le modifiche al codice critico, con almeno due approvatori indipendenti.
• Verificare la protezione della pipeline CI/CD: accessi limitati, log di audit, separazione degli ambienti di build da quelli di produzione.
• Verificare la gestione dei segreti nella pipeline: nessuna credenziale hardcoded nel codice, utilizzo di vault dedicati (HashiCorp Vault, AWS Secrets Manager).

Monitoraggio continuo e vulnerability disclosure

La valutazione puntuale del software al momento dell’acquisto o dell’onboarding non è sufficiente: nuove vulnerabilità vengono scoperte continuamente nei componenti installati, e la finestra temporale tra la pubblicazione di un CVE e il suo sfruttamento attivo si è ridotta drasticamente negli ultimi anni.

Il monitoraggio continuo delle vulnerabilità nei componenti software in uso è oggi un requisito operativo fondamentale, non un’opzione per le organizzazioni più avanzate.

Strumenti come Dependency-Track (progetto OWASP), Grype, Trivy e le funzionalità native delle principali piattaforme cloud (AWS Inspector, Microsoft Defender for Cloud, GCP Security Command Center) consentono di monitorare in tempo reale le vulnerabilità nei componenti software installati, correlando l’SBOM dell’applicazione con i database CVE aggiornati e generando alert prioritizzati per le vulnerabilità più critiche.

La prioritizzazione è fondamentale: non tutte le CVE hanno lo stesso impatto nel contesto specifico dell’organizzazione; una vulnerabilità in un componente non raggiungibile dall’esterno ha un profilo di rischio molto diverso dalla stessa vulnerabilità in un servizio esposto su internet.

La vulnerability disclosure policy del vendor è un indicatore della maturità del suo programma di sicurezza.

Un vendor che pubblica tempestivamente le informazioni sulle vulnerabilità scoperte nei propri prodotti, che mantiene un canale dedicato per la ricezione di segnalazioni da ricercatori esterni (responsible disclosure) e che risponde con patch in tempi documentati è un vendor che gestisce il rischio software in modo professionale.

La verifica di questi elementi deve far parte della due diligence SCRM in fase di selezione del vendor.

SCRM e VRM: la convergenza necessaria

Il monitoraggio del codice sorgente di terze parti riduce drasticamente l’introduzione di minacce silenti nel network aziendale.

Tali verifiche si integrano perfettamente all’interno dei processi dedicati alla gestione dei rischi della catena fornitura per garantire la resilienza: lo SCRM non è un programma parallelo al VRM, ma la sua estensione tecnica nel dominio del software, la risposta operativa alla stessa domanda che il VRM pone sul piano organizzativo.

La convergenza tra SCRM e VRM è tanto più necessaria quanto più il software è al centro della relazione con il vendor.

Per un MSP che gestisce l’infrastruttura IT di un’organizzazione, il VRM tradizionale copre i processi organizzativi, le certificazioni e le clausole contrattuali; lo SCRM copre gli strumenti software che quel MSP utilizza per erogare il servizio (gli agenti di monitoraggio, gli strumenti di accesso remoto, le piattaforme di ticketing).

Entrambe le dimensioni devono essere presidiate: ignorare una delle due lascia aperte superfici di attacco che l’altra non può coprire.

In pratica, questa convergenza si realizza attraverso l’integrazione degli output dello SCRM – inventario dei componenti software, stato delle vulnerabilità, risultati dei controlli tecnici – nel registro del rischio fornitore del programma VRM.

Un vendor il cui software presenta vulnerabilità critiche non risolte deve vedere il proprio vendor score aggiornato di conseguenza, con le stesse implicazioni contrattuali e operative che deriverebbero da un gap organizzativo di pari gravità.

Framework e standard di riferimento

Il NIST SP 800-161 Revision 1 (2022) – “Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations” – è il documento di riferimento più completo per la strutturazione di un programma SCRM.

Organizzato in coerenza con il NIST CSF, definisce pratiche specifiche per la gestione del rischio supply chain a tre livelli: organizzativo (governance, policy, ruoli), di missione e business (integrazione del rischio supply chain nei processi decisionali) e operativo (controlli tecnici su sistemi e componenti specifici).

Per le organizzazioni nei settori critici, il NIST SP 800-161r1 è la baseline metodologica più solida disponibile, più dettagliata del NIST CSF 2.0 sullo specifico dominio della supply chain.

L’Executive Order 14028 (maggio 2021) ha avuto un impatto che va ben oltre il perimetro della pubblica amministrazione statunitense per cui è stato emesso.

I requisiti che introduce (SBOM obbligatori, standard minimi per la sicurezza dello sviluppo software, adozione di pratiche Zero Trust, logging obbligatorio) hanno definito un nuovo standard di fatto che i vendor software globali hanno dovuto adottare per mantenere l’accesso al mercato federale americano, con effetti di trascinamento sull’intero settore. Molte delle pratiche SCRM oggi considerate best practice internazionali sono state sistematizzate o accelerate dall’EO 14028.

In Europa, il recepimento di questi principi è avvenuto attraverso percorsi normativi distinti ma convergenti.

Il Cyber Resilience Act (CRA, Regolamento UE 2024/2847) introduce per la prima volta obblighi specifici per i produttori di software commercializzato nell’Unione Europea: gestione delle vulnerabilità per l’intero ciclo di vita del prodotto, notifica obbligatoria delle vulnerabilità attivamente sfruttate ad ENISA e, implicitamente, requisiti di trasparenza sulla composizione del software che si avvicinano all’obbligo di SBOM.

NIS2 e DORA completano il quadro sul lato delle organizzazioni che utilizzano il software: l’obbligo di gestire il rischio supply chain si traduce, operativamente, nell’adozione di pratiche SCRM per i vendor software critici.

SCRM nei settori critici NIS2: requisiti operativi

Per i soggetti essenziali e importanti identificati dalla direttiva NIS2, il rischio software nella supply chain non è una preoccupazione teorica: è una delle superfici di attacco più concrete e documentate.

Gli operatori di energia, le infrastrutture di trasporto, le organizzazioni sanitarie, i fornitori di infrastrutture digitali dipendono in misura crescente da software di vendor terzi per funzioni critiche: sistemi SCADA, piattaforme di gestione clinica, sistemi di controllo industriale, infrastrutture di rete.

La compromissione di uno qualsiasi di questi componenti software può avere conseguenze che vanno ben oltre il perimetro IT: interruzione di servizi essenziali, rischi per la sicurezza fisica, impatti su infrastrutture nazionali.

Le linee guida ENISA per la sicurezza della supply chain ICT identificano il software come uno dei vettori di rischio prioritari per i settori critici e raccomandano un approccio SCRM strutturato che includa:

• la valutazione della sicurezza del processo di sviluppo software del vendor (non solo del prodotto finito);
• la verifica della gestione delle dipendenze open source;
• l’analisi dei meccanismi di aggiornamento e patching;
• la valutazione della postura di sicurezza della pipeline di build.

Per i sistemi di controllo industriale (OT/ICS), le sfide sono amplificate dalla difficoltà di applicare patch in ambienti in cui i sistemi non possono essere interrotti e dai lunghi cicli di vita dei componenti software industriali.

Un aspetto specifico per i settori critici riguarda il software di sicurezza stesso: gli strumenti EDR, i sistemi di monitoraggio di rete, le soluzioni SIEM che proteggono l’infrastruttura critica sono essi stessi componenti della supply chain software con un profilo di rischio elevato in quanto hanno accesso privilegiato a tutti i sistemi, operano con diritti di kernel o di amministratore, e ricevono aggiornamenti frequenti e automatici.

L’incidente CrowdStrike del luglio 2024, in cui un aggiornamento difettoso del sensore Falcon ha causato il blocco di milioni di sistemi Windows globalmente, ha reso evidente che il rischio SCRM si applica anche, e forse soprattutto, agli strumenti di sicurezza stessi.

Costruire un programma SCRM: dalla strategia all’operatività

Un programma SCRM maturo non si costruisce in un giorno, né con un singolo strumento. È il risultato di un percorso progressivo che parte dalla consapevolezza del rischio (sapere cosa è installato e da dove proviene) per arrivare alla capacità di risposta (rilevare una vulnerabilità nella supply chain software e rimediarla prima che venga sfruttata).

Le organizzazioni che iniziano questo percorso devono fare scelte pragmatiche: dove concentrare le risorse limitate disponibili per ottenere il massimo riduzione del rischio nel breve termine.

Il punto di partenza raccomandato è sempre l’inventario: costruire o aggiornare il catalogo del software in uso, prioritizzare i componenti per criticità (accesso ai dati, privilegi di esecuzione, esposizione su internet) e avviare il monitoraggio delle CVE sui componenti prioritari.

Questo primo passo, anche in assenza di strumenti sofisticati, riduce immediatamente la superficie di rischio non presidiata. Il secondo passo è l’integrazione dell’SBOM nel processo di procurement: richiedere l’SBOM ai vendor critici come requisito di onboarding costa poco e fornisce informazioni preziose per il risk assessment.

Il programma SCRM maturo aggiunge progressivamente i controlli tecnici più avanzati e integra i risultati nel programma VRM complessivo.

La maturità non si misura dalla complessità degli strumenti adottati, ma dalla capacità di risposta: un’organizzazione che rileva una CVE critica in un componente installato e la risolve in 24 ore ha un programma SCRM più efficace di una che ha strumenti sofisticati ma processi di remediation lenti e mal governati.