Metriche di gestione delle vulnerabilità: 20 KPI chiave da monitorare

Esplora le metriche di gestione delle vulnerabilità, scopri i 20 KPI principali e osserva come influenzano le strategie di sicurezza. Ottieni informazioni dettagliate sulle misurazioni essenziali e sulle best practice per una supervisione efficiente.

Il numero sempre crescente di rischi per la sicurezza rappresenta una minaccia significativa per le organizzazioni. Ad esempio, nell'anno precedente sono stati segnalati 37.902 nuovi CVE, motivo per cui sono necessarie misurazioni strutturate e metriche di gestione delle vulnerabilità per affrontare queste minacce e valutare la preparazione in materia di sicurezza. Sebbene gli strumenti di scansione possano aiutare a scoprire le vulnerabilità, i team hanno bisogno di dettagli specifici per comprendere la gravità del problema. Un sondaggio ha mostrato che solo il 14% dei partecipanti ha identificato la fonte di una violazione come minacce esterne quali hacker o altre organizzazioni compromesse. Questa statistica sottolinea l'importanza dell'approccio alla sicurezza basato su metriche.

Queste metriche garantiscono che tutte le vulnerabilità, poche o molte che siano, vengano misurate e che non vi siano lacune significative nella misurazione del rischio. In questo articolo discuteremo i concetti di base delle metriche di reporting della gestione delle vulnerabilità e come possono essere utilizzate per informare il processo decisionale strategico.

Cosa sono le metriche di gestione delle vulnerabilità?

Le metriche di gestione delle vulnerabilità sono indicatori misurabili dell'efficacia con cui un'organizzazione rileva, classifica in ordine di priorità e risolve le falle di sicurezza. Esse traducono i dati grezzi delle scansioni in numeri significativi (ad esempio, tempi medi di risoluzione, probabilità di exploit) per aiutare i responsabili della sicurezza a determinare in che misura le attività di patching sono in linea con gli obiettivi di gestione delle vulnerabilità. Queste metriche vanno oltre i semplici punteggi di gravità e tengono conto di fattori reali come l'impatto sul business o le informazioni sulle minacce. Con la crescita delle reti, l'aumento dei container e l'espansione delle catene di fornitura digitali, le metriche forniscono un punto di riferimento coerente per misurare i progressi e identificare le lacune. Questi dati possono anche essere monitorati per garantire la responsabilità, indirizzare l'allocazione delle risorse e il miglioramento continuo. In definitiva, le metriche giuste riuniscono il personale tecnico e i dirigenti su una comprensione comune del rischio e della correzione.

Importanza delle metriche di gestione delle vulnerabilità

Gartner prevede che entro la fine di quest'anno, il 45% delle organizzazioni a livello globale potrebbe subire intrusioni nella catena di approvvigionamento. Queste tendenze sottolineano l'importanza di adottare un approccio trasparente e basato sui dati per la scansione e l'applicazione delle patch. Le metriche di gestione delle vulnerabilità forniscono ai team una lente oggettiva per valutare la rapidità e l'efficacia con cui stanno affrontando le minacce. Di seguito, illustriamo cinque motivi per cui queste misurazioni rimangono un elemento fondamentale della sicurezza aziendale:

