Software Supply Chain Security: rischi, SBOM e strategie di difesa
La software supply chain non coincide con il codice scritto internamente. Comprende repository, librerie open source, package manager, immagini container, tool di build, pipeline CI/CD, secret, runner, registry, servizi SaaS e tutti i componenti che contribuiscono a produrre e distribuire un artifact software. Un attaccante non deve necessariamente violare l’applicazione finale: può compromettere un passaggio a monte e sfruttare la fiducia nel processo di sviluppo e rilascio.
La Software Supply Chain Security ha quindi un obiettivo preciso: rendere verificabili origine, integrità, dipendenze e processo di produzione del software, riducendo la possibilità che codice o componenti manipolati arrivino in produzione senza essere rilevati.
Per una trattazione più ampia del rischio legato a fornitori, terze parti e servizi ICT consulta Supply Chain Security: come ridurre i rischi nella catena di fornitura digitale. Questa guida resta invece focalizzata sulla filiera del software e sui controlli tecnici che la rendono affidabile.
Valutazione tecnica
Devi capire quanto sono esposti repository, dipendenze, pipeline e processi di rilascio? Parti da una valutazione del rischio e definisci una roadmap di remediation.
Che cos’è la Software Supply Chain Security
È l’insieme di processi, controlli e tecnologie usati per proteggere il software lungo il suo ciclo di produzione e distribuzione. Il perimetro parte dal codice sorgente ma si estende a tutti gli elementi che possono influenzare il risultato finale:
- repository Git e sistemi di versionamento;
- dipendenze dirette e transitive;
- package registry pubblici e privati;
- pipeline CI/CD, runner e build environment;
- secret, token, chiavi di firma e credenziali di automazione;
- immagini container e base image;
- artifact repository e registry;
- meccanismi di firma, attestazione e provenance;
- processi di release, deployment e aggiornamento.
Il punto chiave è la fiducia. Ogni volta che una pipeline scarica una dipendenza, esegue un’action, usa un token o pubblica un artifact, sta assumendo che quella sorgente e quel passaggio siano affidabili. La sicurezza della supply chain serve a sostituire questa fiducia implicita con controlli verificabili.
Dove si genera il rischio nella software supply chain
- Repository e identità degli sviluppatori
Compromissione degli account, token personali troppo permissivi, branch protection assente, review aggirabili e secret committati possono consentire modifiche al codice o ai workflow senza un controllo adeguato. - Dipendenze open source e package manager
Componenti vulnerabili, pacchetti malevoli, typosquatting, dependency confusion e compromissione di maintainer possono introdurre codice non affidabile attraverso canali perfettamente legittimi. - Pipeline CI/CD e runner
Una pipeline è un sistema privilegiato: accede al sorgente, ai secret, ai registry e agli ambienti di destinazione. Workflow modificabili, action non pin-nate, runner persistenti o privilegi eccessivi trasformano l’automazione in un percorso di attacco. - Build environment
Se il processo di compilazione non è isolato e riproducibile, l’artifact può differire dal sorgente revisionato. La compromissione del builder è particolarmente critica perché può inserire modifiche dopo la code review. - Artifact, container e registry
Immagini non firmate, tag mutabili, repository senza policy e artifact non verificati rendono possibile distribuire componenti diversi da quelli approvati. - Secret e identità macchina
Token CI/CD, chiavi di firma, credenziali cloud e service account sono spesso più pericolosi delle password utente perché operano senza interazione umana e possono avere privilegi estesi. - Software di terze parti acquistato
Anche chi non sviluppa software è un consumatore della supply chain: deve poter valutare provenienza, vulnerabilità, aggiornamenti, supporto e capacità del vendor di gestire incidenti e disclosure.
Software supply chain attack: come funziona
Un supply chain attack sfrutta un elemento fidato del processo per distribuire una modifica non autorizzata. Il vantaggio per l’attaccante è l’effetto moltiplicatore: compromettere una dipendenza, un tool o una pipeline può consentire di raggiungere molti sistemi downstream senza attaccarli individualmente.
- compromissione dell’account di un maintainer e pubblicazione di una versione malevola;
- package typosquatting o dependency confusion per far installare un pacchetto controllato dall’attaccante;
- modifica di un workflow CI/CD per esfiltrare token o alterare la build;
- compromissione del build environment e produzione di artifact diversi dal codice revisionato;
- furto di chiavi o token di firma e pubblicazione di release apparentemente legittime;
- manomissione di immagini container o dipendenze tra fase di build e deployment.
SBOM: sapere cosa contiene davvero il software
Una Software Bill of Materials (SBOM) è un inventario strutturato dei componenti che compongono un software. Serve a rispondere rapidamente a domande operative: quale applicazione usa questa libreria? In quale versione? È una dipendenza diretta o transitiva? Quali prodotti devono essere verificati dopo la pubblicazione di una nuova CVE?
Nel luglio 2026 CISA ha pubblicato una nuova versione dei Minimum Elements for an SBOM, rafforzando i dati minimi attesi e introducendo elementi come hash del componente, licenza, tool usato per generare la SBOM e contesto di generazione. Una SBOM efficace deve quindi essere prodotta in modo automatico, aggiornata a ogni release e collegata ai processi di vulnerability management.
Attenzione: la SBOM non è un controllo di sicurezza autonomo. È una base di trasparenza. Se non viene correlata a vulnerabilità, exploitability, ownership e remediation, resta un inventario statico che non riduce il rischio.
SCA, SBOM e vulnerability management: ruoli diversi
Elemento | Cosa fa | Output utile |
SCA - Software Composition Analysis | Identifica componenti e dipendenze e li correla a vulnerabilità, licenze e policy. | Finding tecnici, dipendenze vulnerabili, policy violation. |
SBOM | Rappresenta l’inventario strutturato dei componenti contenuti nel software. | Trasparenza, tracciabilità, impatto di nuove CVE. |
Vulnerability management | Prioritizza, assegna ownership, gestisce eccezioni e verifica la remediation. | Rischio contestualizzato, SLA, ticket, evidenze di chiusura. |
Il modello maturo integra i tre livelli: inventario, rilevazione e processo di remediation.
Proteggere repository e dipendenze
- MFA forte e accessi amministrativi separati per repository e piattaforme DevOps.
- Branch protection, pull request obbligatorie e review indipendenti per codice e workflow sensibili.
- CODEOWNERS o controlli equivalenti sui percorsi critici.
- Dependency pinning e lock file; evitare riferimenti a versioni mobili quando l’integrità richiede immutabilità.
- Registry interni o proxy controllati per ridurre dipendenza diretta da sorgenti pubbliche.
- Scansione SCA continua e policy per componenti vulnerabili, obsoleti o non approvati.
- Secret scanning e divieto di credenziali statiche nel codice o nelle variabili non protette.
Mettere in sicurezza CI/CD e build
- Separare i privilegi di build da quelli di deployment.
- Usare identità workload e credenziali a vita breve al posto di secret permanenti quando la piattaforma lo consente.
- Isolare i runner e ricrearli tra build sensibili; evitare runner persistenti condivisi con workload non affidabili.
- Limitare network e filesystem access della pipeline al minimo necessario.
- Pin-nare action, plugin e container usati nel workflow a versioni o digest affidabili.
- Richiedere security gate automatici prima della promozione di un artifact.
- Produrre log e attestazioni del processo di build in modo che la release sia verificabile a posteriori.
Per un approfondimento formativo su pipeline, secret, SAST/DAST/SCA e security gate consulta il corso Cloud Security Applications.
Build provenance, firma e SLSA
La firma di un artifact dimostra chi lo ha firmato, ma non descrive necessariamente come è stato prodotto. La provenance aggiunge informazioni verificabili sul processo: sorgente, builder, parametri e materiali utilizzati. Il framework SLSA formalizza requisiti progressivi per aumentare l’integrità del processo di build e rendere più difficile la manipolazione degli artifact.
In pratica, l’obiettivo è poter dimostrare che l’artifact distribuito è stato prodotto da un builder atteso, a partire da sorgenti attese e attraverso un processo non alterato. La provenance diventa quindi un controllo complementare a firma, SBOM e vulnerability scanning.
NIST SSDF: integrare la sicurezza nello sviluppo
Il NIST Secure Software Development Framework (SSDF, SP 800-218) definisce un insieme di pratiche di sviluppo sicuro integrabili nei diversi modelli SDLC. Il valore del framework è organizzativo oltre che tecnico: crea un linguaggio comune tra sviluppo, security, procurement e fornitori e consente di trasformare i requisiti di sicurezza in attività verificabili lungo il ciclo di vita.
Per i team di sviluppo, la software supply chain security non sostituisce il secure coding. I due ambiti sono complementari: il secure coding riduce le vulnerabilità introdotte nel codice applicativo; i controlli supply chain proteggono dipendenze, automazioni, build e distribuzione. Per lavorare sul primo livello consulta il corso Secure Coding.
NIS2 e Cyber Resilience Act: cosa cambia per la filiera software
NIS2 include espressamente la sicurezza della supply chain e i rapporti con fornitori e service provider tra le misure di gestione del rischio. Per le organizzazioni soggette, questo rende necessario collegare procurement, requisiti contrattuali, vulnerability management e controlli sui servizi ICT critici.
Il Cyber Resilience Act (CRA) introduce requisiti di cybersecurity per i prodotti con elementi digitali lungo il ciclo di vita. Al 19 agosto 2026 il regolamento è già in vigore: gli obblighi di reporting dell’articolo 14 iniziano ad applicarsi dall’11 settembre 2026, mentre gli obblighi principali diventano applicabili dall’11 dicembre 2027. Per produttori software e fornitori di prodotti digitali questo rende ancora più importante disporre di inventario dei componenti, processi di vulnerability handling, evidenze di sviluppo sicuro e capacità di reagire rapidamente alle vulnerabilità sfruttate.
Nota normativa NIS2 e CRA hanno ambiti, soggetti e obblighi differenti. La pagina deve descrivere i collegamenti operativi con la software supply chain senza presentare l’articolo come consulenza legale o come checklist universale di conformità. |
Checklist operativa: 12 controlli per una software supply chain più sicura
- Inventaria repository, pipeline, registry, builder, package manager e servizi DevOps critici.
- Applica MFA forte, least privilege e separazione degli account amministrativi.
- Proteggi branch e workflow sensibili con review obbligatorie e ownership esplicita.
- Elimina secret statici e adotta credenziali brevi o workload identity dove possibile.
- Genera SBOM automaticamente per release e immagini container.
- Integra SCA e vulnerability scanning nella pipeline, con policy di blocco coerenti con il rischio.
- Controlla dipendenze dirette e transitive; usa lock file, pinning e registry affidabili.
- Isola runner e build environment e riduci i privilegi della pipeline.
- Firma artifact e immagini e verifica la firma prima del deployment.
- Genera e conserva build provenance/attestazioni per i workload critici.
- Definisci ownership, SLA ed eccezioni per la remediation delle vulnerabilità.
- Richiedi ai fornitori evidenze compatibili con il rischio: SBOM, disclosure policy, patch process, support lifecycle e gestione incidenti.
Come valutare la maturità della propria software supply chain
Una valutazione utile non parte dal numero di tool installati ma dalla catena di fiducia. Per ogni applicazione o servizio critico occorre sapere quali componenti entrano nel prodotto, chi può modificare sorgente e workflow, dove vengono custodite le credenziali, chi produce la build, come viene verificato l’artifact e come si reagisce quando emerge una vulnerabilità in una dipendenza.
Nexsys può collegare questa analisi a un Risk Assessment aziendale o a un percorso più ampio di consulenza cybersecurity, mantenendo separati assessment, remediation e attività formative.
Dalla guida alla remediation
Se la software supply chain sostiene applicazioni o processi critici, mappa i punti di fiducia, le dipendenze e i privilegi della pipeline e trasformali in controlli verificabili.
Formazione sulla Supply Chain Security
Per team IT, Security Manager, MSP, Cloud Provider e organizzazioni che sviluppano o distribuiscono software, Nexsys propone un percorso dedicato alla gestione dei rischi della filiera IT. Il corso tratta componenti della supply chain, rischi e vulnerabilità, casi reali, controlli organizzativi e tecnici e riferimenti di governance.
Scopri il corso Supply Chain Security per l’IT.
Domande frequenti sulla Software Supply Chain Security
Che cosa si intende per Software Supply Chain Security?
È la protezione dell’insieme di componenti e processi che concorrono a creare e distribuire software: repository, dipendenze, package registry, pipeline CI/CD, runner, builder, secret, artifact e sistemi di deployment.
Qual è la differenza tra Supply Chain Security e Software Supply Chain Security?
La Supply Chain Security ha un perimetro più ampio e comprende fornitori, partner, servizi ICT, hardware e dipendenze organizzative. La Software Supply Chain Security si concentra sulla filiera di produzione e distribuzione del software, inclusi codice, dipendenze, build e artifact.
Che cos’è una SBOM?
Una Software Bill of Materials è un inventario strutturato dei componenti contenuti in un software. Migliora la trasparenza e permette di identificare più rapidamente quali prodotti sono esposti quando emerge una vulnerabilità in una libreria o dipendenza.
Una SBOM rende sicuro il software?
No. La SBOM fornisce visibilità, ma deve essere integrata con SCA, vulnerability management, ownership, prioritizzazione e remediation. Senza questi processi resta un inventario.
Che differenza c’è tra SCA e SBOM?
La Software Composition Analysis analizza componenti e dipendenze e li correla a vulnerabilità, licenze e policy. La SBOM è invece la rappresentazione strutturata dell’inventario dei componenti. I due strumenti sono complementari.
Perché la pipeline CI/CD è un target critico?
Perché può accedere contemporaneamente a sorgente, secret, registry, builder e ambienti di destinazione. Se viene compromessa può alterare la build o distribuire artifact malevoli usando un canale considerato affidabile.
Che cosa significa build provenance?
È un’attestazione verificabile che descrive come e da quali sorgenti è stato prodotto un artifact. Serve a collegare la release al processo di build e a verificare che l’artifact provenga dal builder e dal flusso attesi.
NIS2 riguarda anche la supply chain?
Sì. NIS2 include la sicurezza della catena di approvvigionamento e gli aspetti di sicurezza nei rapporti con fornitori e service provider tra le misure di gestione del rischio previste per i soggetti interessati.
Il Cyber Resilience Act riguarda la software supply chain?
Il CRA introduce requisiti di cybersecurity per prodotti con elementi digitali lungo il ciclo di vita. Per i produttori software, inventario dei componenti, vulnerability handling, sicurezza dello sviluppo e capacità di reporting diventano quindi elementi operativi particolarmente rilevanti.
Da dove partire per migliorare la sicurezza della software supply chain?
Dalla mappatura della catena di fiducia: repository, dipendenze, pipeline, secret, builder, artifact e fornitori. Su questa base si definiscono priorità, controlli tecnici, ownership e roadmap di remediation.