← Torna agli articoli

News · 04 February 2026

Vulnerability Management: non puoi proteggere ciò che non conosci

News stewe 2026-02-04 #vulnerability-management #scanning #CVE #remediation #nessus #openvas

Vulnerability Management: non puoi proteggere ciò che non conosci

C’è una frase che mi è rimasta in testa da quando ho iniziato a occuparmi di sicurezza:

“Non puoi proteggere ciò che non conosci.”

Sembra ovvia. Eppure la realtà delle organizzazioni è piena di server dimenticati, applicazioni legacy non aggiornate, dispositivi IoT connessi senza che nessuno lo sapesse. Il Vulnerability Management nasce esattamente per risolvere questo problema: conoscere la superficie di attacco e gestirla sistematicamente.

Non è un’attività una tantum. È un processo continuo.

Le 4 fasi del Vulnerability Management

1. Inventario (Asset Discovery)

Prima di cercare vulnerabilità, devi sapere cosa hai in rete. Suona banale — non lo è.

# Scansione della rete per scoprire gli host attivi
nmap -sn 192.168.1.0/24 -oG hosts_alive.txt

# Estrai solo gli IP attivi
grep "Up" hosts_alive.txt | awk '{print $2}' > ip_list.txt

# Scansione più dettagliata: OS, servizi, versioni
nmap -sV -sC -O -iL ip_list.txt -oN full_scan.txt

Con Nmap puoi fare un inventario completo della tua rete interna. Per ambienti più grandi, strumenti come Rumble (ora Censys ASM) o Netdisco automatizzano la scoperta continua.

2. Vulnerability Scanning

Con l’inventario in mano, esegui una scansione delle vulnerabilità. I due strumenti principali nel mondo open source / free sono:

OpenVAS (Greenbone)

# Installa su Kali/Debian
sudo apt install gvm
sudo gvm-setup
sudo gvm-start

# Accedi via browser su https://127.0.0.1:9392

Nmap con script NSE per vulnerability scanning

# Usa gli script di vulnerabilità NSE
nmap --script vuln 192.168.1.100

# Script specifici per servizi comuni
nmap --script smb-vuln-ms17-010 192.168.1.100  # EternalBlue
nmap --script http-shellshock 192.168.1.100    # Shellshock
nmap --script ssl-heartbleed 192.168.1.100     # Heartbleed

Nuclei — il mio preferito per velocità e flessibilità:

# Installa Nuclei
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

# Scansione con tutti i template
nuclei -l ip_list.txt -o nuclei_results.txt

# Solo vulnerabilità critiche e alte
nuclei -l ip_list.txt -severity critical,high -o critical_results.txt

# Template specifici per CVE
nuclei -l ip_list.txt -tags cve2024 -o cve_results.txt

3. Prioritizzazione

Questo è il passaggio dove la maggior parte dei processi fallisce. Uno scanner restituisce centinaia (a volte migliaia) di vulnerabilità. Non puoi fixarle tutte subito. Devi scegliere.

Il sistema di scoring standard è il CVSS (Common Vulnerability Scoring System), ma da solo non basta. Una CVE con CVSS 9.8 su un server isolato non raggiungibile da internet è meno urgente di una CVE con CVSS 7.0 su un sistema esposto pubblicamente e già sfruttata attivamente.

Un framework migliore per la prioritizzazione è SSVC (Stakeholder-Specific Vulnerability Categorization), che considera:

  • Exploitation status: è già sfruttata in the wild?
  • Technical impact: cosa può fare l’attaccante se la sfrutta?
  • Exposure: il sistema è esposto a internet?

Matrice di prioritizzazione semplificata:

CRITICITÀ = f(CVSS, Sfruttamento_Attivo, Esposizione, Valore_Asset)

Patch IMMEDIATAMENTE:
  → CVSS >= 9.0 + sfruttata attivamente + sistema esposto

Patch questa settimana:
  → CVSS >= 7.0 + sistema esposto
  → CVSS >= 9.0 su sistemi interni

Patch entro il mese:
  → CVSS 4.0-6.9 su sistemi esposti
  → CVSS >= 7.0 su sistemi interni non critici

Accetta il rischio (con documentazione):
  → CVSS < 4.0 + sistema isolato + mitigazioni compensative

4. Remediation e Verifica

Una vulnerabilità trovata ma non risolta non serve a niente. La remediation può essere:

  • Patch: aggiornare il software alla versione corretta
  • Mitigazione: applicare controlli compensativi (WAF, firewall rule, disabilitare il servizio)
  • Accettazione del rischio: documentare perché non si può patchare e quali controlli si applicano

Dopo ogni remediation, verifica che la vulnerabilità sia effettivamente chiusa:

# Dopo aver applicato la patch a MS17-010
nmap --script smb-vuln-ms17-010 192.168.1.100

# Output atteso se patchato:
# Host script results:
# |_smb-vuln-ms17-010: NT_STATUS_ACCESS_DENIED

Automatizzare il ciclo con Python

Un piccolo script per aggregare i risultati di Nmap e generare un report CSV:

import xml.etree.ElementTree as ET
import csv
from datetime import datetime

def parse_nmap_xml(xml_file):
    tree = ET.parse(xml_file)
    root = tree.getroot()
    vulnerabilities = []

    for host in root.findall("host"):
        ip = host.find("address").get("addr")
        
        for script in host.findall(".//script"):
            script_id = script.get("id")
            output = script.get("output", "")
            
            if "VULNERABLE" in output.upper():
                vulnerabilities.append({
                    "ip": ip,
                    "check": script_id,
                    "dettaglio": output[:200],
                    "data": datetime.now().strftime("%Y-%m-%d")
                })
    
    return vulnerabilities

def export_csv(vulns, output_file):
    with open(output_file, "w", newline="") as f:
        writer = csv.DictWriter(f, fieldnames=["ip", "check", "dettaglio", "data"])
        writer.writeheader()
        writer.writerows(vulns)
    print(f"[+] Report salvato in {output_file}: {len(vulns)} vulnerabilità")

vulns = parse_nmap_xml("full_scan.xml")
export_csv(vulns, "vulnerability_report.csv")

Metriche da monitorare

Un buon programma di VM si misura con metriche concrete:

# KPI fondamentali

Mean Time to Remediate (MTTR):
  critico: < 24 ore
  alto: < 7 giorni
  medio: < 30 giorni
  basso: < 90 giorni

Patch Coverage:
  target: > 95% degli asset scansionati
  
Vulnerability Density:
  vulnerabilità critiche per asset: target < 0.5

Recidiva:
  percentuale vulnerabilità già viste in precedenza: target < 10%

Un errore comune da evitare

Il VM non finisce con lo scanner. Ho visto tante organizzazioni che scansionano regolarmente, producono report bellissimi… e non fanno il patch. Il bottleneck non è quasi mai trovare le vulnerabilità — è il processo di approvazione e deployment delle patch, che spesso passa per team IT, change management, finestre di manutenzione.

Se vuoi che il tuo VM funzioni davvero, devi coinvolgere i team operativi fin dall’inizio e costruire SLA chiari su chi fa cosa entro quando.

La sicurezza non è solo trovare i problemi. È risolverli. 🛡️