1. Guidare le decisioni strategiche: Le metriche forniscono prove quantificabili di successo o problemi. Un tempo medio di applicazione delle patch elevato, ad esempio, può indicare la necessità di riprogettare il flusso di lavoro delle patch. Confrontando le metriche chiave per la gestione delle vulnerabilità tra i diversi trimestri, la leadership può giustificare l'aggiunta di personale, l'adozione di nuove soluzioni di scansione o la revisione dei processi. Le decisioni basate sui dati eliminano le congetture per garantire che gli aggiornamenti di sicurezza affrontino effettivamente i punti critici esistenti.
2. Allineamento dei team sulle priorità: Il personale DevOps, i team di sicurezza e i dirigenti parlano spesso "linguaggi" diversi. Sono uniti da metriche che definiscono obiettivi condivisi, come l'obiettivo di ridurre il tempo medio di risoluzione da 30 a 10 giorni. Questo crea responsabilità: ogni gruppo può vedere come il proprio ruolo influisce sulla metrica complessiva. Concentrandosi sulle stesse misurazioni nel tempo, questa sinergia produce un'implementazione più fluida delle patch e un minor numero di difetti critici non risolti.
3. Evidenziare il ROI degli investimenti nella sicurezza: L'acquisizione di nuovi strumenti di automazione della gestione delle vulnerabilità o l'estensione della scansione a reti aggiuntive può essere costosa. I team possono verificare il valore dell'investimento dimostrando come questi cambiamenti riducano le finestre di exploit medie o decimino il volume delle vulnerabilità critiche in sospeso. Un business case più solido per ulteriori espansioni è supportato anche da metriche che mostrano una minore frequenza delle violazioni o una risposta più rapida agli incidenti. In breve, i dati chiariscono la connessione tra la spesa e il miglioramento della sicurezza nel mondo reale.
4. Monitoraggio delle tendenze a lungo termine: Una singola istantanea raramente è in grado di trasmettere l'efficacia di una strategia di misurazione dei programmi di gestione delle vulnerabilità nel corso di mesi o anni. Una prospettiva storica è fornita dal monitoraggio di dati quali le vulnerabilità di nuova introduzione, i tempi di risoluzione o i tassi di conformità delle patch in intervalli di tempo. Quando le stesse vulnerabilità continuano a ripresentarsi, le metriche indicano le cause alla radice, quali errori DevOps o configurazioni errate ripetute. Questa consapevolezza ciclica pone le basi per miglioramenti iterativi.
5. Soddisfare le aspettative normative e degli auditor: Molte normative richiedono la prova che le vulnerabilità individuate non siano state lasciate irrisolte. La conformità viene dimostrata utilizzando metriche dettagliate, come il rapporto tra difetti corretti e non corretti o il tempo impiegato per risolvere i problemi critici. Questi registri possono essere controllati dai revisori per garantire che l'organizzazione rispetti le tempistiche previste per l'applicazione delle patch. Questo processo porta a revisioni più agevoli, minori possibilità di essere multati e una maggiore fiducia nella sicurezza dell'organizzazione.

Metriche di gestione delle vulnerabilità: i 20 KPI principali

Quando si tratta di operazioni di sicurezza quotidiane, concentrarsi su alcuni KPI strategici può aumentare di 10 volte la velocità e l'efficienza con cui i vostri team possono affrontare i punti deboli. Di seguito presentiamo 20 metriche di vulnerabilità che compaiono comunemente nei dashboard aziendali. Ciascuna di esse riflette una dimensione diversa, come la velocità di rilevamento, la velocità di applicazione delle patch o la fattibilità degli exploit, essenziale per lo sviluppo di processi robusti. Non tutti i KPI sono adatti a tutte le aziende, ma valutarli può aiutare a capire quali numeri rappresentano accuratamente la posizione della propria organizzazione.

