Avvia una prova

Note operative Normativa

Cyber Resilience Act: senza SBOM niente CE dall’11 dicembre 2027

8 min di lettura

Tutti i componenti di un apparecchio smontato, allineati uno accanto all’altro su un fondo chiaro
Una distinta base è esattamente questo: ogni pezzo elencato, nessuno escluso — anche quelli che nessuno voleva mostrare.

L’11 dicembre 2027 il Regolamento (UE) 2024/2847 — il Cyber Resilience Act — si applica per intero: lo fissa l’art. 71, § 2. Da quel giorno un prodotto con elementi digitali si immette sul mercato dell’Unione soltanto se il fabbricante, prima, ha redatto la documentazione tecnica dell’art. 31, ha svolto la valutazione di conformità dell’art. 32, ha firmato la dichiarazione di conformità UE dell’art. 28 e ha apposto la marcatura CE secondo l’art. 30. È la sequenza dell’art. 13, § 12: se manca il primo anello, non esiste l’ultimo. E dentro quel fascicolo c’è una voce nuova — la distinta base del software. Da oggi, 25 luglio 2026, mancano poco più di sedici mesi.

Non è l’obbligo di settembre

Il CRA entra a tappe, ed è facile confonderle. L’art. 14 — segnalazione delle vulnerabilità sfruttate e degli incidenti gravi, preallarme in 24 ore e notifica in 72 — si applica dall’11 settembre 2026, fra meno di sette settimane; il capo IV sugli organismi notificati è in vigore dall’11 giugno 2026. Ma settembre è un obbligo di comportamento: cosa fate quando succede qualcosa, e si regge su una casella di posta, una policy e un responsabile nominato. L’11 dicembre 2027 è un obbligo di prodotto e di carta: un fascicolo per famiglia di prodotto, aggiornato versione per versione, che dovete avere già scritto per poter vendere. Non si recupera nelle ultime settimane.

Cosa deve contenere il fascicolo

L’art. 31, § 1 rimanda all’Allegato VII, che elenca il contenuto minimo:

  1. descrizione generale del prodotto: finalità prevista, versioni del software rilevanti per la conformità, disposizione interna se c’è hardware, istruzioni per l’utilizzatore dell’Allegato II;
  2. progettazione, sviluppo, produzione e gestione delle vulnerabilità — disegni e schemi, una descrizione dell’architettura che spieghi come i componenti software si alimentano a vicenda, la distinta base del software, la politica di divulgazione coordinata, il canale di segnalazione, i meccanismi di distribuzione sicura degli aggiornamenti;
  3. la valutazione dei rischi di cibersicurezza dell’art. 13;
  4. le informazioni usate per determinare il periodo di assistenza, che l’art. 13, § 8 fissa in almeno cinque anni;
  5. norme armonizzate e certificazioni applicate — o, in mancanza, le soluzioni adottate al loro posto;
  6. le relazioni delle prove eseguite;
  7. copia della dichiarazione di conformità UE;
  8. «se del caso, la distinta base del software, a seguito di una richiesta motivata di un’autorità di vigilanza del mercato».

L’art. 13, § 13 chiude il cerchio: fascicolo e dichiarazione restano a disposizione delle autorità per almeno dieci anni dall’immissione sul mercato, o per il periodo di assistenza se più lungo. Non un modulo da archiviare: un archivio vivo.

Una riga di regolamento, una radiografia

L’obbligo sostanziale sta nell’Allegato I, parte II, punto 1: i fabbricanti «identificano e documentano le vulnerabilità e i componenti contenuti nel prodotto con elementi digitali, redigendo anche una distinta base del software in un formato di uso comune e leggibile da un dispositivo automatico, che includa almeno le dipendenze di primo livello del prodotto». L’art. 3, punto 39) la definisce «un registro formale contenente i dettagli e le relazioni della catena di approvvigionamento dei componenti inclusi negli elementi software». Non è un foglio di calcolo compilato a fine progetto: è un artefatto macchina-leggibile che si rigenera a ogni release.

E dice molto più di «cosa c’è dentro»: quali librerie open source usate e in quale versione esatta, quali componenti commerciali avete comprato e da chi, come i moduli dipendono l’uno dall’altro. Da lì si ricostruiscono scelte architetturali, fornitori, costo di sostituire un pezzo. Incrociata con i database pubblici delle vulnerabilità, permette a chi la possiede di sapere prima del fabbricante quali versioni sono esposte e a cosa. È la stessa informazione che serve a difendersi e ad attaccare.

Il regolamento lo sa, e lascia il problema a voi

Il testo non nasconde la tensione, la gestisce. Il considerando 77 è esplicito: «I fabbricanti non dovrebbero essere obbligati a rendere pubblica la distinta base del software». L’Allegato II, punto 9 chiede l’indirizzo dove reperirla solo se il fabbricante decide di metterla a disposizione dell’utilizzatore; l’Allegato VII, punto 8 la subordina a una richiesta motivata dell’autorità; persino la valutazione europea delle dipendenze software dell’art. 13, § 25 arriva all’ADCO anonimizzata e aggregata. E l’art. 63 impone a tutte le parti coinvolte di tutelare i segreti commerciali «compreso il codice sorgente».

