Come gestire il numero crescente di CVE quando il team è piccolo

Che cosa è cambiato: i numeri delle CVE

I dati qui sotto provengono dai record del CVE Program stesso, ricostruiti ogni giorno nella nostra pagina Trend di pubblicazione delle CVE. Allo snapshot del 12 nov 2026 UTC:

• 47.801 record sono stati pubblicati nel 2025, il 20% in più rispetto all'anno precedente.
• 95.494 record sono stati pubblicati finora nel 2026, 303 al giorno, +131% rispetto al ritmo giornaliero del 2025.
• 155 al giorno hanno gravità High o Critical.
• 17% di tutti i record dal 2020 non hanno un punteggio CVSS, né dall'assegnatario né dall'arricchimento di CISA. La copertura è migliorata: nel 2026 la quota è 6%.
• 505 organizzazioni hanno assegnato questi record, e le 20 più grandi ne rappresentano 75%.

• High o Critical
• Altre gravità e senza punteggio

1. 39 2020
2. 54 2021
3. 68 2022
4. 78 2023
5. 109 2024
6. 131 2025
7. 303 2026*

Media giornaliera dei record pubblicati in ciascun anno; * indica l'anno in corso fino a oggi. Fonte: i record cvelistV5 del CVE Program, snapshot del 12 nov 2026 UTC. Filtri per mese, gravità e assegnatario: Trend di pubblicazione delle CVE.

Non si tratta di un trimestre negativo. Il numero è cresciuto ogni anno dal 2020, e diversi cambiamenti strutturali continuano a farlo crescere:

• Più assegnatari, che assegnano in modo più ampio. Il progetto del kernel Linux è diventato CVE Numbering Authority nel febbraio 2024. La sua policy documentata prevede di assegnare una CVE a ogni correzione di bug che potrebbe essere una vulnerabilità, una volta che la correzione arriva in un kernel stabile, perché spesso la sfruttabilità non è chiara quando la correzione viene integrata. La sola CNA del kernel ha pubblicato da allora 18.221 record.
• Scoperta assistita dall'AI. Nel novembre 2024 Project Zero e DeepMind di Google hanno riferito che il loro agente Big Sleep aveva trovato un bug di sicurezza della memoria sfruttabile in SQLite prima che arrivasse in una release, quello che ritengono il primo esempio pubblico di un agente AI che ci riesce in un software ampiamente usato. Strumenti simili aumentano quanto può trovare un singolo ricercatore.
• La NVD non riesce più ad arricchire tutto. Il NIST afferma che la National Vulnerability Database ha accumulato dall'inizio del 2024 un arretrato di CVE non arricchite e non è riuscita a smaltirlo mentre le segnalazioni continuavano a crescere. Nell'aprile 2026 è passata a un modello basato sul rischio: vengono arricchite per prime le CVE presenti nel catalogo Known Exploited Vulnerabilities di CISA e quelle relative a software federale o critico, mentre le altre risultano non pianificate per un arricchimento immediato. Un processo che si affida ai dati sui prodotti interessati di un solo database ora aspetta, oppure perde qualcosa.
• Meno tempo per rispondere. Mandiant ha misurato un tempo medio di sfruttamento di 63 giorni nel 2018 e nel 2019. Il suo report M-Trends 2026 stima meno sette giorni per il 2025: lo sfruttamento ora inizia abitualmente prima che venga rilasciata una patch.
• Scadenze normative. Secondo il Cyber Resilience Act dell'UE, i fabbricanti segnalano una vulnerabilità attivamente sfruttata con un preallarme entro 24 ore, una notifica entro 72 ore e una relazione finale entro 14 giorni dalla disponibilità di una correzione (che cosa richiede il CRA). Le scadenze sono le stesse per un team di tre persone e per uno di trecento.

Niente di tutto questo significa che il software stia diventando meno sicuro. Significa che il numero di cose che un team deve esaminare cresce ogni anno, mentre il team no.

Che cosa si rompe nel processo di un piccolo team

L'aumento dei numeri non manda in crisi la gestione delle vulnerabilità perché ci sono più vulnerabilità da correggere. La manda in crisi perché ogni passaggio manuale si ripete per ogni CVE.

