La sovranità non abita nel data center

Il Cloud and AI Development Act, che la Commissione ha pubblicato il 3 giugno dentro il pacchetto sulla sovranità tecnologica, si presta a una lettura comoda. È la lettura geografica, quella dei megawatt e dei tempi di rilascio delle autorizzazioni, di dove finiscono fisicamente i byte e di quale fornitore americano resterà fuori dalle gare pubbliche europee. Va riconosciuto che è una lettura difendibile, perché i numeri la sostengono. La quota di mercato dei fornitori cloud europei è scesa da circa il ventinove per cento del 2017 a circa il quindici per cento del 2022, la carenza di capacità nei data center è documentata, l’ambizione dichiarata è triplicare quella capacità nell’arco di cinque o sette anni, e il primo dei quattro livelli di assurance previsti dal regolamento chiede letteralmente che il trattamento e l’archiviazione dei dati avvengano su infrastruttura europea. Da qui l’interpretazione che gira su tutti i tavoli in queste settimane, ed è la più rassicurante che si possa immaginare: sovranità vuol dire che i dati sono tornati a casa.

Oltre il primo livello

L’interpretazione ha un difetto, e il difetto è che si ferma al primo livello. Se si legge oltre, il baricentro del regolamento si sposta in un punto molto meno fotogenico. Il secondo livello non domanda dove stiano i dati. Domanda indipendenza dimostrabile dai paesi terzi e trasparenza sulla catena di fornitura del software. Il quarto livello chiede il controllo pieno su quella stessa catena, senza interferenze esterne sul codice che gira. C’è poi un meccanismo più sottile, che vive nelle regole di appalto: le amministrazioni dovranno considerare il cosiddetto valore aggiunto per l’Unione come criterio non economico nell’aggiudicazione, ossia quanto un fornitore contribuisca alla resilienza della filiera digitale europea. Il regolamento precisa che questo criterio deve restare accessorio e non decisivo, con un peso massimo che i considerando collocano intorno ai quindici punti su centoventi, eppure introduce comunque un vantaggio strutturale per chi ha ricerca e produzione dentro i confini. E poi c’è la parte che tocca il mio lavoro più da vicino, perché esce dal perimetro del settore pubblico: il regolamento dà alla Commissione il potere di estendere, con atti delegati, gli stessi obblighi di valutazione della sovranità alle imprese private dei settori già regolati da NIS2, vale a dire le banche, l’energia, le telecomunicazioni, la sanità. Chiunque costruisca software per quei comparti farebbe bene a leggere oltre il primo livello.

La scommessa che l’Europa ha piazzato all’inizio di giugno, sotto la patina infrastrutturale, non è geografica. È una scommessa sulla provenienza verificabile del codice. E non arriva adesso per caso. Sono le stesse settimane in cui il continente ha toccato con mano cosa significhi dipendere da decisioni prese altrove, quando un provvedimento unilaterale di controllo sulle esportazioni ha reso indisponibili dall’oggi al domani modelli di frontiera già in uso da migliaia di persone. Il CADA è, in buona parte, il riflesso strutturale di quella dipendenza percepita. La domanda implicita che lo attraversa non è dove tieni i tuoi dati, ma se sei in grado di sapere, e di dimostrare, cosa c’è dentro il software che fai girare. Conviene tenerla a mente, questa parola, provenienza, perché nella stessa quindicina di giorni qualcuno ne ha mostrato il fondo.

Diecimila repository che fingono

