Dall’11 settembre 2026 si applicano gli obblighi di segnalazione dell’articolo 14 del Cyber Resilience Act. Per un fabbricante che integra software di terzi, rispettarli dipende anche dalle informazioni ricevute lungo la filiera: una vulnerabilità conosciuta dal fornitore di un componente deve essere collegata alle versioni del prodotto che la contengono.
Il contratto può favorire questo lavoro, purché specifichi quali fatti comunicare e renda possibile una valutazione tempestiva anche quando l’indagine è incompleta. La distinzione fra vulnerabilità attivamente sfruttata e incidente grave incide sui presupposti e sui termini; la disponibilità di una misura per il componente richiede inoltre una verifica rispetto al prodotto finale e alle indicazioni da dare agli utilizzatori.
Indice degli argomenti
Obblighi di segnalazione CRA e vulnerabilità lungo la filiera
Un venerdì pomeriggio il fornitore di una libreria comunica al costruttore di un macchinario connesso che una vulnerabilità viene sfruttata in attacchi reali. Il messaggio identifica il componente, ma lascia ancora incerto quali versioni siano interessate. Il costruttore lo ha integrato in più generazioni del proprio prodotto, alcune modificate nel tempo; chi segue il contratto sa a chi chiedere un chiarimento commerciale, mentre il tecnico che conosce quella parte del software non è il referente indicato per le emergenze. In questo caso ipotetico non manca l’informazione iniziale. Manca il collegamento che dovrebbe permettere di capire rapidamente quali prodotti esaminare e quali persone coinvolgere.
Dall’11 settembre 2026 una difficoltà del genere può incidere sul rispetto degli obblighi dell’articolo 14 del Cyber Resilience Act, regolamento UE 2024/2847. L’applicazione generale del regolamento è prevista dall’11 dicembre 2027, ma per il reporting il legislatore ha anticipato la decorrenza. L’articolo 69, paragrafo 3, estende gli obblighi dell’articolo 14 anche ai prodotti rientranti nel suo ambito immessi sul mercato prima di quella data del 2027. Occorre quindi verificare l’inclusione del prodotto e le eventuali esclusioni previste dal CRA; essere già in commercio da anni, considerato isolatamente, non basta a chiudere l’esame. Allo stesso tempo sarebbe inesatto presentare come già applicabile, nel settembre 2026, tutto il complesso dei requisiti previsto per la fase successiva.
Dal componente al prodotto finale
Nel caso del macchinario il costruttore può essere fabbricante del prodotto finale mentre un altro operatore assume quella qualifica per il componente commercializzato separatamente. I rispettivi obblighi vanno esaminati sul proprio oggetto. La segnalazione relativa alla libreria potrebbe infatti descrivere versioni e condizioni che il cliente industriale non sa neppure riconoscere nel prodotto acquistato. Per il costruttore serve un passaggio ulteriore: stabilire dove il componente sia stato integrato, con quali modifiche e in quali configurazioni. Finché questo collegamento manca, inoltrare il messaggio ricevuto rischia di diffondere l’allarme a installazioni estranee o di lasciare fuori proprio quelle esposte.
La qualifica di fabbricante, inoltre, non coincide necessariamente con l’identità di chi ha scritto il codice. Il CRA considera anche chi fa progettare o fabbricare il prodotto e lo commercializza con il proprio nome o marchio. Affidare lo sviluppo a terzi può dunque lasciare al committente gli obblighi legati a quella posizione, pur collocando presso il fornitore le competenze e le prove necessarie per adempierli. Nel contratto questa separazione va affrontata espressamente. Attribuire allo sviluppatore «ogni responsabilità per la sicurezza» può regolare alcuni aspetti del rapporto economico fra le parti; non cambia, per il solo fatto di essere scritto, la qualifica prevista dal regolamento né garantisce che il fabbricante riceva in tempo le informazioni.
Subfornitori e componenti open source
Il problema si estende quando la libreria contiene a sua volta un componente di un subfornitore. L’impegno del contraente diretto a inoltrare le notizie ricevute serve poco se a monte non esiste un canale che gli consenta di conoscerle. Prima di negoziare i tempi della comunicazione conviene dunque capire quali fonti siano disponibili e chi le segua. Per alcune dipendenze sarà possibile ottenere impegni lungo la catena; per altre serviranno monitoraggio e supporto tecnico organizzati dal fabbricante. Nel caso di componenti open source, attribuire indistintamente a ogni manutentore la posizione di un fornitore commerciale sarebbe giuridicamente e praticamente improprio. Vanno considerate le regole del CRA sulle attività e sui soggetti coinvolti, insieme alle risorse effettivamente disponibili per gestire il componente nel prodotto distribuito.
Quando scattano gli obblighi di segnalazione del Cyber Resilience Act
Tornando al messaggio del venerdì, la prima verifica riguarda ciò che il fornitore intende per sfruttamento. La definizione di vulnerabilità attivamente sfruttata dell’articolo 3 richiede prove attendibili che un soggetto malevolo abbia sfruttato la vulnerabilità in un sistema senza l’autorizzazione del proprietario. Un identificativo CVE o un punteggio di gravità elevato, da soli, non dimostrano questo fatto. Anche una prova realizzata dal ricercatore in un ambiente autorizzato ha un significato diverso. Chiarire la natura dell’evidenza consente di valutare correttamente il presupposto del reporting, senza far dipendere ogni decisione dalla parola «critico» inserita nell’oggetto della mail.
Occorre poi accertare se la vulnerabilità sia contenuta nel prodotto del fabbricante. Il nome della libreria è soltanto l’inizio della verifica: possono contare versione e modifiche apportate, così come le condizioni nelle quali la funzione vulnerabile è utilizzata. L’assenza di segnalazioni provenienti dai propri clienti non autorizza ad attendere il primo attacco contro una loro installazione, quando esistono prove attendibili dello sfruttamento della vulnerabilità altrove e questa riguarda il prodotto. Per converso, un componente dal nome simile non rende automaticamente esposta ogni versione commercializzata. La conclusione deve essere documentata; anche un’eventuale mitigazione va descritta per ciò che riduce, perché limitare la raggiungibilità di una funzione non equivale necessariamente a eliminare la vulnerabilità.
Termini di 24 e 72 ore dalla conoscenza
Per questa fattispecie, l’articolo 14, paragrafo 2, prevede il preallarme senza indebito ritardo e comunque entro 24 ore dalla conoscenza, seguito dalla notifica entro 72 ore dallo stesso momento, se le informazioni pertinenti non sono già state fornite. Chi prepara il calendario deve prestare attenzione alla decorrenza: le 72 ore non iniziano dopo l’invio del preallarme. La relazione finale ha invece un riferimento diverso e deve essere presentata entro 14 giorni dalla messa a disposizione di una misura correttiva o di attenuazione. Registrare soltanto la data di apertura del ticket lascerebbe quindi incompleta la cronologia necessaria a gestire il caso.
Neppure la riunione del comitato che autorizza l’invio può diventare, per decisione interna, l’unico momento nel quale l’organizzazione si considera informata. Se il fabbricante dispone già di elementi attendibili il venerdì, il fatto che il referente legale li esamini il lunedì non basta a spostare la decorrenza. L’imputazione della conoscenza richiede un esame concreto delle circostanze e delle funzioni coinvolte.
Per questo serve conservare il primo messaggio, insieme alle verifiche compiute e agli aggiornamenti: un’informazione generica può acquistare un significato diverso quando viene identificata la versione, e quella differenza deve restare ricostruibile. Il termine massimo previsto dalla legge, peraltro, convive con il requisito di assenza di indebito ritardo; non costituisce un tempo da consumare per abitudine anche quando gli elementi necessari sono già disponibili.
Incidenti gravi e calendario della relazione finale
Se la notizia riguarda invece una compromissione del sistema con cui vengono distribuiti gli aggiornamenti, il fabbricante deve considerare anche la fattispecie dell’incidente grave che incide sulla sicurezza del prodotto. Il paragrafo 5 dell’articolo 14 contempla condizioni relative, fra l’altro, alla capacità del prodotto di proteggere dati o funzioni sensibili o importanti e all’introduzione o esecuzione di codice malevolo nei contesti indicati dalla disposizione. Il fatto che non esista ancora una vulnerabilità pubblicamente identificata non esclude questa valutazione.
Anche qui sono previsti preallarme entro 24 ore e notifica entro 72 ore dalla conoscenza, senza indebito ritardo; cambia però il calendario della relazione finale, prevista entro un mese dalla notifica dell’incidente. Se l’incidente è ancora in corso, si applica il percorso del rapporto sullo stato di avanzamento e della relazione finale successiva alla gestione. Una procedura che riportasse indistintamente «14 giorni» per tutti i casi introdurrebbe un errore proprio nella fase conclusiva.
Contratti di filiera per rispettare gli obblighi di segnalazione CRA
Per riuscire a compiere queste verifiche, il fabbricante può aver bisogno di un avviso prima che il fornitore abbia concluso la propria indagine. Una clausola limitata a «ogni incidente grave del fornitore» potrebbe non comprendere la notizia rilevante: nei sistemi di quest’ultimo nessun servizio è fermo, ma il componente consegnato ai clienti contiene una vulnerabilità sfruttata altrove. Conviene descrivere i fatti da comunicare in relazione alla fornitura, con un canale urgente per i segnali pertinenti e aggiornamenti ordinari per ciò che non richiede lo stesso trattamento. La soglia contrattuale può servire ad anticipare il confronto; i presupposti della successiva segnalazione alle autorità restano quelli stabiliti dal CRA.
Tempi contrattuali e canali urgenti
Nel negoziare il tempo dell’avviso, riprodurre automaticamente il limite legale di 24 ore rischia di costruire una catena lenta. Ogni passaggio potrebbe attendere un giorno, mentre al destinatario finale rimarrebbe da identificare il componente nel proprio prodotto e valutarne le conseguenze. Questo non significa che la conoscenza del fornitore faccia sempre decorrere il termine del fabbricante: le posizioni vanno accertate separatamente. Significa che un termine contrattuale deve essere scelto tenendo conto del lavoro che il destinatario dovrà ancora compiere e della criticità della fornitura. Imporre una durata ambiziosa senza verificare come venga rispettata offrirebbe, al più, un argomento per una controversia successiva.
La verifica può partire dal recapito riportato nell’allegato di sicurezza. Se la casella è presidiata soltanto in orario d’ufficio e promette una risposta entro tre giorni lavorativi, il venerdì pomeriggio dell’esempio è già diventato un problema. Servono referenti sostituibili e una conferma di ricezione che dimostri la presa in carico, con un percorso ulteriore quando il primo contatto non risponde. La reperibilità richiesta dovrà essere commisurata al rischio e alle caratteristiche del rapporto; una promessa di assistenza continua deve però corrispondere a persone e procedure raggiungibili. Provare il canale con una comunicazione concordata consente di scoprire un numero obsoleto prima che il ritardo abbia conseguenze sulla notifica.
Informazioni minime, riservatezza e delega
Chi riceve l’avviso deve poter riconoscere la fornitura coinvolta. Il nome del componente e le versioni interessate, quando disponibili, permettono di collegare il messaggio all’inventario; le condizioni di esposizione orientano le verifiche sul prodotto. Per valutare l’attendibilità dello sfruttamento possono servire elementi ulteriori, ma esigere l’intero rapporto forense prima di accettare il primo avviso favorirebbe l’attesa.
È preferibile che il fornitore dichiari ciò che ancora manca e stabilisca come aggiornare il cliente. Se alcune prove contengono informazioni di terzi o dettagli che agevolerebbero altri attacchi, si può negoziare un accesso ristretto o una comunicazione selettiva, purché rimangano elementi sufficienti a sostenere la valutazione del fabbricante.
Lo stesso accordo dovrebbe evitare che la riservatezza blocchi le comunicazioni imposte dalla legge. Richiedere sempre il consenso preventivo del fornitore prima di contattare l’autorità gli attribuirebbe un potere incompatibile con la necessità del fabbricante di rispettare i propri termini. Si possono disciplinare il coordinamento e l’informazione della controparte, quando possibile, distinguendoli dall’autorizzazione a notificare. Anche un embargo sulla divulgazione pubblica della vulnerabilità ha una funzione diversa dalla segnalazione attraverso i canali previsti.
Se un soggetto incaricato cura materialmente la trasmissione, il fabbricante deve conoscere il contenuto inviato e disporre della ricevuta, oltre a poter gestire i successivi aggiornamenti. La delega operativa non trasferisce automaticamente gli obblighi pubblicistici; una manleva non rimedia all’informazione rimasta ferma nella filiera.
Dal reporting CRA alla gestione delle dipendenze
Queste clausole possono essere preparate insieme al lavoro sugli inventari e sulle dipendenze che sosterrà l’applicazione generale del CRA. Gli obblighi dell’articolo 13, secondo la scansione temporale prevista, riguardano anche la diligenza nell’integrazione dei componenti e la gestione delle vulnerabilità. È utile mantenere riconoscibile tale prospettiva quando si negozia oggi: alcune richieste danno attuazione al reporting già applicabile, altre preparano il prodotto e l’organizzazione alla fase successiva. Presentarle tutte come prescrizioni già imposte dall’articolo 14 renderebbe meno preciso il confronto e potrebbe far perdere di vista la ragione operativa della richiesta, ossia ricevere elementi sufficienti per valutare il proprio prodotto in tempo utile.
Segnalazioni CRA: dalla piattaforma ENISA agli avvisi agli utilizzatori
Una volta accertati i presupposti, la trasmissione deve poter avvenire senza scoprire all’ultimo momento un problema di accesso. La Single Reporting Platform di ENISA consente dal settembre 2026 l’invio delle segnalazioni obbligatorie CRA secondo il meccanismo previsto per il CSIRT designato come coordinatore ed ENISA. Verificare preventivamente account e rappresentanti incaricati evita che il lavoro tecnico si arresti davanti a un’autorizzazione mancante. Le ricevute e gli aggiornamenti andranno collegati al fascicolo del caso. Se lo stesso episodio presenta anche i presupposti di obblighi NIS2 o GDPR, questi richiedono una valutazione distinta: aver usato la piattaforma CRA non dimostra, da solo, di aver assolto ogni altra notifica.
Dalla patch del componente alla misura per il prodotto
Nel frattempo il fornitore potrebbe aver pubblicato una patch della libreria. Per il macchinario che la incorpora, quella disponibilità non significa necessariamente che l’utilizzatore possa già installare una misura correttiva. Il costruttore potrebbe doverla integrare e verificarne la compatibilità con funzioni dalle quali dipende il funzionamento dell’impianto. Deve quindi documentare quale misura sia messa a disposizione rispetto al proprio prodotto e quando, considerando anche le mitigazioni eventualmente praticabili. La questione incide sul termine della relazione finale relativa alla vulnerabilità e richiede un esame concreto; sarebbe altrettanto improprio ignorare una mitigazione già disponibile o far coincidere automaticamente il calendario del componente con quello del prodotto finale.
Se, nell’attesa dell’aggiornamento, si propone di disabilitare una funzione, il cliente deve sapere quali conseguenze avrà sul servizio e quale esposizione rimarrà. In un contesto industriale potrebbe essere necessaria una finestra di manutenzione, e la misura provvisoria dovrà essere valutata anche rispetto alla continuità e alla sicurezza del funzionamento. Un avviso che si limita a rinviare al bollettino della libreria lascia all’utilizzatore un collegamento che spesso non ha gli strumenti per compiere. Il fabbricante conosce il prodotto con il quale il cliente lavora e deve tradurre l’informazione tecnica in indicazioni applicabili a quella installazione, dichiarando le incertezze che impediscono ancora una risposta completa.
Informare gli utilizzatori interessati
L’articolo 14, paragrafo 8, prevede l’informazione senza indebito ritardo agli utilizzatori interessati e, ove opportuno, a tutti gli utilizzatori, sulla vulnerabilità attivamente sfruttata o sull’incidente grave e sulle misure pertinenti. Per un macchinario venduto anni prima, il recapito disponibile potrebbe appartenere al distributore originario o a una persona che ha cambiato lavoro. Occorre valutare come raggiungere chi lo usa attraverso i canali effettivamente disponibili, dall’assistenza agli avvisi associati alle versioni del prodotto. Non sempre sarà possibile ricostruire perfettamente ogni installazione; resta necessario esaminare quali destinatari siano stati raggiunti e quali alternative consentano di estendere la comunicazione.
Nel testo destinato al cliente il dettaglio tecnico deve aiutarlo a riconoscere la propria esposizione senza diffondere inutilmente istruzioni di sfruttamento. Se le versioni interessate cambiano dopo ulteriori verifiche, la rettifica deve arrivare a chi ha ricevuto il primo avviso.
Una volta gestito il caso, la cronologia permetterà inoltre di individuare dove si sia perso tempo: nel nome del componente, nella richiesta di chiarimento al subfornitore oppure nell’assenza di un referente autorizzato. Il contratto potrà essere corretto su quel punto e il nuovo passaggio potrà essere provato. Al successivo messaggio del venerdì, il destinatario dovrebbe almeno riuscire ad aprire l’inventario, trovare le versioni da esaminare e raggiungere chi sa valutarle, senza attendere che torni in ufficio la persona che aveva seguito l’acquisto.
Partecipa alla community