Nel 2003, quando MySpace rappresentava il futuro dei social network e Firefox muoveva i primi passi nel mondo dei browser, i vulnerability scanner erano strumenti brillanti per il loro tempo. Analizzavano siti web composti da poche pagine HTML statiche, qualche modulo di contatto e database semplici. Il mondo digitale era prevedibile, le minacce seguivano pattern lineari, e questi strumenti facevano esattamente quello per cui erano stati progettati.
Indice degli argomenti
I limiti dei vulnerability scanner nel mondo moderno
Vent’anni dopo, continuiamo a utilizzare essenzialmente la stessa logica per analizzare ecosistemi cloud complessi, architetture a microservizi che si auto-scalano, API che comunicano in tempo reale e infrastrutture serverless che nascono e muoiono nell’arco di millisecondi. È come pretendere che una mappa stradale del 2003 vi guidi attraverso una metropoli completamente ricostruita, dove i quartieri cambiano nome ogni settimana e le strade si riconfigurano automaticamente in base al traffico.
Il risultato? Organizzazioni che spendono decine di migliaia di euro l’anno per strumenti che promettono sicurezza totale ma la differenza tra sicurezza vera e teatro della sicurezza si gioca su scelte informate, non su promesse marketing.
Perché i vulnerability scanner non bastano contro minacce dinamiche
L’Internet di oggi non è più la semplice raccolta di pagine statiche degli anni ’90; si è trasformato in un ecosistema di applicazioni dinamiche che gestiscono tutto, dalle transazioni bancarie ai dati sanitari, fino alle infrastrutture critiche. Questa evoluzione ha creato un vero e proprio paradiso per gli hacker: ci sono superfici d’attacco infinite, accessibili a tutti, piene di informazioni preziose.
I numeri raccontano una storia di guerra digitale. Le applicazioni web sono responsabili del 26% di tutte le violazioni dei dati, rendendole la seconda causa più comune di compromissioni informatiche. Ogni sito web subisce in media 94 attacchi al giorno, mentre i bot automatizzati lo scandagliano ben 2.608 volte a settimana in cerca di vulnerabilità da sfruttare. Inoltre, il 17% degli attacchi informatici a livello globale si concentra proprio sulle falle delle applicazioni: un obiettivo irresistibile per i criminali che possono operare nell’ombra, senza rischi fisici.
I limiti degli approcci dei vulnerability test
Di fronte a questa emergenza, l’industria della sicurezza ha risposto con i vulnerability scanner, strumenti automatizzati che promettono di scovare falle prima che gli hacker possano approfittarne. L’idea è semplice e accattivante: scansiona il codice, individua le vulnerabilità e correggile. Ma la realtà è ben diversa.
SAST: quando il codice sembra sicuro ma non lo è
Questi strumenti si basano su tre approcci principali, ognuno con le proprie limitazioni:
Static Application Security Testing (SAST) esamina il codice sorgente senza mai eseguirlo. È un po’ come controllare un’auto spenta per capire se è in grado di viaggiare. Questo approccio può identificare potenziali vulnerabilità nel codice, ad esempio, punti dove un attaccante potrebbe inserire comandi dannosi nel database aziendale (le cosiddette “SQL injection”), ma non può sapere se queste vulnerabilità siano realmente sfruttabili nel mondo reale. Una porzione di codice può sembrare completamente sicura durante l’analisi, ma può rivelare falle critiche quando l’applicazione reale gestisce dati inaspettati o si connette a sistemi configurati in modo vulnerabile.
DAST: il valore limitato dei test senza visibilità interna
Dynamic Application Security Testing (DAST) cambia completamente l’approccio, simulando attacchi reali contro l’applicazione in funzione, proprio come farebbe un cybercriminale. Sembra la soluzione ideale, ma ha i suoi limiti significativi. Questo metodo “bombarda” l’applicazione con migliaia di tentativi di attacco senza avere visibilità su cosa stia realmente accadendo nel codice. Il risultato? Può non rilevare vulnerabilità nascoste dai sistemi di protezione esistenti, dando una falsa sensazione di sicurezza ai decision maker.
IAST: la difficoltà di applicazione nei sistemi contemporanei
Interactive Application Security Testing (IAST) dovrebbe essere la soluzione definitiva, combinando i vantaggi dell’analisi del codice con il testing in tempo reale attraverso software di monitoraggio che osservano l’applicazione dall’interno. Tuttavia, questo approccio richiede modifiche invasive agli ambienti di sviluppo, rallenta significativamente le prestazioni del sistema e spesso non funziona nelle moderne architetture cloud che molte aziende stanno adottando.
Falsi allarmi e metriche ingannevoli nei vulnerability scanner
Il problema principale non è tecnico, ma matematico. Ogni scanner deve scegliere tra trovare tutte le vulnerabilità possibili (alta sensibilità) o evitare di sommergere i team con falsi allarmi (alta specificità). È fisicamente impossibile fare entrambe le cose perfettamente.
I fornitori commerciali lo sanno bene, ma ottimizzano i loro prodotti per impressionare durante le dimostrazioni commerciali. Massimizzano deliberatamente i tassi di rilevamento, anche a costo di sacrificare la precisione, perché “Abbiamo trovato 10.000 potenziali problemi di sicurezza” suona molto meglio di “Abbiamo trovato 50 vulnerabilità reali” durante una presentazione al management. Il risultato è prevedibile: strumenti che identificano migliaia di “vulnerabilità” che in realtà non rappresentano alcun rischio concreto per il business.
Vulnerabilità logiche: il punto cieco dell’automazione
La situazione diventa drammaticamente peggiore quando parliamo di vulnerabilità logiche: quelle falle che distruggono la logica di business delle applicazioni, dove il vero valore aziendale può essere compromesso. Nessuno scanner automatico può individuarle, perché non si tratta di errori di programmazione, ma di errori di ragionamento nella progettazione del sistema.
Un esempio concreto: un tool può analizzare alla perfezione una funzione di trasferimento di denaro di una banca online, scovando ogni possibile tentativo di inserimento di codice dannoso nel database (SQL injection) o attacco attraverso il browser (cross-site scripting), ma non si renderà mai conto che quella stessa funzione non verifica se ci sono fondi sufficienti sul conto prima di autorizzare un bonifico. Per lo scanner, il codice è perfetto. Per l’azienda, è un buco nei conti che aspetta solo di essere scoperto.
Il marketing dei vulnerability scanner contro la realtà tecnica
Questi non sono bug che si possono risolvere con un semplice aggiornamento software. Sono limitazioni matematiche fondamentali dell’automazione applicata alla sicurezza informatica. Eppure, l’industria continua a vendere scanner “completi” e “all-in-one” a organizzazioni che, in buona fede, confidano di aver coperto le loro principali vulnerabilità di sicurezza semplicemente investendo nella soluzione tecnologica più avanzata disponibile.
Benchmark realistici per misurare i vulnerability scanner
Per valutare l’efficacia dei vulnerability scanner in scenari realistici, è essenziale utilizzare un approccio basato su benchmark che impieghi applicazioni web intenzionalmente vulnerabili. Questo metodo permette di testare la capacità degli strumenti di identificare vulnerabilità note in ambienti controllati, fornendo metriche oggettive sulle loro performance: un po’ come testare diversi sistemi di allarme antifurto in case dove sappiamo esattamente dove sono nascosti i punti di accesso.
In questo studio sono state utilizzate due piattaforme di riferimento: BrokenCrystal, un’applicazione web moderna che simula le vulnerabilità tipiche delle applicazioni aziendali contemporanee, e DVWA (Damn Vulnerable Web Application), una piattaforma consolidata che replica le falle di sicurezza più classiche e ben documentate. Entrambe fungono da “campi di prova” standardizzati per confrontare le capacità di rilevamento dei diversi scanner.
Pentest-Tools (un vulnerability scanner) ha condotto un benchmark trasparente sui propri competitor nel 2024, demolendo anni di marketing inflazionato con dati crudi e implacabili. Su BrokenCrystal (l’applicazione moderna), Acunetix domina con la copertura più alta, ma il secondo posto è condiviso tra Pentest-Tools Scanner e Burp Suite – due strumenti con filosofie e prezzi completamente diversi che raggiungono prestazioni identiche.
Ancora più rivelatore: OWASP ZAP, completamente gratuito, supera sia Qualys che Rapid7 InsightAppSec, soluzioni enterprise che costano alle aziende decine di migliaia di euro annui. Un risultato che dovrebbe far riflettere qualsiasi CFO – Chief Financial Officer prima di approvare il prossimo budget per la cybersecurity.
Il quadro si ribalta completamente su DVWA, che simula le vulnerabilità delle applicazioni più tradizionali. Burp Suite conquista il primo posto rilevando 29 vulnerabilità su 39 – un tasso di successo del 74% che, in qualsiasi altro settore business, sarebbe considerato mediocre per uno strumento “professionale” da migliaia di euro. Pentest-Tools Scanner si piazza secondo, seguito da Rapid7 InsightAppSec con 19 rilevazioni e Acunetix con appena 18. Ma il dato più devastante riguarda OWASP ZAP: completamente escluso dal confronto a causa di 88 falsi positivi per SQL injection (vulnerabilità che permettono di inserire comandi dannosi nei database aziendali). Ottantotto falsi allarmi significa sommergere i team di sicurezza con segnalazioni inutili, paralizzando la capacità di risposta dell’organizzazione.
Non esiste il miglior vulnerability scanner: solo compromessi
I risultati rivelano una verità brutale: non esiste il “miglior scanner universale”. Acunetix domina sulle applicazioni moderne ma crolla su quelle classiche. Burp Suite eccelle sulle applicazioni legacy ma non primeggia su architetture contemporanee. Ogni strumento ha punti ciechi sistematici che l’industria preferisce non pubblicizzare durante le presentazioni commerciali.
I falsi positivi rimangono il tallone d’Achille dell’intero settore. Quando anche ZAP, considerato uno standard di riferimento dalla comunità di sicurezza, genera 88 falsi allarmi su un’applicazione di test, il problema non è tecnico – è sistemico. I team di sicurezza finiscono per spendere più tempo a verificare segnalazioni fantasma che a correggere vulnerabilità reali, trasformando investimenti in sicurezza in costi operativi improduttivi.
Il benchmark espone una verità scomoda per qualsiasi decisore: il successo di uno scanner dipende più dal tipo di applicazione aziendale che dalla sua qualità intrinseca. Questa variabilità rende impossibile qualsiasi confronto equo e permette ai fornitori di scegliere selettivamente i casi d’uso che favoriscono i loro strumenti durante le demo commerciali. I numeri dimostrano che l’industria vende certezze in un mercato costruito sull’incertezza. Ogni scanner rappresenta un compromesso, ogni risultato è contestuale, ogni promessa di “copertura completa” è una strategia di vendita ben confezionata che non riflette la realtà operativa dell’azienda acquirente.
Una strategia pragmatica per usare meglio i vulnerability scanner
La verità sui vulnerability scanner è più scomoda di quanto il marketing voglia ammettere. Dopo anni di promesse e investimenti significativi in licenze enterprise, ci troviamo di fronte a una realtà complessa: questi strumenti sono utili ma non risolutivi, efficaci ma non infallibili.
Ogni scansione rappresenta una fotografia del momento in cui è stata scattata, mentre nuove vulnerabilità emergono continuamente, il codice evolve e gli attaccanti affinano le loro tecniche. Le organizzazioni spesso credono che una scansione periodica garantisca sicurezza continua, ma il panorama delle minacce non si ferma mai, rendendo questa percezione potenzialmente pericolosa.
I falsi positivi rimangono una sfida significativa: quando un tool rispettato come OWASP ZAP genera 88 allarmi errati per SQL injection su una singola applicazione di test, evidenzia le limitazioni intrinseche di questi sistemi. I team di sicurezza finiscono per dedicare tempo prezioso a verificare segnalazioni inesatte mentre vulnerabilità genuine potrebbero passare inosservate.
I scanner vi dicono cosa è rotto, mai quanto pericoloso sia davvero. Una XSS stored in una funzione amministrativa critica viene catalogata con lo stesso livello di urgenza di una reflected XSS in una pagina di errore visitata una volta all’anno. Le organizzazioni si trovano così spesso sommerse da migliaia di segnalazioni, tutte etichettate come urgenti secondo algoritmi che privilegiano la quantità sulla qualità dell’analisi. Questa overdose informativa porta a paralisi decisionale, con CISO che osservano dashboard coloratissime senza riuscire a identificare le priorità reali. La guidance per la remediation rappresenta un ulteriore punto debole: suggerimenti generici come “aggiorna Apache alla versione 2.4.54” sono tecnicamente corretti ma operativamente problematici se l’upgrade compromette sistemi critici in produzione. È come prescrivere lo stesso farmaco per sintomi diversi, ignorando il contesto specifico di ogni ambiente.
Tuttavia, esistono approcci pragmatici per massimizzare il valore di questi strumenti. Invece di cercare il scanner perfetto, che semplicemente non esiste, le organizzazioni dovrebbero implementare ecosistemi di sicurezza stratificati dove SAST, DAST e review manuali si complementano reciprocamente. Tre strumenti imperfetti che collaborano producono risultati superiori a qualsiasi soluzione monolitica, per quanto sofisticata.
L’investimento in competenze interne rimane fondamentale: un security engineer esperto con strumenti open source spesso supera team meno preparati dotati di scanner enterprise costosi. L’intelligenza umana resta insostituibile per contestualizzare risultati, interpretare falsi positivi e prioritizzare interventi di remediation. È essenziale pretendere trasparenza dai vendor attraverso SLA (Service Level Agreement) specifici sui falsi positivi, benchmark pubblici verificabili e clausole contrattuali che penalizzino performance inadeguate. I fornitori che rifiutano questi standard stanno implicitamente ammettendo che i loro strumenti non reggono il confronto con valutazioni indipendenti. L’adozione di principi security-by-design rappresenta l’evoluzione naturale: threat modeling sistematico, secure coding practices e peer review rigorose prevengono vulnerabilità invece di rilevarle a posteriori, con costi e rischi significativamente inferiori.
L’industria dei vulnerability scanner opera vendendo certezze in un contesto intrinsecamente incerto, dove ogni promessa di copertura completa è più aspirazione marketing che realtà tecnica. La sicurezza efficace richiede umiltà tecnologica: riconoscere onestamente i limiti dei nostri strumenti, diversificare gli approcci e investire in competenze che nessun vendor può fornire attraverso una licenza software.
Le organizzazioni possono raggiungere livelli di sicurezza superiori ottimizzando investimenti e strategie, ma questo richiede il coraggio di sfidare convenzioni consolidate e approcci ortodossi che spesso privilegiano il comfort della familiarità rispetto all’efficacia reale. Il cambiamento inizia quando smettiamo di accettare passivamente prezzi enterprise per performance mediocri e iniziamo a valutare criticamente il ritorno effettivo sui nostri investimenti in sicurezza. La rivoluzione della sicurezza applicativa sarà guidata dal pragmatismo e dall’ottimizzazione intelligente delle risorse, non dalla spesa indiscriminata in tecnologie costose ma non necessariamente superiori.
