Monitoraggio
Monitoraggio continuo delle vulnerabilità dei prodotti già distribuiti
Monitoraggio continuo delle vulnerabilità significa ricontrollare i componenti di ogni prodotto che ancora supporti rispetto ai dati sulle vulnerabilità man mano che quei dati cambiano, non solo quando cambia il tuo codice. Una scansione pulita al momento del rilascio invecchia man mano che compaiono nuovi avvisi di sicurezza: è il monitoraggio a trasformare una scansione una tantum nella gestione continua delle vulnerabilità che il Cyber Resilience Act si aspetta.
Piano Free, nessuna carta richiesta.
Perché una scansione pulita invecchia?
Una scansione delle vulnerabilità risponde a una sola domanda in un solo momento: quali vulnerabilità note riguardano queste versioni dei componenti, secondo i dati degli avvisi di sicurezza di oggi. Ogni giorno vengono pubblicati nuovi record CVE, e quelli esistenti vengono rivisti man mano che emergono versioni interessate, correzioni ed evidenze di sfruttamento. Non serve che il tuo prodotto cambi perché cambi il suo rischio: un’immagine firmware senza problemi noti a marzo può contenere una falla attivamente sfruttata a giugno, con gli stessi byte su ogni dispositivo in campo.
Per questo il CRA inquadra la gestione delle vulnerabilità come un processo e non come un evento. L’allegato I, parte II, chiede ai fabbricanti di identificare e documentare vulnerabilità e componenti, di correggere tempestivamente e di effettuare prove e riesami efficaci e periodici. Questi obblighi valgono per tutto il periodo di assistenza, che l’articolo 13, paragrafo 8, fissa in almeno cinque anni, salvo che si preveda un utilizzo del prodotto per un periodo inferiore.
Riscansionare le release distribuite o il ramo principale
Scansionare il ramo principale a ogni modifica è utile, ma ti parla del codice che distribuirai, non del codice che eseguono i tuoi clienti. I dispositivi in campo eseguono release: la versione 2.3 su alcuni, la 2.4 su altri e una lunga coda di unità che non sono mai state aggiornate. Ogni release supportata ha bisogno del proprio elenco di componenti, ricontrollato rispetto ai dati attuali degli avvisi di sicurezza, perché alla domanda «i nostri clienti sono esposti?» risponde la release, non il ramo.
Conserva una distinta base del software (SBOM) per ogni versione rilasciata, legata alla stringa di versione che vedono gli utenti. Quando un nuovo avviso di sicurezza corrisponde, puoi dire quali release sono interessate e verso quale release corretta indirizzare i clienti. Per il software, l’articolo 13, paragrafo 10, del CRA ti consente di correggere solo nell’ultima versione sostanzialmente modificata, se gli utilizzatori delle versioni precedenti possono passarvi gratuitamente e senza costi aggiuntivi per adeguare il proprio ambiente.
Riconfronto basato sulla SBOM: monitorare senza ricompilare
Invece di ricompilare e riscansionare il prodotto, conservi la SBOM prodotta al rilascio e confronti regolarmente nomi e versioni dei suoi componenti con banche dati di avvisi di sicurezza come OSV.dev, la NVD e la banca dati europea delle vulnerabilità dell’ENISA (EUVD). Poiché la SBOM descrive ciò che è stato distribuito, una corrispondenza riguarda release reali. Il risultato vale quanto la SBOM: i componenti privi di versione o di identificatori di pacchetto non possono essere confrontati in modo affidabile, e il codice incorporato nel repository (vendored) o collegato staticamente che la SBOM non elenca resta invisibile.
Il riconfronto affianca una scansione completa periodica, non la sostituisce. Una scansione completa beneficia di un rilevamento dei componenti migliorato e di nuove regole di analisi, e trova problemi che non sono affatto vulnerabilità dei componenti, come segreti committati o errori di configurazione: eseguine una a ogni rilascio e ogni volta che cambia la build.
Come aiutano KEV ed EPSS a dare priorità alle nuove vulnerabilità?
Il monitoraggio produce un flusso di corrispondenze; la prioritizzazione decide quali meritano attenzione per prime. Aiutano due segnali pubblici. Il catalogo Known Exploited Vulnerabilities (KEV) della CISA elenca le vulnerabilità che hanno un ID CVE, evidenze affidabili di sfruttamento reale e indicazioni chiare per la correzione. L’Exploit Prediction Scoring System (EPSS) di FIRST pubblica ogni giorno, per ogni CVE, una probabilità stimata che venga sfruttata nel mondo reale nei successivi 30 giorni. Il CVSS descrive quanto grave potrebbe essere lo sfruttamento; KEV ed EPSS indicano se è avvenuto o quanto è probabile.
Combinali con il tuo contesto. Una vulnerabilità elencata nel KEV in un componente che distribuisci andrebbe valutata il giorno stesso: il codice vulnerabile è presente e raggiungibile nella tua build, e quali release lo contengono? Registra il ragionamento in ogni caso; una decisione «non interessato» documentata è utile a un auditor quanto una correzione.
Come alimenta il monitoraggio le segnalazioni ai sensi dell’articolo 14 del CRA?
Dall’11 settembre 2026 l’articolo 14 del CRA impone ai fabbricanti di notificare le vulnerabilità attivamente sfruttate contenute nei loro prodotti al CSIRT designato come coordinatore e all’ENISA, tramite la piattaforma unica di segnalazione dell’ENISA. Il preallarme va inviato entro 24 ore dal momento in cui il fabbricante ne viene a conoscenza, la notifica della vulnerabilità entro 72 ore e la relazione finale al più tardi 14 giorni dopo che è disponibile una misura correttiva o di attenuazione. Ai sensi dell’articolo 69, paragrafo 3, l’articolo 14 riguarda anche i prodotti che rientrano nell’ambito di applicazione immessi sul mercato prima dell’11 dicembre 2027.
L’orologio parte dal momento in cui se ne viene a conoscenza, il che rende il monitoraggio la parte iniziale del tuo processo di segnalazione. Una nuova voce KEV che corrisponde a un componente di un prodotto rilasciato è un segnale che una persona deve valutare rapidamente: si tratta di una vulnerabilità attivamente sfruttata contenuta nel tuo prodotto, cioè esistono prove affidabili che un soggetto malintenzionato l’abbia sfruttata in un sistema senza l’autorizzazione del proprietario? Qualunque sia la risposta, l’articolo 13, paragrafo 7, si aspetta che tu documenti le vulnerabilità di cui vieni a conoscenza e che aggiorni, se del caso, la valutazione dei rischi.
Come definire una cadenza di monitoraggio e i responsabili
Il monitoraggio fallisce in silenzio quando nessuno è responsabile dei risultati. Metti per iscritto cadenza e responsabili, come parte della politica di gestione delle vulnerabilità che ti serve comunque per il CRA, e prova il percorso una volta prima di farci affidamento. Una base da adattare ai tuoi prodotti:
- Un responsabile per prodotto, con un sostituto, che esamina le nuove corrispondenze ogni giorno lavorativo e quelle KEV il giorno stesso.
- Un registro delle release supportate, ciascuna con la sua SBOM e la data di fine assistenza.
- Il riconfronto di ogni release supportata almeno una volta al giorno, e una scansione completa a ogni rilascio o modifica della build.
- Un ordine di valutazione: prima le vulnerabilità di cui è noto lo sfruttamento, poi EPSS elevato, poi la gravità CVSS, corretto in base all’esposizione.
- Una persona in grado di approvare una notifica ai sensi dell’articolo 14 entro 24 ore, fine settimana compresi.
- Un registro delle decisioni per ogni corrispondenza (interessato, non interessato, corretto in una versione indicata) con le relative evidenze.
Disponibile oggi in KROMSE
Sui piani a pagamento, KROMSE ricontrolla l’ultima SBOM di ogni prodotto rispetto ai dati attuali degli avvisi di sicurezza e mostra le nuove corrispondenze all’interno del prodotto.
- Ogni 6 ore, l’ultima SBOM di ciascun prodotto viene ricontrollata rispetto a OSV.dev, per un massimo di 5 prodotti per spazio di lavoro per ciclo, a rotazione.
- Le nuove corrispondenze compaiono come avvisi nell’app, e un pulsante «Run monitoring now» avvia un controllo su richiesta.
- Le rilevazioni con ID CVE vengono arricchite con CISA KEV, FIRST EPSS, la NVD e la banca dati europea delle vulnerabilità dell’ENISA (EUVD).
- Ogni scansione produce SBOM CycloneDX e SPDX, e puoi caricare le SBOM che hai già.
- Sui piani a pagamento, bozze interne di segnalazione ai sensi dell’articolo 14 del CRA per le fasi delle 24 ore, delle 72 ore e finale, in PDF, da far approvare a una persona; KROMSE non le invia mai.
- Limiti attuali: non puoi impostare una tua pianificazione, il monitoraggio non invia email e non avvia riscansioni in automatico.
In arrivo
Nella roadmap, non ancora disponibile. Le date sono obiettivi, non promesse; questa pagina viene aggiornata il giorno in cui una funzionalità diventa disponibile.
- In arrivo · Q4 2026 (dicembre)Monitoraggio pianificato da te, con agenti IA. Le nuove scansioni verranno eseguite secondo una pianificazione definita da te, con agenti IA che seguono i nuovi avvisi di sicurezza, valutano quali ti riguardano, propongono correzioni e preparano il report per la tua revisione.
- In arrivo · Q4 2026 (novembre)Correzioni proposte dall’IA, approvate da una persona. KROMSE proporrà correzioni per le rilevazioni, scritte con l’IA e applicate solo dopo l’approvazione di una persona del tuo team.
- In arrivo · Q1 2027Invio alla piattaforma unica di segnalazione dell’ENISA. Dopo che una persona avrà approvato una segnalazione ai sensi dell’articolo 14, KROMSE la invierà alla piattaforma unica di segnalazione dell’ENISA.
Domande frequenti
Qual è la differenza tra scansione delle vulnerabilità e monitoraggio continuo delle vulnerabilità?
Una scansione esamina un prodotto una volta ed elenca le vulnerabilità note nei suoi componenti in quel momento. Il monitoraggio continuo ripete il confronto man mano che cambiano i dati degli avvisi di sicurezza, di solito riconfrontando la SBOM di ogni release, così vieni a sapere delle nuove vulnerabilità nei prodotti distribuiti senza aspettare la prossima modifica del codice.
Ogni quanto vanno ricontrollati i prodotti distribuiti per individuare nuove vulnerabilità?
Nessuna legge dell’UE fissa un intervallo. Il CRA richiede prove e riesami periodici e una correzione tempestiva, e il suo orologio di segnalazione parte da quando si viene a conoscenza di una vulnerabilità attivamente sfruttata, quindi l’intervallo dovrebbe permetterti di accorgertene in ore, non in settimane. Un riconfronto delle SBOM quotidiano o più frequente, più una scansione completa a ogni rilascio, è un punto di partenza ragionevole.
Una voce nel KEV significa che devo fare una segnalazione ai sensi dell’articolo 14 del CRA?
Non automaticamente. L’articolo 14 riguarda le vulnerabilità attivamente sfruttate contenute nel tuo prodotto: devono esistere prove affidabili che un soggetto malintenzionato abbia sfruttato la vulnerabilità in un sistema senza l’autorizzazione del proprietario. Una voce KEV è una forte evidenza di sfruttamento, ma una persona deve comunque stabilire se il codice vulnerabile si trova nel tuo prodotto. Una volta che ne sei a conoscenza, decorre il termine di 24 ore.
Il monitoraggio conta per i prodotti immessi sul mercato prima che il CRA si applichi?
Sì, per le segnalazioni. L’articolo 69, paragrafo 3, rende l’articolo 14 applicabile ai prodotti che rientrano nell’ambito di applicazione immessi sul mercato prima dell’11 dicembre 2027, e l’articolo 14 si applica dall’11 settembre 2026. Le FAQ della Commissione sul CRA spiegano che per questi prodotti i fabbricanti devono effettuare le segnalazioni ma non sono tenuti a rispettare altri obblighi, come la gestione delle vulnerabilità. Per accorgerti di una vulnerabilità sfruttata in questi prodotti, però, devi comunque sapere cosa contengono.
KROMSE mi invia un’email quando una nuova vulnerabilità corrisponde al mio prodotto?
Non oggi. Sui piani a pagamento, KROMSE ricontrolla l’ultima SBOM di ogni prodotto rispetto a OSV.dev ogni 6 ore, per un massimo di 5 prodotti per spazio di lavoro per ciclo a rotazione, e mostra le nuove corrispondenze come avvisi nell’app. Il monitoraggio con una pianificazione definita da te, con agenti IA, è nella roadmap.
Guide correlate
Fonti
- Regolamento (UE) 2024/2847 (regolamento sulla ciberresilienza), EUR-Lex
- Commissione europea: FAQ sull’attuazione del Cyber Resilience Act
- ENISA: Single Reporting Platform (piattaforma unica di segnalazione)
- ENISA: banca dati europea delle vulnerabilità (EUVD)
- CISA: catalogo Known Exploited Vulnerabilities
- FIRST: Exploit Prediction Scoring System (EPSS)
- OSV: database di vulnerabilità open source