DefenceLevel Index · Metodo v1.30

Come si calcola il DefenceLevel Index

Questa pagina descrive per intero, senza semplificazioni, la regola con cui il DefenceLevel Index assegna ogni giorno un livello da 5 a 1. La regola è deterministica: a parità di dati produce sempre lo stesso risultato, e ogni livello è accompagnato dalle ragioni che lo hanno determinato.

Versione del metodo: 1.30 · In vigore dal 4 novembre 2026 · Ultimo aggiornamento di questa pagina: 4 novembre 2026

1. Cosa misura, cosa non misura

Il DefenceLevel Index misura l'urgenza delle minacce informatiche nuove: quanto è probabile che, in un dato giorno, un'organizzazione debba intervenire in fretta su vulnerabilità di software e apparati di uso comune, perché sfruttate da attaccanti reali o sul punto di esserlo.

Non misura:

• il rischio di una singola organizzazione, che dipende da quali prodotti usa, da come li configura e da quanto è esposta su internet;
• il volume complessivo delle vulnerabilità pubblicate: migliaia ogni mese, in gran parte senza conseguenze pratiche;
• attacchi mirati a singole vittime, campagne di phishing, furti di credenziali o incidenti che non passano da una vulnerabilità software pubblica.

Un livello basso non significa che il mondo sia sicuro: significa che in quelle 24 ore non è emerso nulla di nuovo che richieda un intervento straordinario oltre la normale manutenzione.

2. La scala da 5 a 1

La scala riprende quella militare statunitense DEFCON: 5 è la condizione ordinaria, 1 la più grave. DefenceLevel non è affiliato al Dipartimento della Difesa degli Stati Uniti né alla conferenza DEF CON®, marchio di Def Con Communications, Inc.

Le condizioni esatte di ogni livello sono nella sezione 8.

3. Le fonti

Il sistema legge fonti pubbliche, divise per ruolo. Il ruolo decide due cose: quanto pesa la fonte nel segnale di attenzione e se può confermare una vulnerabilità o il suo sfruttamento. Solo enti ufficiali, CERT e produttori possono confermare che una vulnerabilità esiste; lo sfruttamento attivo possono confermarlo anche i laboratori di ricerca; stampa e social contribuiscono all'attenzione ma da soli non confermano nulla.

I dati di VulnCheck KEV sono usati secondo i termini di VulnCheck, che chiedono di citarne la fonte: VulnCheck KEV (vulncheck.com). I dati del catalogo europeo delle vulnerabilità sfruttate sono riutilizzati secondo le note legali di ENISA, citando la fonte: ENISA EUVD (euvd.enisa.europa.eu).

Arricchimento: per ogni vulnerabilità si leggono anche la probabilità di sfruttamento EPSS pubblicata da FIRST e la scheda ufficiale su cve.org.

La console in tempo reale della pagina principale mostra quante fonti hanno risposto nelle ultime 24 ore. L'elenco si amplia nel tempo: ogni aggiunta è registrata nella sezione 14.

4. Il ciclo di raccolta

• Ogni 30 minuti: fonti veloci (ricerca, stampa, exploit pubblici, codice, social).
• Ogni ora: fonti ufficiali e produttori (NVD, CISA KEV, Microsoft, GitHub Advisories, CERT, avvisi dei produttori).
• Ogni 12 ore: Wordfence Intelligence, la banca dati delle vulnerabilità di plugin e temi WordPress.
• A ogni raccolta ogni vulnerabilità toccata viene rivalutata e il livello attuale viene ricalcolato sulle ultime 24 ore.
• Alle 04:00 UTC, ogni giorno dell'anno, vengono fissati il livello del giorno e il contenuto del briefing, con i dati raccolti fino a quel momento; alle 05:00 UTC, dopo la verifica, il briefing parte agli abbonati.