1. Tempo medio di rilevamento (MTTD): L'MTTD è una misura della rapidità con cui il tuo team è in grado di rispondere alle vulnerabilità appena scoperte, dalla divulgazione o creazione al primo rilevamento. Più basso è l'MTTD, migliore è la tua funzione di scansione o di intelligence sulle minacce. Gli aggressori possono sfruttare i difetti prima ancora che tu ti accorga che c'è un problema, grazie a intervalli di rilevamento più lunghi. Le metriche di risposta agli incidenti sono spesso abbinate all'MTTD, collegando i risultati della scansione con il rilevamento in tempo reale. Le organizzazioni riducono il tempo in cui i problemi non risolti rimangono invisibili riducendo l'MTTD.
2. Tempo medio di risoluzione (MTTR): L'MTTR misura il tempo che intercorre tra il rilevamento di una vulnerabilità e la sua risoluzione o correzione. Un MTTR più basso significa che la pipeline delle patch è efficiente, le approvazioni procedono rapidamente e il programma di implementazione è ottimale. Vincoli di test, personale limitato o dipendenze di codice complesse possono causare ritardi prolungati. Analizzando l'MTTR, è possibile identificare i colli di bottiglia nel ciclo di correzione e implementare soluzioni quali l'automazione parziale o la ristrutturazione degli intervalli di patch. Man mano che l'MTTR migliora nel tempo, questo tende a ridurre il numero di exploit riusciti.
3. Tasso di rilevamento delle vulnerabilità: Il tasso di rilevamento è la percentuale di potenziali difetti individuati tramite scansione o revisioni manuali. Un tasso di rilevamento elevato indica una buona copertura di reti, server o container. La ricerca di punti ciechi o configurazioni che impediscono controlli approfonditi è indice della presenza di alcuni difetti trascurati. Se applicata in ambienti containerizzati, la scansione delle vulnerabilità dei container può essere combinata con metodi standard per migliorare il rilevamento complessivo. La documentazione del tasso di rilevamento consente di perfezionare gli strumenti di scansione o gli intervalli per ridurre al minimo le omissioni.
4. Punteggio di sfruttabilità: Una metrica di sfruttabilità è una misura della disponibilità di exploit o dell'interesse degli aggressori, poiché non tutte le vulnerabilità vengono sfruttate attivamente in natura. I difetti gravi potrebbero non avere un exploit noto, mentre quelli moderati potrebbero apparire in kit di exploit popolari. Ciò consente una prioritizzazione basata sul rischio più accurata, combinando la gravità con il potenziale di sfruttamento. Monitorare il numero di difetti "altamente sfruttabili" consente ai responsabili della sicurezza di indirizzare le risorse verso i problemi che i criminali sono più propensi a sfruttare.
5. Tasso di conformità delle patch: Questo KPI viene calcolato misurando il numero di problemi rilevati che sono stati corretti entro un determinato periodo di tempo. Ad esempio, quale percentuale di tutte le vulnerabilità critiche individuate in un mese è stata corretta entro i 15 giorni successivi? Un ciclo di patch agile è indicato da un forte tasso di conformità. Tassi bassi evidenziano ostacoli al processo o attriti tra i reparti. Con il passare del tempo, la correlazione tra i tassi di conformità e la frequenza degli incidenti può dimostrare come l'applicazione tempestiva delle patch mitighi gli attacchi nel mondo reale.
6. Numero di vulnerabilità aperte: Una parte dei difetti identificati rimane irrisolta in un dato momento. Tracciando il conteggio grezzo o l'andamento nel tempo, è possibile vedere se il backlog sta diminuendo o aumentando. Dopo scansioni importanti o nuove implementazioni, potrebbero verificarsi fluttuazioni drastiche. Inoltre, questo numero è collegato alla logica alla base della gestione delle vulnerabilità, poiché una valutazione può rivelare i difetti aperti solo una volta, mentre la gestione cerca di ridurli nel tempo. Tenere d'occhio il backlog aiuta a mantenere la responsabilità.
7. Metriche di prioritizzazione basate sul rischio: Sebbene esistano classificazioni di gravità, molte organizzazioni scelgono di praticare la sinergia tra gestione delle vulnerabilità e gestione dei rischi. Ciò implica classificare le vulnerabilità in base all'impatto sul business, all'utilizzo degli exploit o alla potenziale esposizione dei dati. Se l'approccio basato sul rischio funziona, è possibile monitorare quanti elementi sono classificati come "ad alto rischio" o quanto velocemente vengono risolti. Se i difetti urgenti non vengono risolti entro un periodo di tempo ragionevole, ciò può essere indicativo di carenze del personale o dei processi.
8. Percentuale di vulnerabilità critiche risolte: Una versione più specifica della conformità delle patch incentrata solo sui difetti più gravi. Stabilisce un parametro di riferimento: con quale rapidità i problemi critici dovrebbero ricevere una patch completa: entro 24 ore, una settimana o un mese? Il management può verificare se le best practice di gestione delle vulnerabilità vengono seguite quantificando quante patch vengono applicate entro tale lasso di tempo. Tassi elevati indicano un programma maturo che risponde rapidamente a potenziali percorsi di violazione, mentre tassi bassi indicano potenziali limitazioni delle risorse.
9. Esposizione delle risorse e punteggi di rischio: Alcune soluzioni forniscono un punteggio di rischio per ogni risorsa o sottorete, compresa la percentuale di vulnerabilità aperte, la loro gravità e i dati di sfruttamento. Monitorando i punteggi di rischio medi o massimi nelle principali unità aziendali, è possibile individuare le aree meno sicure. Una scansione costante e punteggi di rischio più bassi si dimostrano un approccio efficace nel tempo. Nel frattempo, se alcuni segmenti presentano costantemente un rischio più elevato, la dirigenza può destinare risorse aggiuntive o formazione sulla sicurezza a tali segmenti.
10. Tempo medio tra il ripetersi delle vulnerabilità: Si tratta del momento in cui si ripresenta lo stesso difetto o uno simile (forse a causa della reinstallazione di una versione precedente o di un'immagine container difettosa). Questo KPI mostra quanto i team siano efficaci nell'implementare correzioni permanenti o nel gestire le pipeline DevOps che ripristinano accidentalmente problemi già noti. Intervalli di ricorrenza brevi indicano la necessità di perfezionare i processi sottostanti (come la gestione delle immagini). La ricorrenza può essere notevolmente ridotta se i team DevOps prendono l'abitudine di incorporare le best practice di scansione delle vulnerabilità dei container.
11. Tempo di mitigazione e tempo di applicazione della patch: A volte, una patch non è immediatamente disponibile o la sua applicazione potrebbe interrompere la produzione. Fino a quando non viene testata una patch stabile, le misure di mitigazione (come la disabilitazione di un servizio vulnerabile o l'utilizzo di una modifica temporanea della configurazione) possono bloccare lo sfruttamento. Monitorando la rapidità con cui queste misure provvisorie entrano in gioco rispetto alla tempistica finale della patch, possiamo vedere se le misure di limitazione del rischio a breve termine vengono utilizzate in modo efficace. Questa metrica sottolinea che le soluzioni parziali sono ancora importanti per prevenire compromissioni immediate.
12. Tasso di copertura della scansione: Questa cifra mostra la percentuale di risorse note scansionate da ciascun ciclo. Se la copertura non è completa, esistono difetti sconosciuti. Per ottenere un tasso di copertura elevato sono necessari inventari delle risorse e programmi di scansione coerenti. Nei contesti DevOps, i container possono apparire e scomparire rapidamente, sono effimeri e gli strumenti di scansione delle vulnerabilità delle immagini dei container devono adattarsi. La misurazione della copertura riduce al minimo la possibilità che vi siano sistemi non sottoposti a scansione.
13. Metriche di invecchiamento delle vulnerabilità: Questa serie di indicatori misura per quanto tempo le vulnerabilità rimangono aperte, talvolta suddivise per livelli di gravità (critica, alta, media, bassa). Un segnale di allarme si ha quando i difetti critici rimangono aperti oltre una soglia standard. Osservando queste tendenze di invecchiamento, è possibile vedere se il backlog cresce o diminuisce. I team possono monitorare costantemente i dati di invecchiamento per identificare i colli di bottiglia del processo che impediscono l'applicazione tempestiva delle patch.
14. Tassi di falsi positivi vs falsi negativi: I falsi positivi degli scanner possono causare una perdita di tempo da parte del personale addetto alla sicurezza su problemi inesistenti. La parte peggiore è che i falsi negativi non rilevano le vulnerabilità reali. Questa metrica mostra l'accuratezza della scansione e può indicare se una soluzione è sufficientemente ottimizzata o se alcuni moduli devono essere migliorati. Entrambi i tipi si riducono nel tempo, il che si traduce in una scansione efficiente e il personale può fidarsi maggiormente dei risultati durante la valutazione delle vulnerabilità.
15. Conformità SLA per la correzione delle vulnerabilità: Questa metrica misura la conformità se un'organizzazione stabilisce SLA interni o esterni (ad esempio, le vulnerabilità critiche devono essere risolte entro 48 ore). La carenza di personale o i processi di patch complicati sono in genere la causa alla base del mancato rispetto costante degli SLA. D'altro canto, il loro rispetto contribuisce a creare fiducia con i clienti e gli altri stakeholder, dimostrando che i difetti critici non rimangono nascosti. Ciò è in linea con le politiche di rischio più ampie e gli obiettivi di gestione delle vulnerabilità.
16. Velocità di correzione: Questo KPI misura la rapidità con cui i team possono passare dal rilevamento alla patch, in genere nell'ordine di ore o giorni. È simile all'MTTR, ma a un livello più granulare, per la velocità di ogni fase del ciclo di patch. Un'analisi più approfondita potrebbe rivelare la causa principale (ad esempio, la mancanza di strumenti di patch automatizzati o la complessità della pipeline DevOps) se la velocità si blocca frequentemente. La velocità migliora nel tempo, riducendo la probabilità di exploit riusciti.
17. Tasso di successo delle patch: Alcune patch potrebbero non funzionare o non risolvere il difetto sottostante se applicate in modo errato. Questo KPI ci mostra il numero di vulnerabilità scoperte che sono state effettivamente risolte dalle patch. Un controllo qualità accurato o conflitti di sistema minimi determinano tassi di successo elevati, mentre ripetuti fallimenti indicano incongruenze nell'ambiente o nei processi. Migliori test delle patch e un miglior coordinamento nel tempo possono aumentare i tassi di successo.
18. Rapporto tra correzioni automatiche e manuali: Gli strumenti di automazione della gestione delle vulnerabilità sono spesso utilizzati nelle configurazioni moderne per accelerare le attività di patch. Sapere quante delle vostre correzioni sono processi automatici rispetto a quelli manuali è un buon indicatore di maturità. Un rapporto di automazione più elevato implica costi generali inferiori e una risoluzione più rapida. Tuttavia, alcuni sistemi potrebbero richiedere controlli manuali approfonditi. Osservando la variazione di questo rapporto, possiamo vedere gli effetti delle nuove soluzioni di automazione o dell'integrazione DevOps.
19. Incidenti collegati a difetti non corretti: Non è raro scoprire che, dopo una violazione, la causa dell'incidente era una vulnerabilità che non era stata corretta. Questa metrica indica il numero di incidenti di sicurezza che possono essere collegati a vulnerabilità note che non sono state risolte. Se tale numero è elevato, è necessario aumentare la frequenza delle scansioni o organizzare meglio le patch. Ridurlo significa che il programma affronta in modo efficace le principali esposizioni per ridurre il potenziale di exploit nel mondo reale.
20. Riduzione complessiva del rischio nel tempo: Alla fine, è utile avere una visione d'insieme per determinare se l'esposizione complessiva al rischio dell'organizzazione sta aumentando o diminuendo. In questo modo, le vulnerabilità possono essere classificate in base alla gravità e alla criticità delle risorse e riassunte in un "punteggio di rischio" cumulativo, che può essere monitorato mensilmente o trimestralmente. Questi cambiamenti possono verificarsi contemporaneamente all'implementazione di nuovi strumenti di scansione dei container o a modifiche nelle politiche di patch. A lungo termine, i cali di rischio che si verificano regolarmente dimostrano che ogni fase della pipeline delle vulnerabilità fornisce un reale miglioramento della sicurezza.

Conclusione

La gestione dei rischi non consiste più nell'eseguire una scansione, incrociare le dita e sperare di individuare alcune vulnerabilità. Utilizzando metriche di gestione delle vulnerabilità o misurazioni coerenti, le organizzazioni quantificano la rapidità con cui sono in grado di identificare le vulnerabilità, porvi rimedio e convalidarne i risultati. Quando questi KPI sono allineati con i dati di exploit reali, i team di sicurezza ottengono un quadro chiaro dei punti di forza e di debolezza dei processi. Con migliaia di nuovi CVE ogni anno, qualsiasi informazione in grado di ridurre il tempo a disposizione per sfruttare le vulnerabilità è preziosa. Inoltre, l'integrazione di queste metriche con altri framework di sicurezza aiuta a collegare le scansioni quotidiane agli standard di gestione delle vulnerabilità a lungo termine. A lungo termine, un monitoraggio adeguato migliora la responsabilità, promuove la coesione tra i reparti e riduce al minimo i rischi ricorrenti.

"

FAQs

Cosa sono le metriche di gestione delle vulnerabilità?

Le metriche di gestione delle vulnerabilità sono misure che possono essere espresse in termini numerici, ad esempio il tempo necessario per correggere o applicare una patch di conformità, che aiutano a determinare l'efficienza dei processi di scansione e correzione di un'organizzazione. Queste metriche traducono i risultati grezzi della scansione in dati utilizzabili e consentono ai team di sicurezza di monitorare i progressi, identificare le aree problematiche e valutare i miglioramenti. L'obiettivo è garantire che i risultati del processo di scansione siano coerenti con gli obiettivi e gli scopi dell'azienda.

In che modo le organizzazioni stabiliscono le priorità delle vulnerabilità utilizzando le metriche?

Gli approcci basati sul rischio sono comuni nei team, dove la gravità è combinata con la disponibilità di exploit e la criticità delle risorse. Misure come il "numero di problemi critici risolti entro X giorni" mettono in luce le correzioni ad alta priorità. Un altro modo per decidere l'allocazione delle risorse è osservare tendenze come le vulnerabilità aperte o il tempo medio necessario per la correzione, che possono aiutare a evidenziare i problemi più pericolosi che richiedono una risoluzione rapida.

Con quale frequenza devono essere riviste le metriche di gestione delle vulnerabilità?

Esistono diversi tipi di programmi di revisione: alcune aziende optano per revisioni settimanali o mensili, mentre altre si affidano a report in tempo reale. La scansione continua può significare che le grandi imprese avranno una supervisione quotidiana delle metriche principali. La frequenza è determinata dal tasso di trasformazione del loro ambiente e dalle nuove minacce che emergono. In ambienti dinamici, le revisioni sono più frequenti per garantire che la patch sia aggiornata.

Quali sono le metriche più importanti per la gestione delle vulnerabilità?

Sebbene le circostanze di ciascuna organizzazione siano uniche, esse condividono metriche simili, quali il tempo medio di rilevamento, il tempo medio di risoluzione, i tassi di conformità delle patch e le vulnerabilità critiche e non critiche. Alcune monitorano le vulnerabilità ripetute o la gravità determinata dagli exploit. La selezione delle metriche chiave migliori per la gestione delle vulnerabilità dipende dalle dimensioni dell'ambiente, dai requisiti di conformità e dai modelli di minaccia.

Come monitorare e migliorare le metriche di gestione delle vulnerabilità?

Innanzitutto, assicurarsi che la scansione sia completa e copra tutti gli endpoint e i container. Quindi, collegare i risultati della scansione alle patch e impostare i flussi di lavoro delle patch per consentire un'azione rapida. Nel corso del tempo, misura il miglioramento delle metriche di vulnerabilità come il tempo medio di risoluzione o il numero totale di difetti non corretti. Analizzando questi dati e affrontando gli intervalli di risoluzione lenti che si verificano frequentemente, le organizzazioni possono migliorare i processi. Le riscansioni vengono utilizzate per ripetere la scansione, verificare ogni correzione e identificare altri potenziali miglioramenti.

Quali sono le sfide nella misurazione della gestione delle vulnerabilità?

Alcune organizzazioni potrebbero disporre di sistemi con sistemi operativi diversi, servizi temporanei basati su cloud o sistemi obsoleti, che potrebbero portare a scansioni parziali o a un eccesso di dati. Un'altra sfida è la capacità di dare la giusta priorità a ciascuno dei difetti che sono stati identificati. Anche la mancanza di personale o la lentezza dei processi di patch influiscono sulle metriche, ad esempio aumentando il tempo medio necessario per la correzione. Come per molti processi, la cultura o i silos dipartimentali possono ostacolare il flusso delle attività di patch e rendere difficile la misurazione in tempo reale.

Quali sono le best practice per ottimizzare le metriche di vulnerabilità?

Molte organizzazioni utilizzano un sistema di punteggio basato sul rischio per separare i rischi importanti e allocare le risorse in modo efficiente. L'uso di scansioni frequenti, l'orchestrazione automatizzata delle patch e ruoli ben definiti aiutano a ridurre al minimo il verificarsi di ritardi nelle correzioni. L'integrazione dei dati di scansione con i processi di conformità o DevOps aiuta a garantire che gli aggiornamenti vengano effettuati in modo tempestivo. La documentazione di una politica relativa alle metriche del programma di gestione delle vulnerabilità garantisce l'acquisizione e la segnalazione coerente dei dati. In questo modo, i team sono sempre preparati ad affrontare nuove minacce grazie a sessioni di revisione regolari.

In che modo le organizzazioni possono migliorare le metriche di gestione delle vulnerabilità?

Le organizzazioni possono ottimizzare i cicli di patch, integrare l'automazione per eseguire lavori ripetitivi o integrare le informazioni sulle minacce per dare priorità ai problemi più gravi. Ampliare l'ambito della scansione, ad esempio includendo i controlli dei container, fornisce un quadro più completo. Un altro approccio utile consiste nell'effettuare audit o adeguamenti periodici, soprattutto se le metriche mostrano un numero elevato di elementi che non sono stati corretti. A lungo termine, la sincronizzazione delle attività di scansione, DevOps e conformità porta a un miglioramento stabile dei KPI di gestione delle vulnerabilità.