Cyber Resilience Act: una vulnerabilità non è più un ticket di assistenza

Dall’11 settembre 2026 si applicano gli obblighi di notifica previsti dall’articolo 14 del regolamento (UE) 2024/2847, il Cyber Resilience Act. Non è ancora la piena applicazione del regolamento, che arriverà più avanti, ma per chi immette sul mercato prodotti con elementi digitali è finita la stagione in cui una vulnerabilità si gestiva soltanto come ticket interno.

La regola, ridotta all’osso: quando una vulnerabilità del proprio prodotto è attivamente sfruttata, il fabbricante deve trasmettere un primo avviso senza indebito ritardo e comunque entro 24 ore da quando ne viene a conoscenza. Tempi analoghi valgono per gli incidenti gravi che incidono sulla sicurezza del prodotto. Il destinatario non è il cliente che urla più forte, né il commerciale di riferimento: la segnalazione passa dal CSIRT designato come coordinatore e da ENISA, attraverso la piattaforma europea di notifica.

Per una software house italiana il punto non è imparare a compilare un modulo nuovo. È avere la capacità di capire, nel giro di poche ore, se quello che è arrivato all’assistenza è un malfunzionamento, un tentativo di attacco o una vulnerabilità già sfruttata. Chi non ce l’ha non ha soltanto un problema di conformità: ha un prodotto che può essere compromesso più in fretta di quanto l’azienda riesca ad accorgersene. La buona notizia è che questa capacità si costruisce mettendo in ordine poche cose, non aprendo un reparto nuovo.

1. Non riguarda solo chi vende dispositivi

L’espressione «prodotti con elementi digitali» fa pensare subito a router, telecamere, macchinari connessi, IoT. Il perimetro è più largo: comprende hardware e software messi a disposizione sul mercato dell’Unione nell’ambito di un’attività commerciale. Un gestionale installabile, un’applicazione desktop, un plugin, un firmware o una libreria venduta a terzi possono rientrarci.

Il SaaS puro non diventa automaticamente un prodotto per effetto del CRA. Il regolamento però tira dentro le soluzioni di elaborazione remota dei dati quando sono parte integrante del prodotto e senza di esse il prodotto non svolgerebbe una delle sue funzioni. Nelle architetture di oggi il confine non è teorico: autenticazione, motore di calcolo, aggiornamenti e telemetria dipendono spesso da servizi remoti gestiti dallo stesso produttore.

Conta poi chi veste i panni del fabbricante, e non serve avere una fabbrica. Lo è l’impresa che sviluppa — o fa sviluppare — un prodotto e lo commercializza con il proprio nome o marchio. Anche la PMI che rivende a proprio brand una soluzione realizzata da terzi deve quindi leggere con attenzione ruoli, responsabilità e flussi di segnalazione: il contratto di sviluppo non trasferisce da solo al fornitore gli obblighi legati al prodotto immesso sul mercato.

Discorso a parte per il software libero e open source sviluppato o fornito al di fuori di un’attività commerciale, per cui il regolamento prevede una disciplina dedicata, compresa la figura dell’open source steward. Attenzione però a un equivoco comune: usare una dipendenza open source non rende open source il prodotto commerciale che la incorpora, e non esonera dal sapere cosa si sta distribuendo.

2. Le prime 24 ore servono a segnalare, non a risolvere

L’articolo 14 tiene distinte due cose: la notifica di una vulnerabilità attivamente sfruttata e la notifica di un incidente grave che incide sulla sicurezza del prodotto. Non chiede di segnalare ogni bug o ogni CVE che compare in una dipendenza. Chiede di riconoscere gli eventi che superano la soglia e di attivare in fretta il canale giusto.

Per le vulnerabilità attivamente sfruttate la scansione è questa: primo avviso entro 24 ore dalla conoscenza, notifica più completa entro 72 ore con quello che si sa sulla vulnerabilità, sulla natura dello sfruttamento e sulle misure adottate, rapporto finale entro quattordici giorni da quando è disponibile una misura correttiva o di mitigazione. Per gli incidenti gravi, dopo primo avviso e notifica a 72 ore, il rapporto finale arriva entro un mese dalla notifica.

