Quattro regolamenti europei. Una software supply chain
Negli ultimi mesi la SBOM è uscita dall’ambito di nicchia degli ingegneri della sicurezza ed è entrata nelle decisioni di un consiglio di amministrazione europeo medio. Non per scelta editoriale. Per scadenza: l’11 settembre 2026, ogni produttore di software venduto in Europa dovrà notificare le vulnerabilità attivamente sfruttate entro 24 ore alla piattaforma centralizzata che la Commissione Europea sta costruendo — la Single Reporting Platform del Cyber Resilience Act.
Per sapere se un componente vulnerabile è presente nei propri prodotti in 24 ore, serve una cosa: la distinta base del software. Chi non ce l’ha, non può rispondere. Chi non può rispondere, è fuori conformità 15 mesi prima dell’obbligo formale di SBOM previsto per dicembre 2027.
La mia riflessione parte da una convinzione: la SBOM non è un adempimento tecnico. È il protocollo di interoperabilità che tiene insieme l’intera architettura regolatoria europea — ed è diventata una questione di sicurezza nazionale nel momento in cui l’Europa codifica e gli Stati Uniti frammentano. Chi controlla lo schema della software supply chain controlla la conformità globale del prossimo decennio.
La software supply chain è il nuovo perimetro di attacco
Non è una tesi teorica. Ad aprile 2026, ricercatori di sicurezza hanno identificato 73 nuove estensioni sleeper nel marketplace Open VSX collegate all’operazione GlassWorm — il secondo cluster in due mesi, dopo le 72 estensioni malevole e gli 88 pacchetti npm scoperti a marzo. Il totale dell’operazione supera 500 componenti compromessi, secondo CybersecurityNews. L’evoluzione tattica è significativa: le estensioni sleeper non iniettano codice malevolo immediatamente — costruiscono credibilità, accumulano download, e si attivano dopo. Una SBOM generata al momento dell’installazione le classifica come pulite. Solo l’attestazione continua dell’ambiente di build le cattura.
GlassWorm colpisce l’ambiente VS Code — lo strumento di sviluppo più usato al mondo, con oltre 15 milioni di utenti attivi. L’attacco non mira al luogo dove il software viene eseguito, ma al luogo dove viene scritto. E l’impatto non si limita agli sviluppatori: le estensioni compromesse sono state trovate anche in ambienti collegati alla supply chain automotive, dove gli strumenti di sviluppo condivisi fra fornitori moltiplicano la superficie di attacco.
GlassWorm è una campagna attiva, non un evento passato. Ad aprile 2026, 15 agenzie di sicurezza di 9 paesi hanno pubblicato un advisory congiunto su reti covert collegate alla Cina che compromettono infrastrutture critiche e mantengono accesso persistente, secondo il National Cyber Security Centre britannico. Una SBOM affidabile, in questa cornice, non è documentazione amministrativa. È la prima linea di difesa contro il pre-posizionamento.
Europa e Stati Uniti, approcci differenti
La risposta regolatoria europea alla fragilità della software supply chain non è un singolo regolamento. È un’architettura a strati dove quattro norme convergono sullo stesso protocollo. Il Cra impone la SBOM esplicitamente e il reporting delle vulnerabilità dal settembre 2026. La NIS2 chiede di gestire il rischio della supply chain ICT — il che implica conoscere i componenti del software dei fornitori. DORA, pienamente vincolante dal gennaio 2026, impone due diligence sulle terze parti ICT per le istituzioni finanziarie. L’AI Act richiede documentazione tecnica per i sistemi ad alto rischio, incluso l’inventario dei componenti.
La SBOM è il dato strutturato che circola fra questi framework — non un obbligo di un singolo regolamento, ma il protocollo di interoperabilità dell’intera cornice regolatoria.
La guida Enisa sulla SBOM — 84 pagine, struttura a 5 fasi, firma crittografica come requisito core — è in pubblicazione finale nel secondo trimestre 2026. La revisione della Cybersecurity Act estende lo scope alla supply chain e ai servizi di sicurezza gestiti. In Italia, l’Acn ha aperto la finestra di categorizzazione NIS2 dal 1° maggio al 30 giugno 2026 (Determinazione 155238 del 20 aprile): chi non ha una SBOM non può mappare i fornitori rilevanti entro la scadenza.
Dall’altro lato dell’Atlantico, la direzione è opposta. Il memorandum OMB M-26-05 del 23 gennaio 2026 ha rescisso il framework standardizzato per la SBOM federale e l’ha frammentato in requisiti specifici per ciascuna agenzia: 24 micro-mercati regolatori dove ogni agenzia decide se e come richiedere la SBOM ai propri fornitori. La Cisa — l’agenzia che aveva costruito lo standard — opera senza direttore confermato. Il consenso tecnico internazionale sulla SBOM è solido. La divergenza non è tecnica. È politica.
Non è autarchia europea. È il contrario: l’Europa sta usando uno standard tecnico già esistente per costruire un mercato regolato, mentre gli Stati Uniti scelgono di frammentarlo. E il Regno Unito si allinea all’Europa: la Financial Conduct Authority ha confermato le nuove regole PS26/2 su incident reporting e sorveglianza delle terze parti, con entrata in vigore il 18 marzo 2027 — convergendo di fatto sul framework DORA nonostante la Brexit. Per il fornitore software transatlantico, la complessità è aumentata su entrambi i fronti.
La SBOM da sola non basta, e lo sa già chi lavora sui prodotti
Dove chi produce il software non ha visibilità sul firmware, dove chi gestisce il firmware non ha letto il Cra, e dove chi analizza la conformità regolatoria non ha mai aperto l’architettura di un prodotto che integra componenti di terzi su tre livelli di supply chain — lì si forma il rischio di conformità. Tre competenze che non si parlano, e nel mezzo la responsabilità legale che cade sull’integratore finale.
Il problema si estende oltre il software classico. La SBOM tradizionale copre il codice con dipendenze esplicite scritte da sviluppatori umani. Ma il codice generato dall’intelligenza artificiale rompe questo modello: un modello di linguaggio non copia codice da un repository — lo sintetizza, rendendo il tracciamento delle dipendenze impossibile con gli strumenti attuali. War on the Rocks documenta che il codice generato dall’AI è già presente nei sistemi di difesa statunitensi, spesso senza piena tracciabilità.
Il concetto di AI Bill of Materials emerge come estensione necessaria della SBOM per coprire modelli, dataset, embedding e servizi AI di terze parti. E i limiti non si fermano qui: HBOM per i componenti hardware, CBOM per la crittografia in transizione post-quantum. La SBOM non è la soluzione finale. È il primo strato di una mappa che deve ancora essere completata — una mappa che si estende dal firmware delle centraline ai modelli linguistici, passando per i semiconduttori e gli algoritmi crittografici.
L’obiezione che mi aspetto è prevedibile: «La SBOM è un costo che le piccole e medie imprese non possono sostenere.» L’obiezione è comprensibile, ma sbaglia il punto. Il mercato italiano della cybersecurity ha raggiunto 2,78 miliardi di euro nel 2026, secondo l’Osservatorio del Politecnico di Milano, trainato proprio dalla conformità NIS2 e DORA. La domanda c’è. Il Rapporto Clusit 2026 documenta il divario persistente tra ambizioni di conformità e capacità operativa delle PMI italiane. La SBOM non è un costo aggiuntivo — è il prerequisito senza il quale il resto della conformità non regge. E il costo della non-SBOM non è una sanzione. È un breach che nessuno ha visto arrivare perché nessuno sapeva cosa c’era dentro il software.
La finestra si restringe
Il mercato della SBOM è nella fase di accelerazione di una curva a S. I catalizzatori sono datati con precisione: settembre 2026 per il reporting Cra, maggio-giugno 2026 per la categorizzazione Acn in Italia, marzo 2027 per le nuove regole della Financial Conduct Authority britannica che convergono su DORA, dicembre 2027 per l’obbligo SBOM pieno. Solo il 21% delle organizzazioni dichiara visibilità completa sulla propria software supply chain (Anchore, 2024). Il margine fra domanda regolatoria e capacità operativa è lo spazio dove si decide chi cattura il mercato e chi lo subisce.
Enisa non sta scrivendo una guida tecnica: sta diventando il data model designer della conformità europea. La firma crittografica come requisito core non è un dettaglio implementativo — è la chiave che renderà la SBOM machine-readable fra Bruxelles, Roma e Londra, e che taglierà fuori chi consegna fogli di calcolo o PDF firmati a mano. Chi adotta lo schema Enisa per primo acquisisce un vantaggio strutturale su chi aspetta l’obbligo.
La domanda operativa è semplice e brutale: conosci i componenti del software che il tuo prodotto integra? Non le funzionalità — i componenti, le dipendenze, le vulnerabilità. Sai cosa succede quando un componente end-of-life viene colpito da una vulnerabilità critica e la piattaforma Cra ti chiede la notifica in 24 ore? Hai visibilità sulla supply chain fino al firmware, non solo fino al software applicativo? Sai quale fornitore tier-2 ti farà sforare la deadline europea senza nemmeno saperlo?
Chi si muove adesso compra tempo e potere contrattuale. Chi aspetta dicembre 2027 scoprirà che il gap di conformità ha un costo di recupero che nessuno aveva budgetato. Non è un costo di adeguamento. È il costo di una software supply chain che non hai mai mappato.
Chi questa mappa la disegna per primo non sta solo conformandosi. Sta scegliendo da che parte del nuovo confine regolatorio europeo trovarsi quando, l’11 settembre 2026, la Single Reporting Platform aprirà le notifiche. Lo schema della software supply chain non è un dettaglio implementativo. È il terreno su cui si gioca la sovranità tecnologica del prossimo decennio — e l’Europa lo sta tracciando adesso.