Passaggio manuale	Perché non regge con i volumi attuali
Costruire l'inventario a mano	Un foglio di calcolo, o una SBOM preparata prima di un audit, è superato il giorno dopo la release successiva.
Leggere il feed	Con 155 record High o Critical al giorno, nessuno riesce a stare al passo.
Chiedere all'engineering "usiamo X?"	La stessa domanda per ogni CVE, alle stesse persone già impegnate. Il collo di bottiglia è la domanda stessa.
Un ticket per ogni CVE in ogni repository	La CVE di una libreria condivisa diventa decine di ticket duplicati che sommergono il backlog.
Rispondere a ogni cliente uno per uno	Le richieste crescono con la base clienti, non con il numero di vulnerabilità.
Documenti in PDF o in un wiki	Gli strumenti dei clienti non possono confrontare un PDF con il loro inventario, quindi ogni lettore chiede di nuovo.
Scadenze che non si spostano	Il tempo di sfruttamento si riduce, mentre un processo manuale rallenta con l'aumentare dei volumi.

L'inventario. La maggior parte dei team che tiene a mano un elenco dei componenti lo aggiorna prima di un audit o di un questionario di un cliente. Tra una data e l'altra descrive un software che non viene più distribuito. Ogni domanda su una CVE parte quindi dalla ricostruzione di ciò che conteneva la release.

Il feed. Leggere gli advisory è il passaggio da cui i team partono, e il primo a cedere. Sentiamo team che lo fanno ancora a mano, tra cui uno in cui la scansione delle vulnerabilità consiste in persone che leggono forum sulle CVE. Funziona fino al giorno in cui non funziona più, e non c'è alcun segnale che annunci quel giorno.

La domanda all'engineering. "Usiamo questa libreria, e in quale versione?" interrompe uno sviluppatore per ogni CVE che potrebbe riguardarvi. Un team di product security di due persone ci ha detto che il suo lavoro consiste nel premere pulsanti solo per stare al passo, senza tempo per migliorare il processo.

I ticket. Quando una libreria condivisa ha una CVE e ogni repository apre il proprio ticket, il backlog conta la stessa decisione molte volte. I team imparano a ignorare il backlog, e poi perdono il ticket che contava.

Le risposte ai clienti. Dopo una vulnerabilità molto discussa o un attacco alla supply chain, i clienti chiedono "siamo coinvolti?". Rispondere a ciascuno separatamente costa più tempo proprio nel giorno in cui ce n'è meno.

I documenti. Una dichiarazione in PDF o una pagina wiki deve essere letta da una persona dal lato del cliente. Gli scanner dei clienti, e sempre più spesso le autorità di regolamentazione, si aspettano SBOM, VEX e advisory in formati che una macchina può confrontare.

Le scadenze. Un preallarme dovuto entro 24 ore, o un exploit che compare prima della patch, non aspetta che la coda si svuoti.

Che cosa automatizzare, in ordine

Ogni passaggio toglie lavoro al successivo, quindi l'ordine conta più della scelta degli strumenti.

1. Sapere che cosa distribuisce. Una SBOM da ogni build trasforma "siamo coinvolti?" in una ricerca.
2. Matching continuo, su più di una fonte. Le nuove CVE vengono confrontate con ogni SBOM archiviata, così nessuno legge il feed.
3. Tagliare il rumore. I risultati su ciò che non viene distribuito, e i duplicati, non arrivano mai a una persona.
4. Triage semiautomatico. I fatti sono già compilati; la decisione la prende una persona.
5. Rendere tutto leggibile dalle macchine. Ogni decisione si prende una volta e viene riutilizzata da ogni lettore.
6. Rispondere una volta, pubblicamente. La richiesta che non arriva non costa nulla.

1. Generare automaticamente una SBOM per ogni build

Che cosa sostituisce: il foglio di calcolo e la domanda all'engineering. Una SBOM generata in fase di build descrive ciò che la build ha effettivamente usato, e conservarne una per ogni versione distribuita significa poter rispondere sia per la release dell'anno scorso sia per main. I clienti usano versioni vecchie; il Suo inventario deve coprirle.

Versione minima: una SBOM generata in CI per ogni build di release, archiviata accanto all'artefatto della release. Meglio: una SBOM registrata dalla build stessa invece che dedotta a posteriori dai lockfile, così vi compaiono anche i componenti scaricati al di fuori del package manager (SBOM in fase di build, automazione delle SBOM).