Il 18 giugno un ricercatore che firma con lo pseudonimo Orchid ha pubblicato i risultati di un’indagine durata mesi. La storia è cominciata nel modo più banale: cercando il proprio progetto su un motore di ricerca, Orchid ha trovato al suo posto un clone con nome e descrizione identici, ospitato da un account diverso. Da lì è partita la caccia, condotta con un singolo script Python che ha setacciato sedici milioni di eventi di push registrati nell’archivio pubblico di GitHub alla ricerca di una firma ricorrente. Il risultato è un numero che ad aprile, in un’analisi precedente di altri ricercatori, si fermava a centonove repository, e che a giugno era arrivato a circa diecimila, con la campagna attiva almeno da inizio 2025. Tutti distribuivano la stessa famiglia di malware, un loader che apriva la strada a un programma di furto di credenziali. Il dettaglio che fa la differenza, e che la maggior parte delle cronache ha trattato come un particolare tecnico, è il modo in cui questi repository si rendevano credibili. Non erano fork. Erano cloni creati ex novo, con la cronologia dei commit copiata di peso dal progetto originale e l’attribuzione lasciata intatta sugli autori reali, così che cliccando sui contributor comparivano account veri e storici. L’unica modifica era un collegamento nel file di descrizione che puntava a un archivio compresso. La cosa che li faceva sembrare affidabili era esattamente il segnale di provenienza su cui ci appoggiamo da dieci anni: la storia lunga e gli autori riconoscibili, l’aria di un progetto vissuto.

Alcuni di questi repository sopravvivevano da oltre un anno, e ci riuscivano con un trucco che dice molto su come funziona la fiducia automatizzata. Cancellavano periodicamente l’ultimo commit e ne ripubblicavano uno identico, intitolato sempre allo stesso modo, ogni poche ore. Bastava a confondere gli algoritmi di sicurezza della piattaforma, tarati per segnalare l’attività improvvisamente sospetta più che l’anomalia quieta e prolungata. Ma la parte che dovrebbe inquietare più del numero è la risposta di GitHub a chi, prima di Orchid, aveva segnalato il meccanismo attraverso i canali ufficiali. La piattaforma ha respinto i report sostenendo che i commit retrodatati sono un caso d’uso legittimo per chi lavora offline, e ha qualificato il rendere più visibile la cronologia reale dei push come una richiesta di funzionalità, non come una correzione di sicurezza. Tradotto: la piattaforma che ospita la quasi totalità dell’open source mondiale ha deciso che il problema della provenienza non è un suo problema. Orchid, di fronte al silenzio, ha pubblicato sia lo strumento di rilevazione sia l’elenco completo dei repository individuati, perché segnalarli uno per uno era materialmente impossibile.

Una linea, non un incidente

Vale la pena collocare questa vicenda in una linea, perché da sola sembra un incidente e in fila con le altre rivela una direzione. Nel 2020 SolarWinds aveva mostrato che si potevano colpire migliaia di organizzazioni compromettendo un solo fornitore a monte. Nel 2024 il caso di XZ Utils aveva alzato l’asticella della pazienza, con un attaccante che aveva passato mesi a guadagnarsi la fiducia di un progetto open source per inserirvi una backdoor in qualità di manutentore legittimo. Il 2026 ha spostato il bersaglio ancora più in là. A maggio la campagna ribattezzata Megalodon ha iniettato in poche ore workflow malevoli in oltre cinquemila repository, progettati per rubare i segreti delle pipeline di integrazione continua e ogni credenziale cloud a portata. Negli stessi giorni, lo stesso GitHub ha confermato che un dispositivo di un suo dipendente, infettato tramite un’estensione malevola di un editor molto diffuso, aveva permesso l’esfiltrazione di circa tremilaottocento repository interni. La campagna di Orchid si muove su un asse diverso ma complementare: non compromette un progetto reale, ne fabbrica di falsi che indossano i panni di quelli veri. Messe in sequenza, queste storie raccontano un solo movimento. La superficie d’attacco si è spostata dal codice ai metadati della fiducia, e dalle mani umane alle pipeline automatiche. Mentre noi spostavamo lo sviluppo verso l’orchestrazione di agenti che clonano ed eseguono codice senza più la frizione del giudizio umano, l’avversario imparava a falsificare proprio i segnali che quella frizione, un tempo, leggeva. E non è una figura retorica. Orchid ha notato che molti di quei repository erano costruiti per adescare gli agenti, non solo le persone. Il meccanismo lo ha descritto una ricerca parallela sulle vulnerabilità degli assistenti di codifica: file di configurazione avvelenati, le istruzioni che strumenti come Copilot o Cursor leggono all’avvio per sapere come comportarsi, scritte in modo da dirottare in silenzio tutto il codice generato da lì in poi nella sessione. L’istruzione malevola sopravvive alla copia del repository e si propaga ai progetti a valle. Quando a clonare è un agente che poi scrive codice al posto tuo, il falso segnale di provenienza smette di ingannare un essere umano distratto e comincia a contaminare la fonte stessa di ciò che verrà prodotto.

