Introduzione: Gestione della vulnerabilità basata sul rischio ai sensi del Cyber Resilience Act
I team moderni sanno già che correggere ogni vulnerabilità è impossibile. Ciò che conta davvero è correggere quelle giuste. Ecco perché la gestione delle vulnerabilità basata sul rischio è diventata l'approccio preferito per i team DevSecOps. Tuttavia, nell'Unione Europea, questa non è più solo una buona pratica. Il Cyber Resilience Act introduce obblighi legali concreti, soprattutto quando il software include problemi elencati nel CISUn catalogo delle vulnerabilità note sfruttate.
In questo nuovo contesto, la definizione delle priorità per le vulnerabilità passa da una scelta di sicurezza a un requisito di conformità. I team devono dimostrare di comprendere quali vulnerabilità vengono attivamente sfruttate e come decidono cosa correggere per primo. E il tempo non è più un concetto astratto: A partire dall'11 settembre 2026, l'obbligo di segnalazione all'Agenzia delle Entrate canadese (CRA) per le vulnerabilità attivamente sfruttate e gli incidenti gravi si applica anche a questo tipo di situazioni., con l'insieme completo degli obblighi principali che seguiranno nel dicembre 2027. Qualunque modello di prioritizzazione un'organizzazione stia utilizzando oggi, deve essere difendibile in base a tale requisito di rendicontazione entro poche settimane, non trimestri.
Gestione delle vulnerabilità basata sul rischio e vulnerabilità note sfruttate
La gestione delle vulnerabilità basata sul rischio si concentra sull'esposizione reale anziché sulla gravità pura. Anziché trattare tutti i CVE allo stesso modo, i team stabiliscono le priorità in base a sfruttamento, raggiungibilità e impatto.
È qui che le vulnerabilità note sfruttate giocano un ruolo centrale. Quando una CVE appare nel CISUn catalogo di vulnerabilità note e sfruttate conferma che gli aggressori le utilizzano già in ambienti reali. Questo segnale ha un peso ben maggiore di un punteggio teorico.
Se desideri una spiegazione più approfondita su cosa sono i KEV e come identificarli, puoi leggere il nostro post precedente Vulnerabilità note sfruttate: cosa correggere per prima cosaIn questo articolo, ci concentriamo su come i KEV si inseriscono nei modelli di conformità e di definizione delle priorità previsti dal Cyber Resilience Act.
Cosa richiede realmente il Cyber Resilience Act
Il Cyber Resilience Act è un regolamento dell'UE che stabilisce obblighi di sicurezza informatica obbligatori per i prodotti con elementi digitali venduti nell'UE. Richiede ai fornitori di gestire le vulnerabilità durante l'intero ciclo di vita del prodotto e di evitare di rilasciare software con vulnerabilità note e sfruttate. Secondo il documentazione ufficiale dell'UE, i produttori devono:
- Identificare e gestire le vulnerabilità durante l'intero ciclo di vita del prodotto
- Impedire la spedizione di software con vulnerabilità note sfruttate
- Segnalate le vulnerabilità attivamente sfruttate e gli incidenti gravi entro 24 ore dalla loro scoperta; tale obbligo di segnalazione entrerà in vigore l'11 settembre 2026.
- Mantenere la prova della gestione della vulnerabilità decisioni
In altre parole, una volta che una vulnerabilità appare nel CISUn catalogo di vulnerabilità note e sfruttate, ignorato, crea rischi sia per la sicurezza che per la conformità normativa e, a partire da settembre 2026, a tale rischio è associato un termine per la segnalazione.
Che cos'è il Cyber Resilience Act (CRA)
Migliori Legge sulla resilienza informatica è un regolamento UE che definisce i requisiti obbligatori di sicurezza informatica per software e prodotti digitali venduti in Europa. Richiede ai fornitori di gestire le vulnerabilità durante tutto il ciclo di vita del prodotto e di evitare di rilasciare software con vulnerabilità note sfruttate.
Lista di controllo per la gestione della vulnerabilità basata sul rischio, pronta per l'approvazione da parte di CRA
Perché i KEV sono fondamentali per la conformità CRA
Migliori CISUn catalogo di vulnerabilità note e sfruttate (Known Exploited Vulnerabilities Catalog) elenca le CVE che gli aggressori sfruttano già in natura. In altre parole, elimina le ambiguità dal processo di prioritizzazione.
Invece di chiedersi "Potrebbe essere sfruttato?", i team ora devono porsi una domanda molto più diretta: "È già oggetto di sfruttamento e lo stiamo comunque distribuendo?"
Ai sensi del Cyber Resilience Act, questa distinzione è giuridicamente rilevante. Di conseguenza, i KEV diventano il principale fattore scatenante per gli SLA di ripristino e il blocco delle release. In questo contesto, la gestione delle vulnerabilità basata sul rischio si allinea naturalmente alle aspettative normative.
Abbiamo approfondito l'aspetto della segnalazione degli incidenti in una sessione congiunta con Nariman Aga-Tagiyev, Cybersecurity Architect di SecureHabits.nl: 24 ore per la segnalazione: come sopravvivere al conto alla rovescia dell'Agenzia delle Entrate canadeseIl documento illustra il ciclo di vita degli incidenti in tre fasi che la CRA si aspetta che le organizzazioni monitorino, dalla segnalazione di un problema, all'indagine, fino all'incidente confermato che dà inizio al periodo di segnalazione di 24 ore.
CVSS, EPSS e KEV hanno scopi diversi
Per stabilire correttamente le priorità, i team devono prima capire cosa rappresenta effettivamente ogni segnale.
- CVSS mostra un potenziale impatto
- EPS stima la probabilità di sfruttamento
- CISUn catalogo di vulnerabilità note sfruttate conferma che lo sfruttamento avviene già
Considerate singolarmente, ciascuna metrica può essere fuorviante. Tuttavia, quando i team le utilizzano insieme, il contesto risulta molto più chiaro. Per questo motivo, la combinazione di questi segnali costituisce la base di un'efficace gestione delle vulnerabilità basata sul rischio.
Gestione della vulnerabilità basata sul rischio nella pratica
In pratica, un modello di prioritizzazione basato sul rischio segue un flusso chiaro e ripetibile.
- Rilevare vulnerabilità nel codice e nelle dipendenze
- Controlla le corrispondenze con il CISUn catalogo di vulnerabilità note sfruttate
- Valutare la probabilità di exploit utilizzando EPSS
- Verifica la raggiungibilità nella tua applicazione o pipeline
- Applicare regole di correzione in base all'esposizione e al ruolo del prodotto
Di conseguenza, i team smettono di trattare gli elenchi delle vulnerabilità come backlog statici e iniziano a trattarli come soluzioni di sicurezza concrete.cisioni.
Diversi modelli di priorità utilizzati oggi dai team
Non tutti i team danno la stessa priorità al rischio. Generalmente, vediamo tre modelli comuni in ambienti reali.
1. Modello di severità prima di tutto
I team risolvono i problemi basandosi solo su CVSS.
Questo modello è facile da adottare. Tuttavia, crea confusione e non soddisfa le aspettative del Cyber Resilience Act.
2. Modello basato sulla verosimiglianza
I team si affidano all'EPSS per prevedere quali saranno le tattiche che gli aggressori potrebbero sfruttare in seguito.
Questo approccio migliora la focalizzazione. Ciononostante, non rileva le vulnerabilità che gli aggressori già sfruttano.
3. Modello consapevole dello sfruttamento
I team combinano EPSS con CISUn catalogo delle vulnerabilità note sfruttate e un contesto tecnico.
Al contrario, questo modello supporta al meglio la gestione della vulnerabilità basata sul rischio e si collega direttamente agli obblighi della CRA.
Come Xygeni rende operativa la priorità CRA Ready
Xygeni aiuta i team a trasformare la regolamentazione in flusso di lavoro quotidiano. Invece di affidarsi solo a dashboards, Xygeni impone decisindividua esattamente i punti in cui avvengono le modifiche al codice. Di conseguenza, la prioritizzazione diventa automatica e coerente.
Le capacità chiave includono:
- Correlazione automatica con il CISUn catalogo di vulnerabilità note sfruttate
- Punteggio di probabilità di exploit basato su EPSS
- Analisi di raggiungibilità per confermare la reale esposizione
- Guardrails che blocca le fusioni o i rilasci quando i KEV influenzano il codice raggiungibile
- Rimedio automatizzato tramite sicurezza pull requests
- Registri di controllo completi per dimostrare la conformità al Cyber Resilience Act.
In breve, i team non si limitano a vedere il rischio. Agiscono su di esso in modo ripetibile e verificabile.
Esempio da Dev a Dev: KEV blocca una versione
Immagina che un aggiornamento delle dipendenze introduca un CVE.
- La vulnerabilità appare nel CISUn catalogo di vulnerabilità note sfruttate
- Xygeni lo rileva durante la pull request
- L'analisi di raggiungibilità conferma che il percorso del codice viene eseguito
- Guardrails bloccare automaticamente l'unione
- Il bot propone un aggiornamento sicuro ed esegue i test
Lo sviluppatore risolve il problema nello stesso flusso di lavoro. La versione rimane conforme. Non sono necessarie riunioni.
In altre parole, si tratta di una gestione delle vulnerabilità basata sul rischio, applicata esattamente dove gli sviluppatori già lavorano.
Perché questo è importante oltre la conformità
Sebbene il Cyber Resilience Act abbia innescato questo cambiamento, i vantaggi vanno oltre. I team che danno priorità all'utilizzo di KEV, EPSS e contesto:
- Ridurre l'affaticamento da allerta
- Ridurre i tempi di bonifica
- Evitare le patch di emergenza
- Invia software più sicuro con fiducia
Nel complesso, la conformità diventa una conseguenza naturale di una corretta gestione della sicurezza.
Considerazioni finali: la CRA rende obbligatoria la gestione basata sul rischio
Il Cyber Resilience Act formalizza ciò che i team di sicurezza hanno già imparato a proprie spese: non tutte le vulnerabilità hanno la stessa importanza.
Migliori CISUn catalogo di vulnerabilità note e sfruttate (Known Exploited Vulnerabilities Catalog) definisce le vulnerabilità utilizzate dagli aggressori oggi. EPSS prevede quali saranno le loro prossime mosse. Il contesto mostra se la vulnerabilità ti riguarda.
Insieme, costituiscono la moderna gestione delle vulnerabilità basata sul rischio e, a partire dall'11 settembre 2026, non sarà più facoltativa. I team che sono già in grado di rispondere alla domanda "questa vulnerabilità è sfruttata? E la stiamo comunque distribuendo?" rispetteranno le scadenze di segnalazione del CRA senza problemi. I team che non ci riescono stanno scoprendo quanto siano effettivamente brevi 24 ore.
Xygeni aiuta i team ad applicare questo modello in modo continuo, automatico e in un modo che gli sviluppatori possano effettivamente accettare.
L'autore
Scritto da Fatima Said, Content Marketing Manager specializzato in Application Security presso Sicurezza Xygeni.
Fátima crea contenuti basati sulla ricerca e adatti agli sviluppatori su AppSec, ASPMe DevSecOps. Traduce concetti tecnici complessi in informazioni chiare e fruibili che collegano l'innovazione della sicurezza informatica all'impatto aziendale.