Costo: uno o due giorni di lavoro sulla pipeline per la versione minima, poi nulla per ogni release. Segnale che funziona: per qualsiasi release, Lei può elencarne i componenti senza chiedere a nessuno.

2. Matching continuo su più fonti di vulnerabilità

Che cosa sostituisce: la lettura del feed. Il matching è un lavoro da macchina: ogni nuova CVE contro ogni SBOM archiviata, non solo la SBOM della build appena eseguita. Una vecchia release che era pulita quando è stata distribuita diventa vulnerabile il giorno in cui viene pubblicata una CVE per uno dei suoi componenti.

Una sola fonte non basta. L'arretrato di arricchimento della NVD fa sì che i dati sui prodotti interessati possano arrivare in ritardo o non arrivare affatto. Gli advisory degli ecosistemi, come GitHub Advisory Database e OSV, sono spesso più rapidi e indicano quali versioni dei pacchetti sono interessate nei termini propri dell'ecosistema. La EU Vulnerability Database dell'ENISA aggiunge il contesto europeo.

Versione minima: un job pianificato che ogni giorno riesamina ogni SBOM archiviata rispetto a una fonte aggregata e segnala le nuove corrispondenze. Segnale che funziona: Lei scopre che una release è coinvolta prima che glielo dica un cliente. Veda il monitoraggio delle vulnerabilità per come funziona in CRACI.

3. Tagliare il rumore prima che qualcuno guardi

Che cosa sostituisce: la revisione manuale di risultati che non contano. La maggior parte del rumore nasce a monte: da inventari che elencano ciò che Lei non distribuisce, da più strumenti che segnalano la stessa CVE e da dipendenze di cui nessuno ha bisogno. Corregga l'inventario, conti ogni risultato una sola volta per package URL (PURL), versione e CVE, distribuisca meno dipendenze, poi aggiunga il contesto di sfruttabilità da CISA KEV, EPSS e VEX. Come ridurre il rumore delle vulnerabilità affronta queste leve una per una. Segnale che funziona: i risultati per release distribuita diminuiscono, e le motivazioni sono documentate.

4. Triage semiautomatico

Che cosa sostituisce: una persona che raccoglie i fatti per ogni risultato. Divida il lavoro con precisione:

• Automatico: gravità, se è noto che viene sfruttata, quali prodotti e versioni contengono il componente, il team responsabile, una priorità proposta e una scadenza.
• Umano: la decisione. Correggere, mitigare, accettare con una data di scadenza, oppure segnare come non interessato con una giustificazione.

Che cosa non è sicuro automatizzare: chiudere un risultato come non interessato senza una motivazione documentata. Quella è soppressione, e ritorna in un audit o in un incidente. Le regole di classificazione sono trattate in prioritizzazione delle vulnerabilità.

Versione minima: 15 minuti al giorno su una coda già ordinata e compilata. Segnale che funziona: ogni decisione ha una motivazione documentata, e nulla resta in attesa che qualcuno cerchi qualcosa.

5. Rendere tutto leggibile dalle macchine

Che cosa sostituisce: PDF, pagine wiki ed email che una persona deve leggere. Pubblichi le SBOM in CycloneDX o SPDX (CycloneDX vs SPDX), le decisioni di non interessamento come VEX e gli advisory in CSAF. Gli scanner dei clienti e le autorità di regolamentazione possono così utilizzarli senza intervento umano, e ogni decisione si prende una volta e viene riutilizzata da chiunque la chieda.

Versione minima per un piccolo team: SBOM e VEX su richiesta, da una posizione stabile; CSAF quando i clienti iniziano a chiederlo. Segnale che funziona: gli strumenti dei clienti smettono di segnalare ciò a cui Lei ha già risposto.

6. Rispondere una volta, pubblicamente

Che cosa sostituisce: un thread email per ogni cliente. Pubblichi un advisory o una pagina di stato per ogni CVE significativa, con le versioni interessate e quelle corrette, e tenga un modello di risposta che vi rimandi. La guida su come rispondere a "siamo coinvolti da questa CVE?" mostra come arrivare alla risposta. Per la risposta vera e propria, come rispondere ai clienti dopo un attacco alla supply chain offre modelli di risposta. La richiesta più economica è quella che non arriva mai. Segnale che funziona: alla maggior parte delle richieste si risponde con un link.