Ogni segnalazione raccolta registra una fonte, un istante, una o più vulnerabilità citate (identificate dal codice CVE), e alcuni indicatori ricavati dal testo, come la menzione esplicita di sfruttamento attivo. Le segnalazioni non si cancellano: il calcolo usa sempre la storia completa. Una segnalazione attribuita per errore a una vulnerabilità, per esempio un avviso su altre vulnerabilità che la cita solo come contesto, dopo la verifica viene esclusa dal calcolo per quella vulnerabilità: la correzione resta registrata e il livello si ricalcola con le stesse regole. Nei bollettini su più vulnerabilità, una già sfruttata da almeno 7 giorni (catalogo KEV o prima conferma), citata accanto ad altre nuove (pubblicate da meno di 14 giorni o non ancora pubblicate) e non nominata nel titolo dell'avviso, è un rimando e non un segnale: quella segnalazione non conta per lei. Un avviso ufficiale o del produttore uscito nelle 48 ore dopo la pubblicazione della vulnerabilità è l'avviso su di lei: si esclude solo se le attribuisce per errore uno sfruttamento. Il comunicato di CISA sull'ingresso nel catalogo KEV vale solo per le vulnerabilità che il catalogo ha con la sua data (o con il giorno prima, per il fuso): per le altre che cita non conta.

5. L'analisi di ogni vulnerabilità

Ogni vulnerabilità viene valutata su quattro assi, ciascuno da 0 a 10.

5.1 Gravità tecnica (S)

