L'allegato I parte II del Regolamento (UE) 2024/2847 stabilisce otto obblighi numerati che ogni fabbricante di un prodotto con elementi digitali deve applicare per l'intero periodo di supporto: identificazione ancorata allo SBOM, remediation senza ritardo, test regolari, divulgazione pubblica delle correzioni, una policy di divulgazione coordinata delle vulnerabilità, un canale esterno di segnalazione, distribuzione sicura degli aggiornamenti e aggiornamenti di sicurezza a titolo gratuito. Questa pagina illustra ciascun obbligo e mostra dove finisce la gestione ai sensi dell'allegato I e dove comincia la segnalazione ai sensi dell'articolo 14.
Riepilogo
- L'allegato I parte II è la specifica ingegneristica per la gestione delle vulnerabilità ai sensi del Regolamento sulla ciberresilienza, applicabile a ogni fabbricante 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 devono essere forniti gratuitamente ai sensi dell'allegato I parte II punto 8, con l'unica deroga per i prodotti su misura destinati a utenti aziendali.
- La policy CVD è obbligatoria, non facoltativa: l'allegato I parte II punto 5 rende la divulgazione coordinata delle vulnerabilità un obbligo per la marcatura CE, non una buona prassi.
- La gestione delle vulnerabilità si applica per l'intero periodo di supporto definito dall'articolo 3(20) e dall'articolo 13(8); il minimo è di cinque anni dall'immissione sul mercato.
- La gestione delle vulnerabilità non è la segnalazione ai sensi dell'articolo 14: la gestione è il processo ingegneristico quotidiano; la segnalazione è la cadenza 24h/72h/14g attivata solo da vulnerabilità attivamente sfruttate o da incidenti gravi (si veda segnalazione ai sensi dell'articolo 14 del CRA).
I quattro pilastri che inquadrano la gestione delle vulnerabilità CRA: ambito, durata, regola di costo e massimale delle sanzioni.
Gli otto obblighi dell'allegato I parte II
L'allegato I parte II del Regolamento (UE) 2024/2847 elenca otto obblighi numerati. Non sono una checklist: descrivono un ciclo di vita continuo che si svolge per l'intero periodo di supporto. Il raggruppamento seguente li organizza in base alla fase operativa in cui ciascuno si svolge.
Punti 1, 6. Identificazione basata su SBOM dei componenti e delle vulnerabilità note, oltre a un canale di contatto pubblico che consenta a soggetti esterni di segnalare ciò che gli scanner non hanno rilevato.
Punti 2, 3. Remediation senza ritardo (proporzionata alla gravità, non un SLA fisso) e test regolari ed efficaci della codebase e delle sue dipendenze.
Punti 7, 8. Canale di aggiornamento sicuro (firmato, autenticato, automatico ove applicabile), con aggiornamenti di sicurezza separabili dalle funzionalità e gratuiti, salvo per i prodotti su misura B2B.
Punti 4, 5. Una policy di divulgazione coordinata delle vulnerabilità istituita e applicata, oltre ad advisory pubblici una volta disponibile la correzione, con una stretta deroga per i casi "debitamente giustificati".
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
I requisiti dell'allegato I parte II si applicano per l'intero periodo di supporto definito dall'articolo 3(20) e richiesto dall'articolo 13(8). Il periodo di supporto è di almeno cinque anni dalla data in cui il prodotto è immesso sul mercato UE, o il periodo di uso atteso del prodotto se inferiore e dichiarato. La data di fine del periodo di supporto deve comparire nelle informazioni sul prodotto ai sensi dell'allegato II. Una volta terminato il periodo di supporto, gli obblighi dell'allegato I parte II decadono per quella versione del prodotto, ma l'obbligo di conservazione della documentazione ai sensi dell'articolo 31 (dieci anni dall'immissione sul mercato) prosegue. Si veda periodo di supporto CRA.
La gestione delle vulnerabilità non è la segnalazione ai sensi dell'articolo 14
Il Regolamento sulla ciberresilienza distingue due obblighi che operano su superfici e con destinatari diversi:
- La gestione delle vulnerabilità ai sensi dell'allegato I parte II è il processo ingegneristico: SBOM, remediation, policy CVD, divulgazione pubblica, aggiornamenti sicuri. Si applica a tutte le vulnerabilità, sempre, per l'intero periodo di supporto. È erogata attraverso l'organizzazione di sicurezza del prodotto del fabbricante.
- La segnalazione ai sensi dell'articolo 14 è la notifica regolatoria attivata da una vulnerabilità attivamente sfruttata (articolo 3(42)) o da un incidente grave che incide sulla sicurezza del prodotto. È erogata attraverso la piattaforma di segnalazione unica ENISA con cadenza 24h / 72h / 14g 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ò essere pienamente conforme all'allegato I parte II senza presentare mai una segnalazione ai sensi dell'articolo 14, perché la maggior parte delle vulnerabilità viene corretta prima di essere attivamente sfruttata. L'articolo 14 si attiva solo quando la remediation non ha ancora raggiunto lo sfruttamento attivo. Si veda segnalazione ai sensi dell'articolo 14 del CRA.
Sanzioni in caso di violazione
L'inosservanza dei requisiti essenziali dell'allegato I, inclusa la gestione delle vulnerabilità ai sensi della parte II, ricade nella fascia massima delle sanzioni amministrative ai sensi dell'articolo 64(2): fino a 15.000.000 EUR o al 2,5% del fatturato mondiale annuo totale, a seconda di quale sia maggiore. L'obbligo si applica dall'11 dicembre 2027 per i prodotti immessi sul mercato a partire da quella data.
Domande Frequenti
Lo SBOM ai sensi dell'allegato I parte II punto 1 deve coprire le dipendenze transitive?
Il testo letterale richiede "almeno le dipendenze di primo livello", che è il minimo regolatorio. I componenti transitivi non sono imposti dal punto 1, ma lo sono nella pratica dal punto 2: non è possibile "affrontare e correggere le vulnerabilità senza ritardo" per 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: l'allegato I parte II punto 8 consente un accordo a pagamento per i prodotti su misura forniti a un utente aziendale qualora il fabbricante e l'utente aziendale abbiano 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 è una violazione diretta del punto 8 ed espone il fabbricante alle sanzioni di primo livello ai sensi dell'articolo 64(2).
Gli obblighi dell'allegato I parte II proseguono dopo la fine del periodo di supporto?
No. Gli otto obblighi dell'allegato I parte II si applicano per l'intero periodo di supporto ai sensi dell'articolo 13(8) e decadono per quella versione di prodotto al termine del periodo. Due obblighi sopravvivono al periodo di supporto: l'obbligo di conservazione della documentazione tecnica ai sensi dell'articolo 31 (dieci anni dall'immissione sul mercato) e qualsiasi segnalazione ai sensi dell'articolo 14 già in corso al momento della fine del periodo. Le nuove vulnerabilità scoperte dopo il termine del supporto non devono essere corrette per quella versione, ma il fabbricante deve aver pubblicato una chiara data di fine del supporto nelle informazioni sul prodotto affinché gli utenti possano migrare. Si vedano periodo di supporto e comunicazione di fine supporto.
Quando un intake CVD diventa un trigger dell'articolo 14?
Il trigger è "attivamente sfruttata" ai sensi dell'articolo 3(42), non "segnalata" né "sfruttabile". Una proof-of-concept funzionante allegata a una segnalazione CVD non è di per sé un trigger dell'articolo 14; 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 ai sensi dell'articolo 14 del CRA.