Aperto non vuol dire ispezionato

A questo punto l’editorialista pigro ha già il suo pezzo pronto, e anche il titolo. L’open source first incontra l’open source che nessuno verifica. La sovranità europea costruita sul codice ispezionabile, smentita nella stessa quindicina di giorni da diecimila progetti ispezionabili e tossici. È un’ironia che regge per la durata di un post e non un millimetro oltre, perché poggia su un equivoco che conviene smontare con calma.

L’argomento a favore dell’open source come fondamento della sovranità è corretto, e va preso sul serio prima di provare a scalfirlo. Un componente i cui sorgenti sono pubblici e le cui dipendenze sono dichiarate parte da una posizione migliore di uno stack proprietario dentro cui non si può guardare. È la tesi che SUSE ha formulato con precisione commentando il regolamento: l’infrastruttura aperta, dove ogni componente è ispezionabile e ogni dipendenza è dichiarata, soddisfa quel requisito di trasparenza in un modo che il software chiuso non raggiunge. È vero. La campagna di Orchid non smonta questa tesi, la sposta di un passo, su un terreno che la tesi non copriva. Aperto vuol dire ispezionabile in linea di principio. Non vuol dire ispezionato. E alla scala di centinaia di milioni di repository, il principio è precisamente il luogo dove si annidano gli attacchi. La fiducia, nello sviluppo software, è un’economia come tutte le altre, e come tutte le altre cerca di risparmiare. Leggere davvero il codice di ogni dipendenza che importiamo costerebbe più del tempo che abbiamo, e così non lo facciamo quasi mai. Leggiamo i segnali che gli stanno intorno: il numero di stelle, la cronologia, gli autori, la posizione nei risultati di ricerca. Quei segnali sono una procura, una delega che firmiamo in tre secondi ogni volta che cloniamo qualcosa. Gli attaccanti di Orchid non hanno violato la nostra capacità di leggere il codice. Hanno imparato a coniare la moneta con cui paghiamo la fiducia per non doverlo leggere. La falsificazione non riguarda il sorgente, riguarda l’apparato che ci dispensa dal guardarlo.

La SBOM diventa legge

Qui il discorso smette di essere filosofico e diventa una scadenza sul calendario. Lo strumento che trasforma la trasparenza promessa dal regolamento in qualcosa di operativo esiste, ha un nome poco elegante e una base giuridica ormai precisa. È la distinta dei materiali del software, la SBOM, e con il Cyber Resilience Act diventa per la prima volta un obbligo di legge e non più una buona pratica. Le date sono ravvicinate. Dall’11 settembre 2026 chi mette sul mercato europeo un prodotto con elementi digitali deve notificare le vulnerabilità attivamente sfruttate entro ventiquattro ore. Dall’11 dicembre 2027 deve conservare nella documentazione tecnica una SBOM in formato leggibile dalle macchine, che copra almeno le dipendenze di primo livello e resti aggiornata per tutto il periodo di supporto del prodotto. Le sanzioni sono dimensionate sul modello del GDPR, fino a quindici milioni di euro o il due e mezzo per cento del fatturato mondiale. E c’è un dettaglio che molti scoprono solo durante la prima valutazione: non puoi notificare ciò che non sai di avere. La scadenza di settembre 2026 sulle vulnerabilità rende la SBOM un prerequisito pratico già da subito, ben prima che diventi formalmente obbligatoria, perché senza un inventario accurato delle dipendenze la finestra di ventiquattro ore è impossibile da rispettare.