È il punteggio CVSS ufficiale. Se la scheda CVE non è ancora pubblicata ma un avviso ufficiale, di un CERT nazionale o del produttore, conferma la vulnerabilità, vale la gravità scritta nell'avviso: il punteggio CVSS, oppure il minimo della classe indicata (critica 9, alta 7, media 4, bassa 0,1); dallo stesso avviso si prendono il prodotto colpito e l'indicazione di un attacco senza credenziali. Altrimenti è stimato dalla categoria della vulnerabilità (per esempio: esecuzione di codice remoto 9; aggiramento dell'autenticazione 8,5; scrittura di file arbitrari 8,5; scalata di privilegi 7,5; divulgazione di informazioni 5,5; cross-site scripting 4,5), con −1 se servono prerequisiti difficili (credenziali amministrative, accesso locale o fisico) e +0,5 se è attaccabile da rete senza credenziali. «Attaccabile da rete senza credenziali» viene dal vettore CVSS, ma non vale se il produttore scrive che serve un accesso locale, privilegi o un account già ottenuti, o un client autenticato: allora contano i prerequisiti difficili. Se la scheda CVE non ha produttore né prodotto, valgono quelli che i cataloghi delle vulnerabilità sfruttate ed ENISA EUVD scrivono in forma strutturata; poi i prodotti colpiti scritti nella scheda stessa o da NVD, se nominano un solo produttore (con i soli prodotti di una distribuzione Linux, che include il componente, vale la valutazione più grave); senza questi, il prodotto nominato nei titoli degli avvisi e dei cataloghi, con il suo produttore quando è un prodotto noto. Se non ha descrizione, la categoria si prende dai titoli degli avvisi.

5.2 Sfruttamento reale (E)

Dipende dallo stato più avanzato documentato:

Il valore sale fino a 10 × EPSS se la probabilità EPSS è più alta, e almeno a 6 se la vulnerabilità è nel 5% più probabile secondo EPSS. Scende di 1,5 se servono prerequisiti difficili (salvo sfruttamento attivo) e di 1 se la complessità d'attacco CVSS è alta.

«Sfruttamento attivo» in un testo si riconosce da espressioni esplicite («exploited in the wild», «actively exploited», «under active exploitation» e simili). Vale solo se la fonte è ufficiale, di un produttore o di ricerca; se lo afferma solo la stampa, o lo riportano almeno due account social diversi, la vulnerabilità resta in osservazione con la dicitura «sfruttamento riportato, non confermato», e non finisce mai fra il rumore. L'espressione si riconosce anche in italiano, francese, spagnolo, tedesco e olandese, le lingue dei CERT letti, e non vale se è negata («non risulta sfruttata», «n'a pas connaissance d'exploitation»). Nei bollettini su più vulnerabilità vale solo per quelle nominate nella frase che parla di sfruttamento; se la frase non ne nomina nessuna, vale per tutte se sono al massimo tre e, se sono di più, solo per quella del paragrafo in cui si trova la frase, quando il bollettino le descrive una per una. Un articolo di stampa o un post sui social che nel titolo o nelle prime righe nomina solo altre CVE non conta come segnalazione di attacchi per le vulnerabilità che cita più avanti, salvo che la frase sullo sfruttamento le nomini. Nei riassunti a elenco vale solo per la vulnerabilità della riga che la contiene, e non vale quando descrive soltanto ciò che la falla permetterebbe («lets attackers…»). Un articolo di ricerca che nel titolo nomina altre CVE e non questa ne parla come contesto: per questa non è un segnale. Un articolo di ricerca o di stampa su una vulnerabilità nel catalogo CISA KEV da oltre 30 giorni ne parla come contesto e per lei non conta, salvo che il titolo o l'indirizzo nomini la vulnerabilità, il suo prodotto o il suo produttore, o parli di attacchi, o che, in un testo su più vulnerabilità, la frase sullo sfruttamento la nomini. Lo stesso vale per qualsiasi vulnerabilità quando un articolo di ricerca cita solo quella, senza nominare nel titolo o nell'indirizzo lei, il suo prodotto o il suo produttore e senza riferire attacchi: ne parla come contesto e, come un rimando, per lei non conta.

5.3 Impatto (I)

Parte dalla categoria (esecuzione di codice 9,5; aggiramento dell'autenticazione 9; compromissione della catena di fornitura 9; scrittura di file arbitrari 8,5; scalata di privilegi, corruzione di memoria, SQL injection 7; …) e si corregge con la diffusione del prodotto (vedi sezione 6): +1,5 componenti presenti quasi ovunque, +1 apparati di confine, 0 prodotti comuni, −1,5 prodotti di nicchia, −4 generatori di vulnerabilità a basso impatto. +1 se è usata da gruppi ransomware secondo CISA, +0,5 se attaccabile da rete senza credenziali. L'esecuzione di comandi arbitrari conta come esecuzione di codice, anche quando è l'effetto di una SQL injection.

5.4 Attenzione (Z)

Misura quanto se ne discute fra professionisti nelle ultime 24 ore. Contano le menzioni di ricerca, codice, stampa e social, ciascuna con il peso del suo ruolo (tabella della sezione 3), e ogni account, testata o autore conta una volta sola, con il peso più alto fra le sue menzioni, anche quando scrive su più social con lo stesso nome utente; gli avvisi ufficiali, dei produttori e degli archivi di exploit entrano già nella gravità e nello sfruttamento, e qui non contano:

Il logaritmo impedisce che mille post ripetuti valgano mille volte uno solo.

Non contano gli account che ripubblicano le schede delle vulnerabilità invece di discuterne: quelli che nei 7 giorni prima hanno scritto di almeno 20 vulnerabilità diverse, salvo gli account autorevoli della sezione 3. Lo stesso testo pubblicato da account diversi a pochi minuti di distanza, come fa una redazione con più profili, conta come un account solo.

5.5 Punteggio combinato

I pesi privilegiano gravità e sfruttamento reale; l'attenzione pesa solo il 10%, per non premiare il clamore. Sono scelte di metodo, dichiarate qui e verificate a posteriori (sezione 12). Il punteggio serve a scegliere quali vulnerabilità entrano nel briefing (7,0 per le principali, 5,8 per «da tenere d'occhio»); il livello, invece, segue le regole esplicite della sezione 8.

6. Prodotti diffusi e presi di mira

Una vulnerabilità conta di più se colpisce un prodotto usato da molte organizzazioni e storicamente nel mirino degli attaccanti. La classificazione unisce un elenco pubblico per tipo di prodotto e un dato oggettivo di storico degli attacchi:

Lo storico degli attacchi è ricavato dal catalogo CISA Known Exploited Vulnerabilities: si contano le vulnerabilità con sfruttamento confermato aggiunte negli ultimi 5 anni. Il conteggio si rifà da solo il primo giorno di ogni mese (UTC) e resta fisso per tutto il mese; la fotografia di ogni mese viene conservata. Così un prodotto che gli attaccanti prendono di mira entra nella classificazione anche se non era nell'elenco, e un prodotto dell'elenco senza storico di attacchi non viene sopravvalutato. Il produttore si riconosce senza la forma societaria, comunque la scriva la fonte: «PHP Group» è PHP, «SAP SE» è SAP, «IBM Corporation» è IBM.

La classe dall'elenco vale per i prodotti di chi produce la piattaforma: Windows di Microsoft, Android di Google o dei produttori che lo installano sui propri telefoni, i componenti di sistema (OpenSSL, glibc, sudo…) anche delle distribuzioni Linux che li includono. Un prodotto di terzi che ne cita il nome non la eredita: una libreria Python non è Python, un'app per Android non è Android. Nemmeno un progetto che porta nel nome la piattaforma unita da un trattino a un'altra parola (node-openssl non è OpenSSL), che non prende neppure lo storico degli attacchi del suo produttore, salvo che il prodotto porti da solo il nome della piattaforma. Lo stesso vale per i componenti aggiuntivi (plugin, estensioni, temi, add-on): un plugin per WordPress non è WordPress. Questi prodotti si classificano a sé, con il proprio storico degli attacchi. Produttore e prodotto sono quelli della scheda CVE, salvo due casi in cui valgono quelli del catalogo CISA KEV: la scheda elenca più di tre prodotti (Microsoft elenca ogni versione di Windows), oppure indica un produttore senza legame con quello del catalogo, di solito un prodotto che incorpora il componente colpito (Apache Struts, non l'apparato Huawei che lo contiene). I nomi generici del catalogo («Multiple Products») non valgono mai.

