Ogni fabbricante soggetto al CRA ha bisogno di un processo vivo di gestione delle vulnerabilità per ogni prodotto: sapere cosa contiene il prodotto, trovare e correggere vulnerabilità, testare regolarmente, pubblicare advisory, ricevere segnalazioni esterne e consegnare aggiornamenti di sicurezza sicuri e gratuiti. Questa pagina spiega quel modello operativo e dove passa alla segnalazione regolatoria urgente.
Riepilogo
- La gestione delle vulnerabilità è un modello operativo di ingegneria che ogni fabbricante CRA deve avere per ogni prodotto con elementi digitali.
- Otto obblighi numerati: identificare (con SBOM), porre rimedio senza ritardo, testare regolarmente, divulgare pubblicamente le vulnerabilità corrette, applicare una policy CVD, facilitare la segnalazione delle vulnerabilità, distribuire gli aggiornamenti in modo sicuro, fornire gli aggiornamenti di sicurezza a titolo gratuito.
- La gratuità non è negoziabile: gli aggiornamenti di sicurezza sono gratuiti per impostazione predefinita, con una deroga stretta per i prodotti su misura forniti a utenti aziendali.
- La policy CVD è obbligatoria, non facoltativa: la divulgazione coordinata delle vulnerabilità fa parte della prontezza per la marcatura CE, non di una buona prassi volontaria.
- La gestione delle vulnerabilità si applica per l'intero periodo di supporto; il minimo è cinque anni dall'immissione sul mercato salvo che il periodo di uso previsto sia inferiore e dichiarato.
- La gestione delle vulnerabilità non è segnalazione regolatoria urgente: la gestione è il processo ingegneristico quotidiano; la segnalazione parte solo in caso di sfruttamento attivo o incidenti gravi.
I quattro pilastri che inquadrano la gestione delle vulnerabilità CRA: ambito, durata, regola di costo e massimale delle sanzioni.
Gli otto obblighi di gestione delle vulnerabilità
Il CRA non tratta la gestione delle vulnerabilità come una checklist una tantum. Si aspetta un ciclo continuo per l'intero periodo di supporto, dall'inventario dei componenti alla remediation, alla divulgazione e alla consegna sicura degli aggiornamenti. La tabella raggruppa gli otto obblighi legali per fase operativa.
| Fase | Punti | Cosa copre | Focus operativo |
|---|---|---|---|
| Rilevare e catalogareIntake e inventario | Punti 1 e 6 | Identificazione basata su SBOM dei componenti e delle vulnerabilità note, più un canale pubblico di segnalazione. | Tenere aggiornati i dati sui componenti e rendere semplice il contatto con il team di sicurezza prodotto. |
| Progettare e correggereRemediation e test | Punti 2 e 3 | Remediation senza ritardo e test regolari efficaci della codebase e delle sue dipendenze. | Usare la gravità per definire l'urgenza e conservare evidenza che correzioni e test siano avvenuti in tempo. |
| DistribuireCanale di aggiornamento sicuro | Punti 7 e 8 | Aggiornamenti di sicurezza firmati e autenticati, separabili dalle funzionalità e gratuiti salvo per prodotti B2B su misura. | Consegnare correzioni di sicurezza senza forzare gli utenti verso nuove funzionalità o livelli di manutenzione a pagamento. |
| Coordinare e divulgareCVD e advisory | Punti 4 e 5 | Una policy CVD applicata e advisory pubblici una volta disponibile la correzione. | Coordinare intake dei ricercatori, avvisi agli utenti e ritardi giustificati da un unico playbook. |
Cosa significa nella pratica ciascun obbligo
| # | Obbligo | Cosa richiede effettivamente |
|---|---|---|
| 1 | Identificare e documentare le vulnerabilità e i componenti | Uno SBOM in CycloneDX o SPDX, che copra almeno le dipendenze di primo livello. Lo SBOM è l'indice che rende possibile la corrispondenza con i CVE: non si può porre rimedio a ciò che non si è catalogato. |
| 2 | Porre rimedio senza ritardo, separatamente dalle funzionalità | Nessuno SLA fisso; la velocità attesa è proporzionata alla gravità. I rami di sicurezza devono essere separabili dai rami funzionali in modo che gli utenti non possano rinviare una patch rinviando una release. |
| 3 | Test regolari ed efficaci | Analisi statica, test dinamici, scansione delle dipendenze rispetto ai feed di vulnerabilità e penetration test. La "regolarità" deve essere proporzionata al rischio e al tasso di evoluzione della codebase. |
| 4 | Divulgazione pubblica delle vulnerabilità corrette | Una volta pubblicato il fix, pubblicare descrizione, prodotto interessato, impatto, gravità e rimedio. Ritardo solo "in casi debitamente giustificati" finché gli utenti non possono applicare la patch. CVE più CSAF è il vettore di fatto. |
| 5 | Policy di divulgazione coordinata delle vulnerabilità | Una policy CVD scritta e applicata con canale di intake, SLA di risposta e condizioni di divulgazione. ISO/IEC 29147 e 30111 forniscono un quadro formale. |
| 6 | Facilitare la segnalazione esterna delle vulnerabilità | Un indirizzo di contatto per segnalare problemi nel prodotto e nei suoi componenti di terze parti. security.txt ai sensi di RFC 9116 soddisfa il requisito del canale. |
| 7 | Distribuzione sicura degli aggiornamenti | Aggiornamenti firmati, autenticati, automatici ove applicabile. I prodotti senza un canale di aggiornamento devono crearne uno o documentare perché l'automazione non è applicabile. Si veda aggiornamenti di sicurezza. |
| 8 | Gratuiti, con messaggi di advisory | Gli aggiornamenti di sicurezza devono essere distribuiti senza ritardo e a titolo gratuito (unica deroga: prodotti su misura per utenti aziendali in cui le parti hanno concordato diversamente). Ogni aggiornamento deve essere accompagnato da un messaggio di advisory che descrive il problema e l'azione che l'utente deve intraprendere. Un gate a manutenzione a pagamento, o una patch silenziosa senza advisory, viola il punto 8. |
La gestione delle vulnerabilità e il periodo di supporto
La gestione delle vulnerabilità dura per l'intero periodo di supporto. Il minimo predefinito è di cinque anni dalla data di immissione sul mercato UE, salvo che il periodo di uso previsto sia inferiore e dichiarato. La data di fine supporto deve comparire nelle informazioni sul prodotto. Una volta terminato quel periodo, gli obblighi attivi di gestione decadono per quella versione del prodotto, ma la documentazione tecnica e la dichiarazione di conformità devono comunque essere conservate per 10 anni dall'immissione sul mercato o per il periodo di supporto, a seconda di quale sia più lungo. Si veda periodo di supporto CRA.
La gestione delle vulnerabilità non è segnalazione urgente
Il Regolamento sulla ciberresilienza distingue due obblighi che operano su superfici e con destinatari diversi:
- La gestione delle vulnerabilità è il processo ingegneristico: SBOM, remediation, policy CVD, divulgazione pubblica e aggiornamenti sicuri. Si applica a tutte le vulnerabilità per l'intero periodo di supporto e sta nell'organizzazione di sicurezza del prodotto del fabbricante.
- La segnalazione regolatoria urgente parte solo in presenza di una vulnerabilità attivamente sfruttata o di un incidente grave che incide sulla sicurezza del prodotto. È inviata attraverso la piattaforma di segnalazione unica ENISA con cadenza 24h / 72h, più un rapporto finale (14 giorni dopo la disponibilità di una misura correttiva o di mitigazione per una vulnerabilità attivamente sfruttata, oppure un mese dopo la notifica delle 72 ore per un incidente grave), a ENISA e al CSIRT designato come coordinatore. Per i meccanismi di onboarding all'SRP, si veda onboarding ENISA SRP.
Un team di prodotto può gestire un processo conforme di vulnerabilità senza presentare mai una segnalazione urgente, perché la maggior parte delle vulnerabilità viene corretta prima di essere attivamente sfruttata. La segnalazione parte solo quando la remediation non ha ancora raggiunto lo sfruttamento attivo o un incidente grave. Si veda segnalazione delle vulnerabilità CRA.
Esposizione a sanzioni
Le carenze nella gestione delle vulnerabilità possono comportare sanzioni amministrative rilevanti, ma il dettaglio dei livelli appartiene alla guida dedicata all'enforcement. Vedi sanzioni e applicazione del CRA per livelli di multa, trigger di enforcement e collocazione delle carenze di vulnerability handling nel modello complessivo.
Domande Frequenti
Lo SBOM deve coprire le dipendenze transitive?
Il minimo legale sono le dipendenze di primo livello, ma uno SBOM pratico di solito deve andare più in profondità. Non è possibile correggere senza ritardo un CVE in un componente transitivo che non si è mai catalogato. La maggior parte dei regolatori e dei clienti si attende uno SBOM profondo che segua BSI TR-03183 o linee guida comparabili. CycloneDX e SPDX sono entrambi qualificati come formati comunemente utilizzati e leggibili da macchina. Si vedano i requisiti SBOM CRA.
Cosa significa "senza ritardo" nella pratica per la remediation ai sensi del punto 2?
Il Regolamento sulla ciberresilienza non specifica uno SLA fisso di remediation. "Senza ritardo" è proporzionato al rischio di cibersicurezza: una vulnerabilità critica con sfruttamento attivo in circolazione richiede una correzione in pochi giorni, mentre un problema di bassa gravità può attendere il successivo ciclo regolare. La gravità è determinata con CVSS, affinata dai dati di probabilità di exploit EPSS e confermata dalle evidenze del catalogo CISA KEV nei casi in cui la vulnerabilità è nell'elenco di quelle attivamente sfruttate da CISA. Si veda valutazione della gravità per la scala operativa che le autorità di mercato applicano nel giudicare se un fabbricante abbia posto rimedio "senza ritardo".
Gli aggiornamenti di sicurezza possono essere addebitati in qualche circostanza?
Esiste un'unica deroga: i prodotti su misura forniti a un utente aziendale possono usare un accordo a pagamento se il fabbricante e l'utente aziendale hanno concordato diversamente. Per ogni altro prodotto, inclusi tutti i prodotti di consumo e ogni SaaS o hardware B2B standard, gli aggiornamenti di sicurezza devono essere gratuiti per l'intero periodo di supporto. Mettere una patch di sicurezza dietro a una fascia di manutenzione a pagamento espone il fabbricante alle sanzioni di primo livello.
Gli obblighi di gestione delle vulnerabilità proseguono dopo la fine del supporto?
No. Gli otto obblighi di gestione delle vulnerabilità decadono per quella versione di prodotto al termine del periodo di supporto. Le nuove vulnerabilità individuate dopo la fine del supporto non devono essere corrette per quella versione, a condizione che il fabbricante abbia pubblicato una chiara data di fine supporto affinché gli utenti possano migrare. Due obblighi proseguono comunque. La documentazione tecnica e la dichiarazione di conformità UE devono comunque essere conservate per 10 anni dall'immissione sul mercato o per il periodo di supporto, a seconda di quale sia più lungo. La segnalazione è distinta dalla gestione: se il fabbricante viene a conoscenza di una vulnerabilità sfruttata attivamente o di un incidente grave nel prodotto, l'obbligo di segnalazione dell'articolo 14 può comunque applicarsi, perché non è legato al periodo di supporto. Si vedano periodo di supporto e comunicazione di fine supporto.
Quando un intake CVD richiede una segnalazione urgente?
Il trigger è lo sfruttamento attivo, non una segnalazione privata né una prova di sfruttabilità. Una proof-of-concept funzionante allegata a una segnalazione CVD non è di per sé da segnalare; lo diventa quando esiste una ragionevole convinzione che un attore malevolo abbia usato la falla contro un obiettivo reale. Una volta superata tale soglia, parte l'allerta precoce di 24 ore a ENISA e al CSIRT coordinatore, seguita dalla notifica di 72 ore e da un rapporto finale entro 14 giorni dalla disponibilità di una misura correttiva. Si veda segnalazione delle vulnerabilità CRA.