Quando mio figlio sarà abbastanza grande da scegliere una merendina, gli insegnerò a guardare l’etichetta. Non perché debba diventare un nutrizionista a sei anni, ma perché è utile sapere che cosa c’è dentro ciò che prendiamo dallo scaffale e, soprattutto, essere avvertiti quando uno degli ingredienti può farci male.
Dall’11 settembre 2026 una logica simile entrerà nel mondo del software. Non troveremo una scritta «può contenere tracce di vulnerabilità» stampata sul router o sull’applicazione; entreranno però in applicazione gli obblighi di segnalazione previsti dall’articolo 14 del Cyber Resilience Act, il regolamento europeo che disciplina la sicurezza dei prodotti con elementi digitali. Quando una vulnerabilità viene sfruttata attivamente o si verifica un incidente grave, fabbricanti e altri soggetti responsabili non potranno limitarsi a sistemare il problema in silenzio.
La metafora dello snack aiuta, purché non la si prenda troppo alla lettera. Un allergene è una caratteristica conosciuta dell’ingrediente e deve essere indicato a prescindere da un incidente; una vulnerabilità informatica, invece, può emergere dopo che il prodotto è stato venduto e diventa particolarmente urgente quando qualcuno ha già iniziato a sfruttarla. L’etichetta del CRA, perciò, non è immobile: assomiglia a un avviso che può comparire mentre il prodotto è già nelle case, negli uffici o nelle fabbriche.
Il primo concetto da spiegare a mio figlio sarebbe proprio questo: una vulnerabilità è un difetto che consente di fare al prodotto qualcosa che non dovrebbe essere possibile. Può permettere a un estraneo di entrare, sottrarre dati, impartire comandi o bloccare il servizio. «Attivamente sfruttata» significa che non siamo più davanti alla sola possibilità teorica; esistono elementi affidabili che indicano che qualcuno ha già usato quella falla in un sistema reale.
Dal momento in cui il fabbricante ne viene a conoscenza parte un cronometro molto rapido. Secondo l’articolo 14 del regolamento (UE) 2024/2847, l’avvertimento iniziale deve essere trasmesso senza ingiustificato ritardo e comunque entro ventiquattro ore. Non è ancora il rapporto definitivo: serve a far sapere alle autorità che esiste un problema, quale prodotto riguarda, quali Stati potrebbero essere coinvolti e, quando disponibili, quali misure immediate sono state adottate.
Entro settantadue ore deve seguire una notifica più completa, con le informazioni generali sulla vulnerabilità, sulla gravità e sull’impatto, oltre alle misure correttive o di mitigazione già disponibili. Per una vulnerabilità attivamente sfruttata, la relazione finale arriva poi entro quattordici giorni dalla disponibilità della misura correttiva o di mitigazione. Se si tratta invece di un incidente grave che incide sulla sicurezza del prodotto, dopo il primo avviso e la notifica delle settantadue ore la relazione finale deve essere presentata entro un mese.
Le segnalazioni confluiscono nella piattaforma unica europea gestita da ENISA. La Commissione europea spiega che il sistema consente di notificare simultaneamente ENISA e il CSIRT designato dallo Stato membro interessato. Non è un indirizzo email al quale spedire tutto sperando che qualcuno risponda: è un’infrastruttura comune, costruita per far arrivare informazioni urgenti a chi deve coordinare la risposta e proteggere altri soggetti esposti.
Questo passaggio ha una conseguenza giuridica e organizzativa importante. Le ventiquattro ore non cominciano quando l’ufficio legale riceve una relazione ordinata, né quando il consiglio di amministrazione ha trovato uno spazio in agenda. Cominciano quando il fabbricante viene a conoscenza della vulnerabilità sfruttata o dell’incidente grave. Servono quindi flussi interni capaci di collegare sviluppo, assistenza, vulnerability management, sicurezza, direzione e funzione legale senza trasformare ogni segnalazione tecnica in una caccia al responsabile.
La notifica non riguarda soltanto Bruxelles, ENISA e le autorità. L’articolo 14, paragrafo 8, impone al fabbricante di informare gli utilizzatori interessati e, quando opportuno, tutti gli utilizzatori, comunicando la vulnerabilità attivamente sfruttata o l’incidente grave e le misure che possono adottare. La spiegazione deve essere chiara. Scrivere «applicare la mitigazione prevista dalla knowledge base» può essere sufficiente per uno specialista; per chi ha comprato una videocamera connessa serve qualcosa di più concreto: aggiornare il dispositivo, cambiare una configurazione, disattivare temporaneamente una funzione oppure scollegarlo dalla rete.
È la parte più vicina all’etichetta dello snack. Il produttore non comunica soltanto a chi controlla il mercato, ma anche alla persona che può evitare il danno. L’ENISA, nelle proprie domande frequenti sulla piattaforma, chiarisce il funzionamento del canale e la necessità di organizzare per tempo identità, ruoli e rappresentanti incaricati di effettuare le notifiche.
Non ogni bug farà partire questa macchina. Il regolamento distingue le vulnerabilità attivamente sfruttate dai difetti soltanto ipotetici e riserva agli incidenti una soglia di gravità. Sarebbe controproducente sommergere le autorità con qualsiasi imperfezione del codice; sarebbe altrettanto pericoloso usare questa distinzione come alibi per non vedere segnali concreti di sfruttamento. La classificazione deve essere documentata, rapida e comprensibile anche mesi dopo, quando qualcuno chiederà perché l’allarme non sia stato dato.
C’è poi un dettaglio che molte imprese rischiano di scoprire tardi. Gli obblighi di notifica si applicano dall’11 settembre 2026, prima dell’applicazione generale del CRA prevista per l’11 dicembre 2027, e possono riguardare anche prodotti già immessi sul mercato. Non basta quindi progettare bene il prossimo dispositivo: occorre sapere quali prodotti sono ancora supportati, chi riceve le segnalazioni, dove si trovano le evidenze e come raggiungere gli utilizzatori.
La preparazione concreta è meno misteriosa della terminologia europea. Serve un inventario attendibile dei prodotti; un canale per ricevere le vulnerabilità; criteri per valutare sfruttamento e gravità; persone autorizzate ad accedere alla piattaforma; un meccanismo decisionale che funzioni anche di notte e nei giorni festivi; modelli di comunicazione che possano essere capiti da utenti reali. Occorre inoltre conservare ciò che dimostra quando l’organizzazione ha saputo, che cosa ha verificato e perché ha scelto di notificare o di non notificare.
Spiegata a mio figlio, la regola sarebbe questa: se scopri che nella merendina c’è qualcosa che sta già facendo male alle persone, non nascondi la confezione e non aspetti di avere scritto il rapporto perfetto. Avverti subito chi deve intervenire, entro poco tempo spieghi meglio che cosa è successo e dici a chi l’ha comprata come proteggersi. Il Cyber Resilience Act chiede al software esattamente questo. Anche se quella cosa non si mangia.