Il Regolamento sulla ciberresilienza dell'UE (Regolamento (UE) 2024/2847) impone ai fabbricanti di gestire le vulnerabilità durante il periodo di supporto e, quando sono disponibili aggiornamenti di sicurezza, di diffonderli senza ritardo e a titolo gratuito. Questa pagina tratta i meccanismi di consegna degli aggiornamenti nelle architetture embedded, standalone, SaaS e ibride. Per la durata del supporto consulti le basi del periodo di supporto; per l'informativa pre-acquisto consulti la divulgazione della fine del supporto.
Sintesi
- Gli aggiornamenti di sicurezza non sono aggiornamenti funzionali. Una modifica che corregge una vulnerabilità segue gli obblighi sugli aggiornamenti di sicurezza; una nuova funzionalità no.
- Le correzioni di sicurezza non devono stare dietro piani a pagamento. Gli aggiornamenti di sicurezza disponibili dovrebbero essere diffusi senza ritardo e gratuitamente, con messaggi di advisory che informino gli utenti su cosa affronta l'aggiornamento e quali azioni intraprendere, salvo diverso accordo per prodotti su misura destinati a utenti aziendali.
- Automatici ove applicabile. Gli aggiornamenti automatici di sicurezza sono il modello predefinito quando hanno senso, con meccanismi di distribuzione sicuri e controlli utente chiari.
- Gli obiettivi di patch devono seguire la gravità. Gli obiettivi operativi usuali sono giorni per criticità attivamente sfruttate, 30 giorni per gravità alta, 90 giorni per media e il prossimo ciclo regolare per bassa.
- L'architettura cambia il modello di consegna. Firmware embedded, software standalone, SaaS e prodotti ibridi hanno meccanismi distinti che la documentazione tecnica deve descrivere.
- La segnalazione interagisce con il ciclo di aggiornamento. Quando viene rilevata una vulnerabilità attivamente sfruttata, l'allerta precoce a 24 ore al CSIRT coordinatore e a ENISA corre in parallelo al processo di patch; il meccanismo di aggiornamento deve alimentare il flusso di segnalazione.
I quattro ancoraggi della conformità CRA per gli aggiornamenti di sicurezza: costo, distribuzione, disponibilità dell'aggiornamento e massimale sanzionatorio.
Per i livelli sanzionatori, consulti la guida a sanzioni ed enforcement.
Cosa costituisce un aggiornamento di sicurezza
L’obbligo di aggiornamento parte dalla valutazione del rischio di cibersicurezza del prodotto e dalle proprietà di sicurezza applicabili. Configurazione sicura predefinita, riservatezza, integrità e disponibilità determinano se una modifica è rilevante per la sicurezza. Il fabbricante deve poi gestire efficacemente le vulnerabilità durante il periodo di supporto.
Un aggiornamento di sicurezza è una modifica che corregge una vulnerabilità, cioè una debolezza del prodotto sfruttabile per compromettere riservatezza, integrità o disponibilità. La distinzione da un aggiornamento funzionale conta per due ragioni: gli aggiornamenti di sicurezza disponibili devono essere gratuiti e diffusi senza ritardo; gli aggiornamenti funzionali non hanno questi obblighi.
| Tipo di aggiornamento | Obbligo di aggiornamento di sicurezza | Può essere addebitato? |
|---|---|---|
| Patch che corregge un CVE noto | Sì (aggiornamento di sicurezza) | No |
| Modifica di hardening che riduce la superficie di attacco | Sì (aggiornamento di sicurezza) | No |
| Nuova funzionalità senza rilievo di sicurezza | No | Sì |
| Versione principale con nuove capacità | No (salvo che includa correzioni di sicurezza) | Sì |
| Aggiornamento di dipendenza per eliminare una vulnerabilità nota | Sì (aggiornamento di sicurezza) | No |
| Modifica di configurazione per chiudere una lacuna di sicurezza | Sì (aggiornamento di sicurezza) | No |
Senza ritardo non è definito numericamente nel Regolamento. I fabbricanti devono comunque fissare obiettivi operativi basati sulla gravità, così che le decisioni di patch siano coerenti, documentate e spiegabili. Il diagramma mostra una finestra pratica di patch per gravità, misurata dal momento in cui il fabbricante viene a conoscenza della vulnerabilità:
| Gravità | Obiettivo operativo pratico |
|---|---|
| Critica (attivamente sfruttata) | Giorni, non settimane |
| Alta (facilmente sfruttabile da remoto) | Entro 30 giorni |
| Media | Entro 90 giorni |
| Bassa | Nel prossimo ciclo regolare |
Non sono scadenze imposte dal CRA. Sono obiettivi interni che aiutano il fabbricante a dimostrare che il ritardo è stato controllato, basato sul rischio e documentato.
Come consegnare gli aggiornamenti di sicurezza CRA
Aggiornamenti automatici
Dove tecnicamente possibile e appropriato, gli aggiornamenti automatici di sicurezza sono il modello preferito. Un modello automatico conforme dovrebbe abilitare gli aggiornamenti di sicurezza per impostazione predefinita, offrire un chiaro meccanismo di opt-out, notificare gli aggiornamenti disponibili, consentire il rinvio temporaneo dove appropriato e distribuire gli aggiornamenti in modo sicuro.
Un meccanismo di aggiornamento automatico efficace dovrebbe prevedere:
- Canale di download sicuro (TLS, pacchetti firmati)
- Verifica dell'integrità prima dell'installazione
- Possibilità di rollback se l'aggiornamento fallisce
- Gestione corretta dei problemi di connettività
- Visibilità dello stato di aggiornamento per l'utente
L'utente deve conservare la possibilità di disattivare gli aggiornamenti automatici, con un avviso chiaro sulle conseguenze di sicurezza. Per aggiornamenti critici, il fabbricante deve documentare ogni scelta non rinviabile nella valutazione del rischio e nella documentazione tecnica.
Aggiornamenti manuali
I prodotti che non possono ricevere aggiornamenti automatici (sistemi industriali isolati, dispositivi embedded senza connettività, alcuni dispositivi medici o apparecchiature critiche per la sicurezza) richiedono un processo manuale:
- Pacchetti scaricabili con versionamento chiaro
- Firme crittografiche e chiavi pubbliche pubblicate per la verifica
- Documentazione di installazione
- Notifica tramite tutti i canali disponibili (e-mail, portale web, interfaccia del prodotto, avviso fisico se necessario)
Embedded e SaaS: modelli di aggiornamento diversi
Il meccanismo di consegna cambia molto in base all'architettura:
| Tipo di prodotto | Modello di aggiornamento | Considerazione CRA chiave |
|---|---|---|
| Firmware embedded (IoT, industriale) | Il fabbricante rilascia firmware firmato; il cliente lo applica | Serve OTA o processo manuale documentato; cicli di vita lunghi possono richiedere supporto oltre cinque anni |
| Software standalone (desktop, server) | Il fabbricante pubblica un pacchetto; il cliente lo installa | Preferibile un agente di aggiornamento automatico; il version pinning aziendale crea carico di supporto multiversione |
| SaaS / cloud-hosted | Il fabbricante controlla l'ambiente; gli aggiornamenti sono trasparenti | Verificare prima se il servizio rientra come prodotto con elementi digitali o soluzione di trattamento dati da remoto |
| Ibrido (agente on-premises + backend cloud) | Gli aggiornamenti dell'agente sono controllati dal fabbricante; il backend è trasparente | Ogni componente ha il proprio periodo di supporto; l'agente è il prodotto con elementi digitali che governa l'orologio |
Per la gestione più ampia delle vulnerabilità oltre alla consegna degli aggiornamenti (policy CVD, divulgazione pubblica, segnalazione a terzi), consulti la guida alla gestione delle vulnerabilità.
Obblighi di segnalazione durante la consegna degli aggiornamenti
La segnalazione CRA impone obblighi a termine per vulnerabilità sfruttate attivamente e incidenti gravi che incidono sulla sicurezza del prodotto. Il processo di aggiornamento dovrebbe raccogliere i fatti necessari a tali segnalazioni, perché il rapporto finale deve includere i dettagli dell’aggiornamento di sicurezza o delle altre misure correttive disponibili.
L'interazione operativa è questa:
| Attivatore | Dovere nel flusso di aggiornamento |
|---|---|
| Vulnerabilità attivamente sfruttata | Registrare ora di conoscenza, prodotti interessati, fatti di sfruttamento, stato di mitigazione e dettagli dell'aggiornamento per la sequenza 24 ore, 72 ore e rapporto finale. |
| Incidente grave | Registrare impatto, possibile causa illecita o malevola, valutazione iniziale, misure di mitigazione e azioni correttive per gli utenti. |
| Informazione agli utenti | Preparare istruzioni chiare di mitigazione e correzione per gli utenti impattati e, ove opportuno, tutti gli utenti. |
Non tratti la segnalazione come un passaggio separato a valle. Le informazioni da supporto, PSIRT, telemetria, assistenza clienti o deployment devono arrivare rapidamente al responsabile della segnalazione quando può essere raggiunta una soglia notificabile.
Per la meccanica completa delle scadenze, incluso ciò che ogni segnalazione deve contenere e come differiscono i due flussi, consulti la guida alla segnalazione delle vulnerabilità.
Disponibilità degli aggiornamenti dopo il rilascio
Rendere disponibile una patch una sola volta non basta. Ogni aggiornamento di sicurezza messo a disposizione degli utenti durante il periodo di supporto deve restare disponibile per almeno 10 anni dal rilascio, o per il resto del periodo di supporto se più lungo. Questo cambia le operazioni di release: vecchi pacchetti, avvisi, firme, hash e istruzioni di installazione richiedono hosting durevole e tracciabilità delle versioni.
Le informazioni pubbliche per gli utenti devono anche indicare quale supporto tecnico di sicurezza è offerto e la data di fine del periodo di supporto durante cui possono aspettarsi gestione delle vulnerabilità e aggiornamenti. Per il modello di divulgazione pre-acquisto, consulti divulgazione di fine supporto.
Errori comuni
Ignorare le dipendenze transitive. La maggior parte delle vulnerabilità nei prodotti connessi deriva da librerie e componenti di terzi, non dal codice interno. L'obbligo di gestione delle vulnerabilità copre l'intero prodotto, componenti inclusi. L'SBOM è il prerequisito. Consulti la guida al cluster SBOM per il quadro di monitoraggio delle dipendenze.
Addebitare gli aggiornamenti di sicurezza. Inserire correzioni di sicurezza in un livello di supporto a pagamento è in conflitto con il modello di aggiornamento CRA di base, salvo l’eccezione per prodotti aziendali su misura. Le patch di sicurezza di base devono essere gratuite.
Domande frequenti
Gli aggiornamenti di sicurezza devono essere sempre gratuiti?
Sì, gli aggiornamenti di sicurezza disponibili devono essere gratuiti salvo la stretta eccezione per prodotti commerciali su misura. Un fabbricante non può inserire una correzione di vulnerabilità in un abbonamento a pagamento, un livello premium o un aggiornamento maggiore a pagamento e trattarlo come normale conformità CRA. Aggiornamenti funzionali, nuove funzionalità e servizi professionali possono essere addebitati separatamente. La linea è se la modifica corregge un problema di sicurezza identificato nel prodotto.
Quanto rapidamente un fabbricante deve rilasciare un aggiornamento di sicurezza ai sensi del CRA?
Il CRA non fissa una scadenza numerica per la patch. I fabbricanti hanno quindi bisogno di obiettivi documentati per gravità. Le vulnerabilità critiche attivamente sfruttate devono essere trattate in giorni, quelle ad alta gravità in circa 30 giorni, quelle medie in circa 90 giorni e quelle basse nel prossimo ciclo regolare, salvo diversa giustificazione nella valutazione del rischio. Tracci il tempo effettivo fino alla patch per vulnerabilità, così che il ritardo sia visibile, basato sul rischio e spiegabile.
Il CRA richiede aggiornamenti automatici?
Non in tutti i casi. Gli aggiornamenti automatici di sicurezza sono richiesti ove applicabile, e il prodotto deve anche notificare gli aggiornamenti disponibili e permettere un rinvio temporaneo. Per prodotti consumer con connettività affidabile, sono di solito il modello atteso. Per sistemi industriali isolati, alcuni dispositivi medici o apparecchiature critiche, un processo manuale documentato può essere giustificato. La documentazione tecnica deve spiegare l'approccio scelto e le istruzioni utente devono spiegare come disattivare l'installazione automatica.
Un prodotto SaaS ha un periodo di supporto CRA?
Dipende dal fatto che il servizio rientri nell'ambito come prodotto con elementi digitali o soluzione di trattamento dati da remoto. Un SaaS puro e autonomo, non legato a hardware, software scaricabile o trattamento remoto sotto responsabilità del fabbricante, è generalmente fuori da questo modello di aggiornamento. Se l'offerta include un agente on-premises, un client scaricabile, un gateway hardware o trattamento remoto coperto, mappi il periodo di supporto e il meccanismo di aggiornamento del componente in ambito. Le informazioni utente devono comunque includere tipo di supporto e data di fine.
Cosa accade agli aggiornamenti di sicurezza dopo la fine del periodo di supporto CRA?
L'obbligo ordinario di gestione delle vulnerabilità è legato al periodo di supporto, ma gli aggiornamenti già rilasciati devono restare disponibili. Ogni aggiornamento di sicurezza messo a disposizione durante il periodo di supporto deve restare disponibile per almeno 10 anni dal rilascio o per il resto del periodo di supporto, se più lungo. I fabbricanti devono comunicare in anticipo la fine del supporto e mantenere disponibili le istruzioni utente per il periodo richiesto. Eviti di affermare che la segnalazione può essere ignorata dopo la fine del supporto senza una verifica legale caso per caso.