Poi correggere

Le pull request automatiche di aggiornamento delle dipendenze mandano avanti il lavoro ordinario; le raggruppi per settimana o per release, così la revisione resta gestibile. Aggiornare un pacchetto a monte spesso elimina in un colpo solo diverse dipendenze transitive vulnerabili, e costa meno che correggerle una per una (remediation automatica delle vulnerabilità). Poi impedisca ai componenti noti come vulnerabili di rientrare con policy gate che bloccano la build.

Un piano in base alla dimensione del team

Le ore sono stime illustrative per la pianificazione, non benchmark.

	Una persona, part-time	Una funzione di sicurezza o PSIRT da 2 a 5 persone	Un team più grande
Da automatizzare prima	Passaggi 1 e 2: una SBOM per build e matching continuo	Passaggi da 1 a 3, poi l'assegnazione ai responsabili del passaggio 4	Tutti e sei, con policy gate in ogni pipeline
Resta manuale	La decisione su ogni risultato High o Critical; le risposte ai clienti da un modello	Decisioni, giustificazioni VEX, advisory per le CVE significative	Decisioni, eccezioni e il processo stesso
Tempo settimanale, illustrativo	Da 2 a 4 ore	Da 4 a 8 ore a persona	Determinato dal volume di decisioni, non dal feed

Se gestisce già un PSIRT, vale lo stesso ordine; il modello di processo completo è nel ciclo di vita della gestione delle vulnerabilità. Per le richieste dei clienti che si moltiplicano a ogni CVE, consulti come scalare un PSIRT.

Come capire se funziona

• Il tempo dalla pubblicazione di una CVE a "interessato" o "non interessato", per prodotto.
• La quota di richieste dei clienti a cui si risponde con materiale pubblicato.
• I risultati per release distribuita, non per scansione.
• La quota di decisioni con una motivazione documentata.
• Le ore settimanali dedicate alle vulnerabilità, e se stanno diminuendo.

Misuri prima la Sua baseline. Non esistono benchmark di settore affidabili per questi indicatori, e non ne citiamo.

Assumere, acquistare o cambiare il processo?

• Assuma quando il lavoro consiste nel correggere vulnerabilità nel Suo codice, o in attività di sicurezza rivolte ai clienti che richiedono giudizio.
• Acquisti strumenti per i passaggi che si ripetono per ogni CVE: i passaggi 1, 2, 3 e 5.
• Cambi il processo per responsabilità e scadenze: chi decide, ed entro quando.

Sia onesto sull'ultimo punto. Uno strumento senza un responsabile produce una dashboard che nessuno legge.

Dove si colloca CRACI

CRACI automatizza i passaggi 1 e 2, e parte dei passaggi 3 e 4, per il software compilato in GitHub Actions. Sostituisce i Suoi runner ospitati da GitHub e, durante l'esecuzione di ogni job, registra i pacchetti che il job ha effettivamente scaricato, compresi i pacchetti ripristinati dalle cache CI e le dipendenze nascoste che nessun lockfile elenca.

• Una SBOM da ogni build. La SBOM di ogni job identifica ogni componente tramite PURL e riporta uno stato di completezza, così Lei sa quando qualcosa non è stato visibile. La cronologia delle build conserva ogni build passata con la sua SBOM, così può vedere quali build contenevano una dipendenza vulnerabile, diretta o transitiva.
• Matching continuo. Le SBOM monitorate vengono rivalutate di continuo, e i risultati sono aggregati tra build e repository, così la CVE di una libreria condivisa compare come un unico problema, non quaranta.
• Notifiche e gate. CRACI notifica alle persone interessate una vulnerabilità e la sua gravità, e i policy gate possono fermare una build in tempo reale, anche una build che contiene una specifica CVE.
• Triage e assegnazione. I team di sicurezza fanno il triage dei risultati in CRACI e inoltrano ciascuno al team responsabile della correzione.
• SBOM leggibili dalle macchine. Le SBOM si esportano in CycloneDX o SPDX e CRACI supporta VEX.

CRACI non pubblica advisory, non offre l'analisi di raggiungibilità e non analizza il Suo codice. Addebita solo i minuti di build: $0.002 per vCPU-minuto ($0.004 per un runner predefinito da 2 vCPU), misurati al secondo, senza canone mensile, senza costi per SBOM e, per ora, senza costi di licenza. Veda i prezzi.