Questa gradualità smonta un equivoco diffuso. Nelle prime 24 ore non serve avere la root cause definitiva, la patch testata su tutte le versioni e l’elenco completo dei clienti coinvolti. Serve aver riconosciuto l’evento, averlo classificato in modo ragionevole e aver raccolto abbastanza informazioni per un primo avviso attendibile. Aspettare la certezza assoluta è il modo più comune per sforare la finestra.

Il rischio opposto è notificare qualunque anomalia per prudenza, scaricando sul regolatore l’incapacità di fare triage in casa. Anche quello è un processo debole. Servono criteri tecnici, responsabilità chiare e qualche fonte informativa affidabile per distinguere una segnalazione credibile da un falso positivo, senza trasformare ogni ticket in una crisi.

3. Il punto critico è quando l’azienda «ne viene a conoscenza»

In una multinazionale ci sono un SOC, un PSIRT e un ufficio legale abituato alle notifiche. In una software house da trenta persone la prima evidenza arriva a uno sviluppatore su GitHub, al commerciale via WhatsApp o al primo livello di supporto con oggetto «il programma fa cose strane». Le 24 ore non aspettano che il messaggio raggiunga spontaneamente l’amministratore delegato.

La conoscenza dell’evento è organizzativa, non coincide con la lettura formale da parte di un dirigente. Se un canale aziendale riceve elementi credibili e nessuno li inoltra, il problema è il processo, non il calendario. Per questo la prima mossa concreta non è comprare una piattaforma: è decidere dove confluiscono le segnalazioni di sicurezza e chi ha il potere di far partire la valutazione.

Un PSIRT minimo è alla portata di una PMI. Non richiede dieci persone in turno h24. Richiede cinque elementi, collegati tra loro:

• un canale pubblicato per le segnalazioni di sicurezza, distinto dall’assistenza ordinaria ma agganciato al ticketing;
• un responsabile reperibile e un sostituto, con l’autorità per tirare dentro sviluppo, infrastruttura e direzione;
• criteri di triage che distinguano bug, vulnerabilità, sfruttamento attivo e incidente sul prodotto;
• un inventario delle versioni distribuite, delle dipendenze critiche e dei clienti potenzialmente coinvolti;
• una procedura già scritta per raccogliere le informazioni e trasmettere la notifica sul canale previsto.

La parte scomoda è l’inventario. Molte software house sanno benissimo quale versione stanno sviluppando, molto meno quali versioni girano ancora dai clienti. E spesso non sanno quali librerie fossero incluse nelle release vecchie, soprattutto se le build non sono riproducibili o le dipendenze venivano scaricate al volo. In quelle condizioni stabilire l’impatto di una vulnerabilità diventa un lavoro di archeologia, proprio mentre il cronometro corre. Vale la pena affrontarlo adesso, a freddo: una build riproducibile e una distinta delle componenti sono lavoro tecnico ordinario, non un progetto di compliance.

4. Una patch non serve, se non sapete a chi consegnarla

Il Cyber Resilience Act mette la notifica dentro un sistema più ampio di gestione delle vulnerabilità. L’allegato I del regolamento si occupa anche di correzioni di sicurezza, trattamento delle vulnerabilità, informazioni sulle componenti e distribuzione degli aggiornamenti. Il senso industriale è chiaro: non si può notificare seriamente nulla se il ciclo di vita del prodotto finisce con l’emissione della fattura.

Una PMI non deve copiare i processi di un produttore globale. Deve però sapere quali prodotti supporta, fino a quando e con quali modalità. Se un cliente usa una release di sei anni fa, quella vulnerabilità viene corretta? Esiste un aggiornamento compatibile? L’upgrade è a pagamento? E la comunicazione arriva anche se il referente originario ha cambiato azienda?

Qui si nasconde una forma di lock-in di cui si parla poco. Un prodotto aggiornabile soltanto attraverso un’infrastruttura proprietaria e non documentata sembra comodo finché il produttore è in salute; diventa fragile durante un’acquisizione, una cessazione di attività o un contenzioso. La sicurezza del cliente finisce per dipendere non dal codice, ma dalla continuità commerciale del fornitore.

Dal lato del produttore, conviene separare almeno logicamente il processo di sicurezza dalla relazione commerciale. Un cliente in ritardo con il rinnovo non può diventare invisibile quando c’è da comunicargli una vulnerabilità che lo espone. Anagrafiche, contratti e portali di aggiornamento devono riflettere questa distinzione.

