--- title: "Perché Guardian360 sta sostituendo il suo motore di scanning, e perché “meno” significherà “più sicuro” | Guardian360" description: "Se lavori con i vulnerability scanner da un po', conosci lo schema: lanci uno scan, ottieni un elenco enorme, ordini per gravità e inizi a rincorrere i rossi. Funziona, finché non…" url: https://guardian360.net/it/blog/why-guardian360-is-replacing-its-scanning-engine-and-why-less-will-mean-safer/ locale: en source: guardian360.net --- [← Tutti i post](https://guardian360.net/it/blog/) Consapevolezza # Perché Guardian360 sta sostituendo il suo motore di scanning, e perché “meno” significherà “più sicuro” Di Guardian360 · 16 gennaio 2026 Se lavori con i vulnerability scanner da un po', conosci lo schema: lanci uno scan, ottieni un elenco enorme, ordini per gravità e inizi a rincorrere i rossi. Funziona, *finché* non smette di funzionare. Perché la realtà nel 2026 è questa: i dati sulle vulnerabilità stanno esplodendo, il comportamento degli attaccanti cambia rapidamente e la risorsa più scarsa nella maggior parte dei team IT non sono gli strumenti… è il tempo. Ecco perché Guardian360 sta apportando due grandi cambiamenti a Lighthouse: 1. Stiamo sostituendo il nostro arsenale di scanner (la nostra "sala macchine" dello scanning). 2. Stiamo introducendo un approccio risk-based che collega i risultati tecnici al rischio di business, allineato a ISO 27001, NIS2 e altri framework. E sì: per molti partner e clienti, questo solleverà una domanda legittima: **"Vedremo meno vulnerabilità… ed è davvero sicuro?"** Analizziamo il "perché" dietro queste decisioni, e perché risultati meno numerosi ma più rilevanti portano tipicamente a esiti migliori, insight migliori e un uso molto più efficace di ore costose. ## 1. Perché stiamo sostituendo il nostro arsenale di scanner Stiamo ricostruendo le fondamenta per rendere lo scanning: - **Più affidabile** (risultati coerenti, meno sorprese nei casi limite) - **Più veloce** (meno attese, più visibilità continua) - **Più leggero** (minore impronta e minori oneri operativi) E c'è anche una ragione strategica: **Andare oltre le macchine virtuali verso un agent** Oggi molte soluzioni di scanning si affidano ancora pesantemente a macchine virtuali e deployment ingombranti. La nostra direzione è chiara: **abilitare capacità basate su agent**, così che partner e clienti possano ottenere copertura senza dover sempre mantenere appliance virtuali come approccio di default. Non è cambiamento per il gusto di cambiare. Si tratta di costruire una piattaforma di scanning pronta per la prossima fase di Lighthouse: **insight continui, minore attrito operativo e risultati più concreti.** ## 2. Perché stiamo introducendo un approccio risk-based (e perché si adatta meglio a ISO 27001 e NIS2) La maggior parte degli scanner è costruita per rispondere a una domanda tecnica: "Quanto è grave questa vulnerabilità?" Ma ISO 27001, NIS2 e la governance di sicurezza moderna richiedono di rispondere a una domanda diversa: "E allora cosa significa questo per la nostra organizzazione, e cosa facciamo per primo?" Questo cambiamento conta, perché la gravità tecnica da sola non descrive il rischio di business. Il rischio di business dipende dal contesto: dove risiede la vulnerabilità, cosa tocca e cosa succede se viene sfruttata. ### CIA: l'ingrediente mancante nella gestione delle vulnerabilità "basata solo sulla gravità" Un modo pratico per rendere esplicito quel contesto è la classica triade CIA: - **Confidenzialità**: lo sfruttamento esporrebbe informazioni sensibili (dati dei clienti, proprietà intellettuale, credenziali, cartelle mediche)? - **Integrità**: lo sfruttamento potrebbe consentire manomissioni (modificare dati, manipolare transazioni, alterare configurazioni, avvelenare i log)? - **Disponibilità**: lo sfruttamento potrebbe causare downtime o interruzioni (impatto ransomware, interruzione del servizio, fermo della produzione)? In altre parole: la stessa CVE può significare *cose molto diverse* a seconda del profilo CIA dell'asset. Esempio: stessa vulnerabilità, diverso rischio di business Una vulnerabilità "ad alta gravità" su un server di test di scarso valore può essere fastidiosa, ma non mette a rischio il business. Quella stessa identica vulnerabilità su: - un sistema che elabora le buste paga (integrità), - un portale clienti con dati personali (confidenzialità), - o un'applicazione critica per un ospedale (disponibilità), …diventa improvvisamente un rischio di business rilevante. Quindi, invece di trattare ogni risultato come uguale e ordinare puramente per CVSS, un approccio risk-based chiede: - Quale asset è interessato? - Quanto è critico quell'asset per confidenzialità, integrità e disponibilità? - È raggiungibile / sfruttabile in questo ambiente? - Qual è l'impatto reale se viene sfruttata? - Qual è l'azione successiva più efficace? **Perché questo si adatta meglio a ISO 27001 e NIS2** ISO 27001 non è uno standard del tipo "raccogli tutte le vulnerabilità". Riguarda la gestione di un ISMS che identifica, valuta e tratta il rischio in modo controllato e ripetibile. Un approccio risk-based lo supporta direttamente: puoi mostrare *perché* hai dato priorità a qualcosa, *cosa* hai fatto e *come* questo ha ridotto il rischio. NIS2 spinge le organizzazioni verso una resilienza misurabile e una gestione del rischio responsabile, non solo verso l'output tecnico. Un approccio risk-based aiuta partner e clienti a comunicare in termini di business, perché i consigli di amministrazione e gli auditor non vogliono "abbiamo avuto 8.000 risultati", vogliono "abbiamo ridotto il rischio per i servizi critici". Il risultato: decisioni migliori, prove migliori, meno sforzi sprecati Collegando i risultati alla CIA e al contesto di business, Lighthouse può passare da: - "Ecco un elenco spaventoso" a: - "Ecco i problemi che mettono in pericolo ciò a cui tieni davvero, ed ecco l'ordine più intelligente per risolverli." Questo è il cuore dell'approccio risk-based: non meno controlli, ma una migliore prioritizzazione e una governance più solida. ## 3. La verità scomoda: non tutte le CVE contano per il tuo ambiente Ecco la parte che spesso si perde nella gestione delle vulnerabilità: **l'universo delle CVE è enorme**, e la maggior parte non conterà mai per lo specifico ambiente del tuo cliente. - Il National Vulnerability Database (NVD) elenca **centinaia di migliaia di CVE** (oltre 326k al momento della scrittura)( [https://nvd.nist.gov/general/nvd-dashboard](https://nvd.nist.gov/general/nvd-dashboard)). - Nel frattempo, il catalogo CISA Known Exploited Vulnerabilities (KEV), un riferimento pratico del tipo "questo è sfruttato in the wild", contiene **circa 1.484 voci** (dati di fine 2025)( [https://www.securityweek.com/cisa-kev-catalog-expanded-20-in-2025-topping-1480-entries](https://www.securityweek.com/cisa-kev-catalog-expanded-20-in-2025-topping-1480-entries)). Quel contrasto non significa "ignora tutto il resto". Significa: **La gravità non è la stessa cosa del rischio** Un punteggio CVSS ti dice quanto qualcosa *potrebbe* essere grave sotto certe ipotesi. **Non** ti dice quanto è probabile che venga sfruttato nei prossimi giorni o settimane. Ecco perché esistono modelli come EPSS: per stimare la probabilità di sfruttamento in base a segnali e schemi osservati. La documentazione EPSS di FIRST illustra come l'attività di sfruttamento tenda a concentrarsi in un piccolo sottoinsieme delle CVE pubblicate (il loro esempio mostra circa il 2,7% con attività di sfruttamento osservata in una finestra di 30 giorni)( [https://www.first.org/epss/model](https://www.first.org/epss/model)). E i report sulle minacce continuano a mostrare che lo sfruttamento è un importante vettore di accesso iniziale, ma ancora una volta concentrato dove gli attaccanti ottengono il miglior ROI. Il DBIR 2025 di Verizon evidenzia lo sfruttamento delle vulnerabilità come uno dei principali vettori di violazione (20%) e segnala un aumento significativo anno su anno ([https://www.verizon.com/about/news/2025-data-breach-investigations-report](https://www.verizon.com/about/news/2025-data-breach-investigations-report)). Quindi sì: **le vulnerabilità contano**. Ma **non allo stesso modo**, e non tutte insieme. ## 4. Perché "meno vulnerabilità" può portare a esiti di sicurezza migliori Un elenco enorme di risultati crea tre problemi prevedibili: **1) Il rumore seppellisce il segnale** Quando tutto sembra urgente, niente è urgente. I team consumano cicli nel fare triage di elementi tecnicamente validi ma praticamente irrilevanti. **2) Il tempo si spende su ciò che è facile, non su ciò che è rischioso** Senza contesto di business, la remediation diventa una gara di popolarità del patching: "prima il CVSS più alto", anche se il sistema interessato non è critico o non è raggiungibile. **3) La reportistica diventa una recita** Finisci per dimostrare di aver *lavorato sodo*, invece di dimostrare di aver *ridotto il rischio*. Un approccio risk-based ribalta tutto questo: - Concentrati su **ciò che è sfruttabile**, **raggiungibile** e **rilevante** - Collega i risultati all'**impatto di business** - Rendi la remediation **misurabile**, **spiegabile** e **verificabile** Ecco come rendi la gestione delle vulnerabilità sostenibile, non eroica. ## 5. Cosa possono aspettarsi i partner in Lighthouse Con le nuove fondamenta di scanning e l'approccio risk-based, i partner otterranno: - **Una migliore comprensione del rischio di business** (oltre ai livelli di gravità tecnica) - **Risultati di scan più rilevanti**, riducendo gli sforzi sprecati - **Una remediation più efficace**, perché le azioni sono ordinate per rischio reale e contesto di business - **Prove di conformità più solide**, perché decisioni e azioni possono essere spiegate e mappate sui requisiti di governance È così che diamo significato pratico alla nostra missione: **"Governance e resilienza digitale a portata di mano."** E alla nostra visione: **"Dare ai decisori gli insight per proteggere, rispettare le norme e ottimizzare il proprio business."** ## 6. In sostanza Non puntiamo a mostrare *più* risultati. Puntiamo a mostrare **i risultati giusti**, al momento giusto, nel contesto giusto, così che partner e clienti possano dedicare il loro tempo limitato dove riduce di più il rischio. Se sei abituato a scanner che mostrano con orgoglio "10.000 problemi trovati", questo cambiamento potrebbe sembrare controintuitivo all'inizio. Ma nella pratica, **meno rumore + più rilevanza = insight migliori + riduzione del rischio più rapida**. Ed è esattamente lì che Lighthouse è diretto.