Lavorando da tempo su strumenti di questo tipo per clienti in settori regolati come la sanità e la pubblica amministrazione, il fraintendimento che incontro più spesso è che la SBOM sia il prodotto da consegnare. Non lo è. La SBOM è la domanda. E qui conviene fare subito una concessione a chi conosce la materia, perché l’obiezione è fondata e va disinnescata prima che venga sollevata. Una distinta dei materiali, presa per quello che la maggior parte delle organizzazioni ne fa, l’attacco di Orchid non lo vede nemmeno. Quei repository non infilano una dipendenza malevola dentro il tuo manifest, ti convincono a clonare ed eseguire un progetto che indossa i panni di un altro. Uno scanner che confronta il tuo albero delle dipendenze con un database di vulnerabilità note ci passa attraverso senza accorgersi di niente, perché l’inganno non abita nell’elenco, abita nell’origine di ciò che l’elenco enumera. Ed è esattamente questo il punto. La versione inutile della SBOM, quella prodotta per prima quasi ovunque, è un fermo immagine: un elenco statico di componenti, magari un PDF, generato la sera prima dell’audit e mai più toccato, che dice cosa hai messo dentro e tace su da dove viene e se è davvero quello che dichiara di essere. I diecimila repository della campagna supererebbero un controllo del genere senza battere ciglio. La domanda che conta non è quali componenti ci sono, è se ciascuno di essi proviene davvero da dove sostiene di provenire, e a quella domanda non risponde un documento, risponde una verifica eseguita nel momento esatto in cui il componente entra nella build.

Chi firma la dichiarazione

Ed è qui che la SBOM, da sola, non basta, perché una SBOM è una dichiarazione, e una dichiarazione si può falsificare con la stessa facilità con cui si falsifica una cronologia di commit. La domanda vera arretra di un passo: chi firma quella dichiarazione, e quanto è difficile per un attaccante firmarne una falsa. La risposta, per chi lavora nella sicurezza della filiera, passa per uno strato di strumenti che negli ultimi anni è maturato parecchio. Il modello di riferimento si chiama SLSA e definisce per livelli quanto è affidabile la storia di come un artefatto è stato costruito. Quella storia viene espressa in un formato di attestazione firmata che si chiama in-toto, e firmata davvero grazie a Sigstore, che evita il fardello di gestire chiavi a lungo termine legando ogni firma a un’identità verificata sul momento e registrandone la traccia in un registro pubblico e immutabile. Il punto cruciale di questo impianto non è la crittografia in sé, è chi ha in mano la penna. L’autocertificazione non vale niente: se è lo stesso script di build a generare la prova della propria onestà, un attaccante che controlla lo script può far dire alla prova quello che vuole. Lo si è visto pochi mesi fa con un attacco alla catena dei pacchetti che portava attestazioni di provenienza crittograficamente valide, prodotte però da una piattaforma di costruzione che non garantiva l’isolamento richiesto dai livelli più alti di SLSA. La provenienza diventa credibile solo quando a generarla è un ambiente isolato, controllato dalla piattaforma e non dall’utente, in modo che nemmeno chi ha accesso alla configurazione possa mentire. Non a caso le build riproducibili, ossia la capacità di ricostruire bit per bit lo stesso artefatto a partire dagli stessi sorgenti, sono state tolte dalle versioni recenti di SLSA: erano l’ideale teorico, e si sono rivelate troppo difficili da ottenere nella pratica. Anche la verifica, insomma, ha il suo regresso. Qualcuno deve certificare il certificatore, e la sola risposta solida è spostare quel qualcuno fuori dalla portata di chi avrebbe interesse a barare.