Automatizzi oggi i primi due passaggi: esegua le Sue build su CRACI. Stiamo accompagnando personalmente ogni team nell'onboarding prima della disponibilità generale.

Quando CRACI non è la risposta

• Il Suo software non viene compilato in GitHub Actions. GitLab CI e Jenkins sono in roadmap.
• La Sua esposizione riguarda soprattutto l'infrastruttura: server, endpoint e configurazione cloud. Gli strumenti di gestione delle vulnerabilità dell'infrastruttura sono più adatti.
• Lei integra firmware di terze parti che non compila. Gli strumenti di analisi binaria sono più adatti.
• Il Suo backlog è composto soprattutto da risultati reali e sfruttabili nel Suo codice. È un problema di capacità di remediation, non di automazione.

Automazione della gestione delle vulnerabilità: domande frequenti

Perché oggi ci sono così tante CVE in più?

Più organizzazioni assegnano CVE, e alcune le assegnano in modo ampio: il kernel Linux è diventato CVE Numbering Authority nel 2024 e ne assegna una a ogni correzione di bug che potrebbe essere una vulnerabilità. Gli strumenti assistiti dall'AI trovano più bug per ricercatore. Nel 2025 sono stati pubblicati 47.801 record, e il 2026 procede a 303 al giorno. La tendenza dura da anni.

Come può un piccolo team stare al passo con le nuove CVE?

Non leggendole. Generi una SBOM per ogni build, confronti automaticamente le nuove CVE con ogni SBOM archiviata, tagli il rumore e lasci alle persone solo le decisioni su ciò che resta. Un piccolo team sta al passo eliminando i passaggi che si ripetono per ogni CVE, non lavorando più in fretta.

Che cosa automatizzare per primo nella gestione delle vulnerabilità?

L'inventario: una SBOM generata in CI per ogni build di release, archiviata con la release. Ogni passaggio successivo dipende da essa, e trasforma "siamo coinvolti?" da una domanda all'engineering in una ricerca. Al secondo posto viene il matching continuo su quelle SBOM.

Serve un team di sicurezza per gestire le vulnerabilità?

Non per iniziare. Una persona responsabile del processo part-time può gestirlo se inventario, matching e riduzione del rumore sono automatizzati. Servono un responsabile designato e delle scadenze più di un team. Assuma quando il lavoro diventa correggere il Suo codice o attività di sicurezza rivolte ai clienti.

Come sappiamo quali nuove CVE riguardano il nostro prodotto?

Conservi una SBOM per ogni versione distribuita e le ricontrolli tutte ogni volta che vengono pubblicate nuove CVE, su più di una fonte di vulnerabilità. Una CVE La riguarda quando corrisponde a un componente e a una versione che Lei distribuisce davvero. Il contesto di sfruttabilità e VEX dicono poi se conta.

Che cosa significa "leggibile dalle macchine" per SBOM, VEX e advisory, e perché è importante?

Significa un formato strutturato standard che uno strumento può analizzare: CycloneDX o SPDX per le SBOM, VEX per le dichiarazioni di non interessamento, CSAF per gli advisory. Lo scanner di un cliente può confrontarli con il proprio inventario senza che nessuno li legga, così una decisione presa una volta viene riutilizzata da ogni cliente e strumento.

Quanta parte del triage si può automatizzare in sicurezza?

La raccolta dei fatti: gravità, stato di sfruttamento, quali prodotti e versioni contengono il componente, il responsabile, una priorità proposta e una scadenza. La decisione deve restare a una persona. Non chiuda mai automaticamente un risultato come non interessato senza una motivazione documentata.

Quanto tempo abbiamo per rispondere a una CVE critica?

Meno di quanto presuppone la maggior parte dei processi. M-Trends 2026 di Mandiant stima il tempo medio di sfruttamento nel 2025 in meno sette giorni, cioè lo sfruttamento prima che esista una patch. Secondo il Cyber Resilience Act dell'UE, una vulnerabilità attivamente sfruttata richiede un preallarme entro 24 ore. Fissi le Sue scadenze in base a gravità e sfruttamento, e misuri i risultati rispetto a esse.