Il legislatore ha costruito il proprio perimetro; il vostro dovete costruirlo voi. Vale la condizione che tutela già i manuali tecnici: la Direttiva (UE) 2016/943, recepita col D.Lgs. 11 maggio 2018, n. 63 sugli artt. 98-99 del Codice della Proprietà Industriale, protegge un’informazione come segreto commerciale solo se è segreta, ha valore economico in quanto tale ed è sottoposta a misure ragionevolmente adeguate a mantenerla segreta. Una SBOM caricata su un assistente cloud generico per «farla sistemare in fretta» smette silenziosamente di soddisfare la terza condizione. È un modello ricorrente, non l’accusa a qualcuno: quando il documento è difficile e la scadenza vicina, la scorciatoia più comoda porta sempre il file fuori dall’azienda.

Chi dovrà mostrarlo a un terzo

Non tutti i prodotti si autocertificano. L’Allegato III elenca quelli «importanti» — classe I: sistemi operativi, router e switch, VPN, SIEM, microcontrollori e FPGA con funzionalità di sicurezza, telecamere e serrature intelligenti, indossabili per il monitoraggio della salute; classe II: ipervisori e runtime di container, firewall e IDS/IPS, microprocessori a prova di manomissione. L’Allegato IV elenca i «critici»: gateway dei contatori intelligenti, carte intelligenti ed elementi sicuri. Per la classe I, se non si applicano integralmente norme armonizzate, scatta l’esame UE del tipo (modulo B+C) o la garanzia della qualità totale (modulo H); per la classe II uno dei due, sempre; per l’Allegato IV serve un sistema europeo di certificazione (art. 32, §§ 2-4). In tutti questi casi il fascicolo esce dall’azienda e finisce sul tavolo di un organismo notificato. L’art. 12 aggiunge un ponte: un prodotto che è anche sistema di IA ad alto rischio (art. 6 del Regolamento (UE) 2024/1689) si presume conforme ai requisiti di cibersicurezza dell’art. 15 dell’AI Act se rispetta l’Allegato I del CRA e lo dimostra nella dichiarazione UE. Un solo fascicolo, due regolamenti.

Quanto costa non averlo

L’art. 64 mette cifre, non ammonimenti. Non conformità ai requisiti essenziali dell’Allegato I e agli obblighi degli artt. 13 e 14: fino a 15 milioni di euro o il 2,5% del fatturato mondiale annuo, se superiore. Documentazione tecnica (art. 31, §§ 1-4), dichiarazione di conformità (art. 28), marcatura CE (art. 30, §§ 1-4): fino a 10 milioni o il 2%. Informazioni inesatte, incomplete o fuorvianti agli organismi notificati e alle autorità di vigilanza — cioè un fascicolo compilato male — fino a 5 milioni o l’1%. Ma prima delle sanzioni c’è il blocco: niente fascicolo, niente dichiarazione; niente dichiarazione, niente CE; niente CE, niente mercato unico. Lo stesso schema del Regolamento Macchine, dove è il manuale a decidere la marcatura dal 14 gennaio 2027.

Cosa fare adesso

  1. Classificate ogni prodotto: ordinario, Allegato III classe I o II, Allegato IV. È questo che determina se il fascicolo lo leggerà solo la vigilanza del mercato o anche un organismo notificato.
  2. Generate la SBOM per prodotto e per versione, leggibile da un dispositivo automatico, almeno con le dipendenze di primo livello, e legatela alla pipeline di rilascio: compilata a mano, alla terza release è già falsa.
  3. Decidete e motivate il periodo di assistenza: le ragioni della scelta sono un elemento richiesto dall’Allegato VII, punto 4, non una nota interna.
  4. Classificate la SBOM come documento riservato oggi, non alla prima richiesta motivata: chi la vede, con quale canale la trasmettete, dove è archiviata. È la prova delle «misure ragionevolmente adeguate».
  5. Unificate il fascicolo: l’art. 31, § 3 impone una documentazione tecnica unica per i prodotti soggetti anche ad altri atti dell’Unione. Chi sta già riscrivendo manuali per il gennaio 2027 lavora sullo stesso raccoglitore.

Come lo risolviamo noi

Compilare e verificare fascicoli tecnici e distinte software è un lavoro documentale enorme su materiale che è insieme obbligatorio da produrre e vietato da far circolare. Lo affrontiamo con AI dedicate e chiuse, sganciate dal web aperto, nelle due modalità della nostra offerta: on-premise nell’ambiente del cliente, oppure sul nostro cloud dedicato — ambiente riservato al singolo cliente, accesso via VPN dedicata, data center residente in Italia, locali che presidiamo direttamente. In entrambi i casi distinta e codice restano dentro il perimetro: il sistema legge il fascicolo contro i punti dell’Allegato VII e i requisiti dell’Allegato I, mostra dove manca un elemento e propone come colmarlo; revisione e firma restano all’ufficio tecnico. È il metodo della nostra conformità documentale assistita, lo stesso che nei distretti manifatturieri applichiamo a manuali e istruzioni: costruito una volta, regge più scadenze insieme.

Volete sapere quanti dei vostri prodotti connessi avrebbero oggi un fascicolo tecnico presentabile, senza che il codice esca dall’azienda? Mezz’ora con un nostro esperto basta per la prima mappa.

Fonti