E qui l’ironia che l’editorialista pigro aveva intravisto torna, ma molto più affilata di come l’aveva lasciata. Lo strato di attestazione che ho appena descritto è maturo. Lo stesso GitHub offre nativamente la generazione di prove di provenienza firmate per gli artefatti che escono dalle sue pipeline, e raggiungere un livello dignitoso di garanzia è oggi questione di un pomeriggio di lavoro, non più di un progetto di settimane. La piattaforma, cioè, fornisce il lucchetto crittografico per il pacchetto che produci e nello stesso tempo lascia falsificabile per scelta la targhetta con il nome sulla porta del repository da cui quel pacchetto sembra provenire. Mette a disposizione gli strumenti per dimostrare che un artefatto viene da una certa build, e si rifiuta di rendere più difficile fingere che un intero progetto venga da un certo autore. Le due cose vivono allo stesso indirizzo e non si parlano.

Dove abita la sovranità

Allora torniamo alla domanda da cui siamo partiti, dove abita la sovranità. Non nel data center, che è la parte facile da legiferare e facile da misurare, ed è esattamente per questo che tutti ne parlano. La geografia dei byte è un problema risolto sulla carta nel momento in cui lo scrivi in un capitolato. La provenienza dei componenti che girano dentro quel data center è un problema che va dimostrato di nuovo a ogni build, su ogni dipendenza, contro un avversario che ha tutto l’interesse a sembrare in regola. L’Europa ha fatto, forse senza dirlo fino in fondo, della provenienza il muro portante dell’intero edificio. Ma il linguaggio del regolamento nomina il risultato e tace sul meccanismo. Chiede trasparenza sulla catena di fornitura e non dice firmata da chi, né verificata contro quale criterio al momento del rilascio in produzione. La distanza tra avere una SBOM e poter dimostrare che la SBOM dice il vero è l’intera partita, ed è proprio la distanza che la stessa quindicina di giugno ha messo a cielo aperto. Da un lato un regolamento che scommette sulla filiera verificabile, dall’altro un ricercatore solo che con uno script dimostra che la filiera, oggi, non sa attestare se stessa.

Resta da dire la cosa scomoda. L’open source first è il principio giusto e un principio vuoto finché aperto non viene accoppiato ad attestato. La trasparenza dei sorgenti è una condizione necessaria della sovranità e non è in alcun modo sufficiente, perché tra il poter guardare e l’aver guardato si apre lo spazio in cui un avversario costruisce diecimila repository che nessuno guarda. La sovranità non è un luogo che si raggiunge, è una proprietà che si continua a dimostrare, e smette di esistere nell’istante esatto in cui si smette di verificarla. La SBOM non è un mobile della conformità da tenere in un angolo per l’auditor, è il punto in cui la parola sovranità tocca terra, a patto che sotto ci sia una catena di attestazione che la regge.

Che GitHub abbia chiamato funzionalità la correzione che avrebbe reso più difficile falsificare la provenienza è il dettaglio più rivelatore di tutta la storia. La piattaforma ha deciso che il livello di verifica non lo costruisce lei. Il che significa che, per chiunque prenda sul serio il linguaggio del regolamento europeo, quel livello diventa lavoro da fare altrove, nelle pipeline e nelle pratiche di chi consegna software per i settori che la legge sta per stringere. La scommessa europea sulla sovranità della filiera è, sotto sotto, la scommessa che qualcuno costruisca lo strato di attestazione che la piattaforma si rifiuta di costruire. Quello strato è il lavoro vero. Tutto il resto sono megawatt.

L'autore

Andrea MargiovanniCompliance EU

Lavoro a fianco di team che disegnano sistemi sotto AI Act, CRA, NIS2, GDPR. La regola non è una checklist: è un vincolo architetturale, e va portato a bordo prima del design, non dopo.

Vai al percorso →