Un ricercatore segnala un difetto in un prodotto. La segnalazione contiene una descrizione tecnica e una dimostrazione. Un secondo messaggio parla invece di attacchi osservati contro sistemi reali. È un esempio ipotetico: le due comunicazioni possono richiedere attenzione immediata, ma non descrivono necessariamente lo stesso presupposto giuridico.
Nel Cyber Resilience Act conviene tenere distinti la vulnerabilità, le informazioni sul suo sfruttamento e la decisione sulla notifica. Confonderli può produrre sia allarmi generici sia ritardi nella valutazione di informazioni decisive.
Il punto di partenza oggi
La Commissione europea ricorda che, dall’11 settembre 2026, gli obblighi di segnalazione dell’articolo 14 riguardano i fabbricanti per vulnerabilità attivamente sfruttate e incidenti gravi che incidono sulla sicurezza dei prodotti con elementi digitali. Il percorso per gli incidenti è distinto e non va escluso solo perché manca una vulnerabilità nota. Commissione europea.
Nella spiegazione ufficiale del NCSC irlandese, la categoria delle vulnerabilità attivamente sfruttate richiede evidenze affidabili di sfruttamento malevolo. Non basta quindi trattare ogni informazione tecnica come se attestasse automaticamente un attacco. Questa distinzione non autorizza a ignorare una segnalazione: impone di capirne il contenuto. NCSC.
Una dimostrazione e un attacco rispondono a domande diverse
Una dimostrazione può aiutare a riprodurre un difetto. La domanda sullo sfruttamento richiede invece di esaminare ciò che viene riferito, le fonti e la relazione con il prodotto interessato. È una distinzione operativa proposta qui, non una procedura di certificazione.
Per esempio, un gruppo di lavoro potrebbe registrare separatamente il prodotto e le versioni coinvolte, ciò che è stato verificato, le informazioni ancora da confermare e chi deve valutarle. Il campo dedicato allo sfruttamento non dovrebbe essere riempito automaticamente copiando il livello di gravità della vulnerabilità: sono valutazioni differenti.
ENISA presenta identificazione, coordinamento delle vulnerabilità e segnalazioni CRA come servizi collegati ma distinti. La piattaforma SRP serve alle notifiche previste dal CRA; la divulgazione coordinata riguarda anche la cooperazione nella gestione delle vulnerabilità. ENISA.
Gestire l’incertezza senza usarla per aspettare
La mia proposta organizzativa è assegnare un responsabile alla valutazione e rendere visibili i passaggi: ricezione, verifiche, nuove informazioni ed escalation. Una classificazione iniziale deve poter cambiare quando arrivano elementi ulteriori. Scrivere “in analisi” senza indicare chi farà il prossimo controllo lascia una casella aperta, non una decisione gestita.
I tempi normativi non vanno trasformati in un’attesa fino alla diagnosi completa. La Commissione indica una prima segnalazione entro 24 ore dalla conoscenza del presupposto rilevante e una notifica successiva entro 72 ore. Qui non si ricostruiscono tutti i contenuti delle fasi, né si valuta un caso concreto. Obblighi di segnalazione.
Il risultato utile è una traccia che permetta di capire quali informazioni erano disponibili e come sono state valutate. Ricevere una vulnerabilità, gestirla tecnicamente e decidere una notifica sono attività che devono parlarsi, mantenendo visibili le rispettive domande.
La precisione della classificazione serve a indirizzare il lavoro. Non deve diventare un motivo per rinviare una decisione che le evidenze già disponibili consentono, o richiedono, di affrontare.