Conta anche come si comunica. Il regolamento chiede che gli utenti interessati siano informati, quando serve, sulla vulnerabilità o sull’incidente e sulle misure che possono adottare. Un bollettino che dice solo «aggiornate all’ultima versione» non basta: servono versioni coinvolte, gravità, mitigazioni temporanee e possibili effetti collaterali dell’installazione.

5. Chi compra software deve verificare il processo, non il bollino

Il CRA riguarda i produttori, ma cambia anche il modo in cui una PMI dovrebbe scegliere il software che usa. Un fornitore che non sa spiegare come riceve una segnalazione, chi valuta una vulnerabilità e come distribuisce gli aggiornamenti sta esponendo un rischio di supply chain. Non serve aspettare una gara strutturata: le domande stanno benissimo nel prossimo rinnovo o nella prossima demo tecnica.

La domanda inutile è «siete conformi al Cyber Resilience Act?», perché invita a una risposta commerciale. Meglio chiedere dov’è pubblicato il canale per segnalare una vulnerabilità, per quanto tempo è supportata la release acquistata e come vengono comunicati gli aggiornamenti urgenti. Una verifica ancora più concreta: chiedere il bollettino di sicurezza di una vulnerabilità passata, anche anonimizzato. Se non esiste alcun esempio, può darsi che il fornitore non abbia mai avuto vulnerabilità; più probabilmente non le ha mai gestite con un processo visibile.

Per le PMI soggette alla NIS2, o inserite nella catena di fornitura di un soggetto NIS2, c’è una ragione in più: la direttiva (UE) 2022/2555 mette esplicitamente la sicurezza della catena di approvvigionamento e il trattamento delle vulnerabilità tra le misure di gestione del rischio. Un software critico fornito senza supporto tracciabile rende difficile dimostrare che quel rischio sia stato valutato.

Il contratto, di conseguenza, dovrebbe dire tempi e canali per le comunicazioni di sicurezza, disponibilità degli aggiornamenti, versioni supportate e modalità di cooperazione durante un incidente. Non serve trasformare ogni licenza in un trattato: bastano clausole leggibili e coerenti con come funziona davvero il prodotto. Una promessa di assistenza «best effort» vale poco se alle tre del mattino nessuno sa chi deve rispondere.

6. Una filiera corta della risposta

La tentazione sarà comprare un pacchetto «CRA compliance» e considerare la pratica chiusa. Nessun template, però, ricostruisce le dipendenze di una release vecchia, decide se una segnalazione è credibile o rintraccia i clienti che usano una componente vulnerabile. Il regolamento obbliga a far parlare tra loro sviluppo, assistenza, infrastruttura e direzione: è quella relazione che deve funzionare entro 24 ore.

Una software house piccola può farsi affiancare da un system integrator o da un operatore di cybersecurity italiano per organizzare reperibilità, triage, raccolta delle evidenze e supporto alle notifiche. Rispetto alla costruzione immediata di un SOC interno è spesso la strada più realistica, e in Italia esistono realtà dimensionate su aziende da venti o cinquanta persone, che parlano la stessa lingua e rispondono al telefono. La condizione è una sola: il fornitore esterno deve conoscere prodotti, versioni e referenti prima dell’incidente. Un numero da chiamare senza contesto non è un PSIRT in outsourcing.

Il modo più economico per capire a che punto siete è un’esercitazione da mezza giornata. Si prende una dipendenza realmente usata, si ipotizza che sia sotto sfruttamento attivo e si cronometra quanto serve per individuare prodotti coinvolti, versioni distribuite e clienti raggiungibili. Se dopo quattro ore si sta ancora cercando il file delle dipendenze o discutendo chi può autorizzare una comunicazione, il problema è emerso senza che sia servito un attacco vero — ed è esattamente il momento migliore per scoprirlo.

Il Cyber Resilience Act non elimina le vulnerabilità e non trasforma ogni software house in un’agenzia di sicurezza. Fissa una soglia industriale ragionevole: chi vende un prodotto digitale deve sapere cosa contiene, ascoltare chi ne segnala i difetti e reagire quando quei difetti vengono sfruttati. Dall’11 settembre non è più solo buona pratica, è una funzione operativa che clienti e regolatore possono legittimamente aspettarsi. Per chi la mette in piedi prima degli altri, tra l’altro, è anche un argomento di vendita.