Una vulnerabilità che colpisce più prodotti dello stesso produttore si valuta con la classe di ciascuno e vale il risultato più grave: una falla di Bamboo che colpisce anche Confluence e Jira conta come una falla di un apparato di confine. I prodotti colpiti sono quelli indicati dalle fonti ufficiali (scheda CVE, NVD, catalogo CISA KEV, avvisi dei produttori), esclusi quelli che la scheda dichiara non colpiti; i prodotti di altri produttori, come i sistemi che includono una libreria colpita, e i nomi generici del catalogo non contano.

Per i produttori con un catalogo ampio (Cisco, Fortinet, Ivanti, Citrix, Palo Alto Networks, F5, Juniper, VMware, ConnectWise) il nome del produttore nell'elenco degli apparati di confine vale solo per i suoi prodotti con uno storico di attacchi proprio, almeno 2 vulnerabilità sfruttate in 5 anni: un firewall Cisco sì, uno switch da data center o un server di licenze no. Gli altri suoi prodotti contano come prodotti comuni.

Switch e access point della rete interna non sono apparati di confine, anche dei produttori i cui prodotti per il resto contano come tali: sono prodotti comuni. Si riconoscono dal nome del prodotto o, per Zyxel, dalla sigla del modello.

Un produttore che è il marchio di un prodotto noto (per esempio NetScaler, di Citrix) vale come quel prodotto del suo proprietario, con il suo storico. Il kernel Linux conta come tale anche quando la scheda CVE lo chiama solo «Linux».

7. Il contenimento dell'allarmismo

Una vulnerabilità non può alzare il livello se rientra in uno di questi casi:

• Non confermata: se ne parla molto, ma nessuna fonte ufficiale o produttore l'ha confermata. Se però la stampa riferisce un aggiornamento di sicurezza del produttore, va fra quelle da tenere d'occhio.
• Respinta o contestata nel registro CVE, salvo che sia nel catalogo CISA KEV o abbia un avviso del produttore: allora si valuta come le altre.
• Sensazionalistica: linguaggio da titolo («catastrofica», «miliardi di dispositivi a rischio»…), nessuno sfruttamento né exploit credibile, gravità sotto 7 o prodotto di nicchia, quando l'attenzione non si spiega con un avviso ufficiale o del produttore degli ultimi 3 giorni.
• Exploit falso o non verificato molto condiviso, con gravità sotto 9, quando l'attenzione non si spiega con un avviso ufficiale o del produttore degli ultimi 3 giorni.

Questi casi finiscono nella sezione «Molto discusse, ma senza motivo di allarme oggi» del briefing, con la spiegazione del perché non sono un'emergenza. Fa eccezione una vulnerabilità di cui la stampa, o almeno due account social diversi, riportano attacchi: anche se non sono confermati, va fra quelle da tenere d'occhio, mai in questa sezione. La redazione può spostare una voce da questa sezione a quelle da tenere d'occhio, mai il contrario; nessun livello cambia.

Inoltre, una vulnerabilità vecchia (pubblicata da oltre un anno, o con codice CVE di due anni prima) non è una notizia, a meno che CISA non ne abbia appena confermato lo sfruttamento: in quel caso può arrivare al massimo al livello 3.

8. Il livello di ogni vulnerabilità

Le condizioni sono valutate dall'alto in basso; vale la prima soddisfatta. Solo le vulnerabilità confermate e non classificate come rumore possono superare il livello 5.

«Recente» significa: inserita nel catalogo KEV non più di 14 giorni fa, oppure pubblicata non più di 30 giorni fa, oppure con una nuova segnalazione di sfruttamento da fonte ufficiale, di produttore o di ricerca nelle ultime 72 ore. Uno sfruttamento noto da tempo è un problema già conosciuto, non una notizia.

Fonti indipendenti (attenzione ampia del livello 2 e mezzo punto dell'attenzione): ogni fonte conta una volta; i social insieme valgono una fonte sola, perché quanto se ne discute lo misura già l'attenzione; il comunicato di CISA sull'ingresso nel catalogo KEV è il catalogo KEV; il catalogo VulnCheck KEV non conta se le prove che cita vengono da una fonte già presente. Lo stesso nome utente su più social è un autore solo.

Il livello 2 distingue l'attacco a un prodotto da una minaccia ad ampio impatto. Un apparato di confine sotto attacco (un firewall, una VPN, un gateway di un certo produttore) è un'emergenza per chi lo usa: chi l'ha fra i suoi prodotti in My Defence, con «Solo i miei prodotti», riceve subito l'avviso, e tutti la trovano nel briefing del giorno; ma da solo non porta l'indice globale a rischio grave, che resta riservato ai componenti presenti ovunque e alle campagne documentate da più fonti.

Ne segue che una vulnerabilità grave su un prodotto diffuso non scende mai al livello 5, e che una vulnerabilità critica con exploit pubblico su un prodotto diffuso è almeno al livello 3 anche prima che si osservino attacchi.

9. Il livello del giorno

9.1 Il livello in un dato momento

In ogni momento il livello è il più grave fra quelli delle vulnerabilità del briefing: le novità e quelle ancora in corso, queste un gradino sotto:

Vulnerabilità principali sono quelle confermate con punteggio combinato almeno 7,0 oppure con livello 3 o più grave. Lo sono anche, senza bisogno di attacchi noti, quelle di gravità critica (≥ 9) su un apparato di confine, attaccabili da rete senza credenziali e pubblicate da non più di 30 giorni: tengono il loro livello e portano l'indicazione di aggiornare entro la settimana. Quelle «da tenere d'occhio» compaiono nel briefing ma non determinano il livello. Una segnalazione senza codice CVE su un prodotto che ha già nel briefing una vulnerabilità con il suo codice CVE è la stessa notizia: non compare né come voce a sé né fra quelle da tenere d'occhio. Le vulnerabilità di prodotti classificati come rumore non sono mai principali, salvo che siano nel catalogo CISA KEV. Le vulnerabilità dello stesso prodotto citate insieme a una vulnerabilità principale nello stesso avviso ufficiale, del produttore o di ricerca degli ultimi 7 giorni, con al massimo 5 vulnerabilità, entrano nella sua voce anche se da sole non sarebbero selezionate: sono la stessa catena di attacco. Il livello del giorno non cambia.

L'attualità si misura dal momento più recente fra: pubblicazione della vulnerabilità, inserimento nel catalogo KEV (+12 ore), ultimo segnale ufficiale, di produttore, di ricerca o di exploit, e «adesso» se nelle ultime 24 ore ci sono almeno 3 menzioni. Una vulnerabilità di cui si continua a parlare resta quindi di attualità; una di cui non si parla più esce dal calcolo. Un avviso ripubblicato dalla stessa fonte con lo stesso titolo entro 30 giorni non è un segnale nuovo; un aggiornamento con un titolo diverso sì. La data di ogni segnalazione è quella in cui la fonte l'ha pubblicata; una voce senza data leggibile conta come nuova solo la prima volta che compare. Una segnalazione senza una data affidabile (illeggibile, precedente al 1999, di più di un giorno nel futuro, oppure uguale al millesimo in almeno tre avvisi diversi della stessa fonte su vulnerabilità diverse: è l'ora in cui la fonte ha aggiornato il feed) vale per quello che dice, non per il quando: non rende di attualità una vulnerabilità e non ne conferma lo sfruttamento, che resta riportato e non confermato finché non lo conferma una fonte con la data.

Per restare a livello 1 o 2, e a livello 3 per sfruttamento attivo, però, una vulnerabilità deve avere un segnale forte nelle ultime 24 ore: pubblicazione, inserimento nel catalogo KEV (+12 ore), segnale ufficiale, di produttore, di ricerca o di exploit. Se è di attualità solo perché se ne discute, vale un gradino sotto, nel livello del giorno e nel briefing.

A livello 4 o 5, una vulnerabilità di attualità solo perché se ne discute, senza segnali forti da oltre 7 giorni, non è fra le principali: compare fra quelle da tenere d'occhio e non determina il livello.

Novità delle ultime 24 ore. Fra le vulnerabilità principali di attualità nelle ultime 24 ore sono novità quelle mai uscite fra le voci dei briefing dei 30 giorni prima, quelle con un segnale forte nelle ultime 24 ore e quelle con un livello più grave dell'ultima volta, salvo che a farlo salire siano solo le discussioni. Una vulnerabilità già segnalata che torna di attualità solo perché se ne discute, sui social o sulla stampa, non è una novità e non torna nel briefing; se le discussioni ne hanno alzato il livello, compare in una riga, come quelle ancora in corso, che lo dice. La stessa regola vale per le vulnerabilità da tenere d'occhio: una già uscita nei briefing dei 30 giorni prima torna solo con un segnale forte nelle ultime 24 ore. Una vulnerabilità mai segnalata di cui nelle ultime 24 ore si è solo discusso va fra quelle da tenere d'occhio, salvo che sia a livello 1–3 (sfruttata, o critica con un exploit pubblico): allora è una novità, anche se era già fra quelle da tenere d'occhio. Una vulnerabilità di oltre un anno, nel catalogo CISA KEV da più di 30 giorni, torna fra quelle da tenere d'occhio solo con un segnale forte negli ultimi 7 giorni o se nelle ultime 24 ore ne hanno scritto almeno due account.

Ancora in corso. Una vulnerabilità sfruttata attivamente a livello 1–3, già segnalata e senza segnali forti nelle ultime 24 ore, resta nel briefing per 72 ore dall'ultimo segnale forte, in una riga, anche se nessuno ne parla; l'ultimo giorno la riga lo dice. Nel livello vale un gradino sotto: chi non ha ancora aggiornato è ancora esposto. Con un nuovo segnale forte torna fra le novità. Se il suo prodotto ha una novità, compare nella stessa voce. Le altre vulnerabilità già segnalate e senza novità escono dal briefing.

Altre vulnerabilità sfruttate. Le novità del briefing sono al massimo 8, le più gravi, e le righe «ancora in corso» al massimo 8. Le vulnerabilità sfruttate attivamente (sfruttamento confermato o catalogo KEV) che restano fuori compaiono in una sezione a parte, una riga per vulnerabilità, dalla più grave, al massimo 60; le altre restano fuori. Il livello del giorno le comprende già. Contano come segnalate: come le altre, tornano fra le novità solo con un segnale forte nelle ultime 24 ore o con un livello più grave.

Sotto il livello, il briefing dice com'era nel briefing precedente e quali vulnerabilità lo determinano.

Quando il briefing riporta un prodotto, richiama anche le altre vulnerabilità dello stesso prodotto sfruttate negli ultimi 60 giorni (catalogo KEV o primo sfruttamento) che oggi non sono nel briefing: al massimo 6, le più recenti, con la data da cui sono sfruttate. È solo un richiamo: non cambia il livello del prodotto nel briefing né quello del giorno.

9.2 Il livello del giorno nell'indice

Il livello di un giorno (giorno di calendario in UTC) è quello fissato alle 04:00 UTC e comunicato agli abbonati nel briefing delle 05:00 di quel giorno. Non cambia più. Se nel corso della giornata le raccolte rilevano un livello più grave, l'indice lo mostra come picco del giorno, con l'ora in UTC, senza cambiare il livello del giorno.

Il livello attuale mostrato dal vivo si ricalcola invece a ogni raccolta: un'emergenza che emerge dopo il briefing compare subito nel livello attuale, viene comunicata agli abbonati con un avviso immediato, e nell'indice appare nel giorno successivo.

Gli avvisi partono a DEFCON 1, 2 e 3: il DEFCON 1 a tutti gli abbonati; il DEFCON 2 a chi riceve tutti gli avvisi e, a chi ha scelto «Solo i miei prodotti» in My Defence, solo se riguarda i suoi prodotti; il DEFCON 3 solo a chi ha scelto «Solo i miei prodotti», e solo se riguarda i suoi prodotti. A DEFCON 4 e 5 non parte nessun avviso: le vulnerabilità sono nel briefing del giorno. Gli avvisi partono solo con un segnale forte arrivato nelle ultime 24 ore. Se la vulnerabilità era già fra le voci del briefing e da allora non è arrivato un segnale forte nuovo, un livello più grave raggiunto dopo (per esempio perché se ne discute di più) non fa partire un avviso a DEFCON 2 o 3: lo riporta il briefing successivo. Il DEFCON 1 parte sempre. Se lo sfruttamento è confermato soltanto dal catalogo VulnCheck KEV e le prove che cita sono solo post sui social, pagine di aggregatori o banche dati delle vulnerabilità (come la scheda CVE), che descrivono la falla ma non provano un attacco, la vulnerabilità resta nel briefing al suo livello, ma l'avviso aspetta una seconda fonte: il catalogo CISA KEV, un CERT, il produttore o una ricerca.

Nelle 24 ore dopo un avviso a DEFCON 1 o 2, la vulnerabilità non scende sotto il livello che aveva all'ora dell'avviso solo perché il tempo passa, per esempio perché le menzioni escono dalle 24 ore: quel livello si ricalcola con i dati di adesso, e scende solo se è cambiato un fatto, come una segnalazione esclusa dopo la verifica, una CVE respinta o un CVSS ufficiale più basso. Nel briefing di quelle 24 ore l'avviso vale come un segnale forte: la vulnerabilità resta fra le novità, al livello dell'avviso.

10. Il ruolo dell'intelligenza artificiale

Il livello, la selezione e l'ordine delle vulnerabilità sono calcolati solo dalla regola deterministica descritta in questa pagina: a parità di dati, il risultato è sempre lo stesso, e l'intelligenza artificiale non li decide mai. La usiamo per la redazione: prima dell'invio, un sistema di intelligenza artificiale verifica ogni briefing e ogni avviso sui nostri dati (prodotti, prove di sfruttamento, date, precondizioni) e ne scrive i testi. Se trova una segnalazione attribuita alla vulnerabilità sbagliata, la esclude, e il livello viene ricalcolato dalla regola. Se i dati non confermano un avviso, l'avviso non parte. Briefing e avvisi partono solo a verifica completata: se non è pronta, l'invio aspetta.

11. Lo storico dell'indice

Il livello di ogni giorno è calcolato con le regole descritte in questa pagina, usando solo i dati che le fonti avevano pubblicato fino a quel giorno: nessuna informazione successiva entra nel livello di un giorno passato.

12. La verifica dei risultati

Verifichiamo il metodo confrontando i suoi livelli con il catalogo CISA KEV, l'elenco delle vulnerabilità di cui è confermato lo sfruttamento reale. Misuriamo quante vulnerabilità sfruttate il metodo porta almeno a livello 3, con quale anticipo o ritardo rispetto alla conferma ufficiale, e quante di quelle portate a livello 2 o 1 risultano davvero sfruttate.

La verifica si fa in due modi, con il catalogo fra le fonti, come lavora il servizio, e senza, come controllo indipendente, e si ripete a ogni versione del metodo.

13. Limiti dichiarati

• Copertura delle fonti. Il sistema vede solo ciò che è pubblico e scritto nelle fonti lette. Attacchi non ancora divulgati, o divulgati solo in canali chiusi, non sono visibili.
• Dipendenza dal codice CVE. Vulnerabilità senza codice CVE sono riconosciute solo se citano un prodotto noto; possono essere sottostimate. I nomi di prodotto che sono anche parole comuni (Teams, Outlook, Zoom, Entra) contano solo con il produttore o una parola che li qualifica, come «Microsoft Teams». Un exploit senza CVE, da solo, non alza il livello: conta solo insieme ad altri segnali sullo stesso prodotto.
• Riconoscimento del linguaggio. Lo sfruttamento attivo nei testi è riconosciuto da espressioni esplicite in sei lingue (inglese, italiano, francese, spagnolo, tedesco, olandese); formulazioni insolite o altre lingue possono sfuggire.
• Pesi e soglie. Sono scelte di metodo, non grandezze fisiche: sono dichiarati, stabili nel tempo e verificati a posteriori, ma un metodo diverso darebbe livelli diversi.
• Storico degli attacchi. Il catalogo CISA KEV riflette le priorità del governo statunitense e la sua capacità di confermare; prodotti molto usati fuori dagli Stati Uniti possono esservi sottorappresentati.
• Prodotti con nomi diversi. Il confronto fra nomi di produttori e prodotti nelle diverse fonti è automatico e può sbagliare nei casi ambigui.
• Livelli prima del 1° ottobre 2026. Dipendono da quanto le fonti conservano dei giorni passati: alcune fonti non hanno uno storico consultabile e, per un confronto equo nel tempo, i social contano solo per gli hashtag con storico completo (#vulnerability, #zeroday), con al massimo 30 menzioni al giorno. I livelli di quel periodo possono quindi sottostimare il rischio.

14. Versioni e modifiche

Il metodo ha un numero di versione. Ogni modifica che può cambiare un livello è registrata qui con la data; i livelli già pubblicati non vengono riscritti in silenzio: se una nuova versione cambia livelli passati, lo dichiara.

15. Uso dei dati e citazione

I livelli giornalieri sono pubblici e riutilizzabili con licenza Creative Commons Attribution 4.0 (CC BY 4.0), citando la fonte. Il file CSV degli ultimi 12 mesi si scarica dalla pagina del DefenceLevel Index e contiene data, livello, nome del livello e numero di vulnerabilità incluse nel briefing.

Citazione suggerita: DefenceLevel Index (defencelevel.com), metodo v1.30, con la data del dato.

I dettagli delle singole vulnerabilità (nomi, prodotti, azioni consigliate) sono riservati agli abbonati del briefing.