WPScan è uno scanner di sicurezza specifico per WordPress che lavora dall’esterno del sito: non richiede l’accesso alla dashboard o al codice sorgente per iniziare a raccogliere informazioni sulla versione di WordPress, sui temi, sui plugin e su diverse esposizioni potenzialmente problematiche.
Il progetto lo definisce un black-box WordPress security scanner pensato per professionisti della sicurezza e amministratori di siti WordPress. Il punto è proprio questo: cerca di capire cosa riesce a vedere un osservatore esterno e confronta ciò che rileva con le informazioni disponibili nel database delle vulnerabilità. La documentazione ufficiale elenca controlli che riguardano core, plugin, temi, utenti e diverse configurazioni o file esposti.
Questo lo rende utile in un processo di sicurezza WordPress, ma bisogna capire bene cosa può e cosa non può dirti. Trovare una vulnerabilità nota non dimostra che il sito sia stato compromesso; allo stesso modo, non trovare vulnerabilità non dimostra che il sito sia sicuro.
In questa guida vediamo come installare WPScan, eseguire una prima scansione, utilizzare API token ed enumerazione e, soprattutto, interpretare correttamente quello che compare nel terminale.
Importante: esegui scansioni esclusivamente su siti di tua proprietà o per i quali disponi di un’autorizzazione esplicita. La stessa licenza del progetto avverte che utilizzare lo scanner su sistemi senza consenso può essere illegale.
Cos’è WPScan e cosa controlla realmente
WPScan è uno strumento a riga di comando dedicato a WordPress. Non effettua semplicemente una ricerca del termine “WordPress” nel codice HTML: combina diversi metodi di detection per identificare componenti e informazioni che un sito rende osservabili dall’esterno.
Una scansione può cercare, tra le altre cose:
- versione del core WordPress;
- tema utilizzato;
- plugin rilevabili;
- file e directory interessanti;
- configurazioni esposte;
- informazioni che permettono l’enumerazione degli utenti;
- backup o dump potenzialmente accessibili;
- vulnerabilità note associate ai componenti identificati quando sono disponibili i relativi dati.
Come funziona una scansione black-box di WordPress
“Black-box” significa che lo scanner osserva il sistema senza conoscere preventivamente la sua implementazione interna.
Immagina di avere un plugin installato nella directory:
/wp-content/plugins/example-plugin/
Lo scanner può trovare indizi della sua presenza attraverso risorse pubbliche, markup HTML, file accessibili o altri segnali. Se riesce anche a determinarne la versione, può confrontarla con il database delle vulnerabilità conosciute.
Il meccanismo essenziale è quindi:
sito raggiungibile dall'esterno
↓
raccolta di segnali
↓
identificazione di WordPress e componenti
↓
stima della versione quando possibile
↓
confronto con vulnerability data
↓
finding da verificare
È una distinzione importante. Il tool non entra automaticamente nel filesystem e non legge direttamente il database MySQL del sito. Vede ciò che riesce a dedurre attraverso l’interfaccia esposta sulla rete.
Per questo può offrire una prospettiva diversa rispetto a una scansione delle vulnerabilità di WordPress eseguita da un plugin interno.
Cosa può rilevare e cosa invece non può dimostrare
Se viene identificato un plugin vulnerabile, il risultato significa essenzialmente:
è stato rilevato questo componente o questa versione e nel database esiste una vulnerabilità nota compatibile con ciò che è stato identificato.
Non significa necessariamente:
questa vulnerabilità è stata sfruttata e il sito è compromesso.
La differenza è sostanziale.
WPScan è principalmente uno strumento di discovery e vulnerability assessment. Una compromissione richiede invece un’indagine su file, processi, account, log, database, modifiche anomale, persistence e altri indicatori che una scansione black-box non può osservare completamente.
Anche il database delle vulnerabilità specifica che, pur puntando all’accuratezza, non può garantire di contenere tutte le vulnerabilità né che ogni dato sia perfetto.
Prima della scansione: autorizzazione, ambiente e precauzioni
Una scansione di sicurezza genera richieste HTTP verso il sito. Con le impostazioni di base il carico può essere relativamente contenuto, ma alcune forme di enumerazione aumentano sensibilmente il numero di richieste.
Prima di iniziare conviene quindi conoscere il target, avere un’autorizzazione chiara e sapere che tipo di test stai per eseguire.
Perché devi scansionare solo siti tuoi o autorizzati
WPScan è uno strumento legittimo di security assessment, ma le sue funzionalità possono essere utilizzate anche contro infrastrutture di terzi.
La licenza ufficiale specifica che l’esecuzione dello scanner contro siti senza consenso preventivo può essere illegale.
Il fatto che un sito sia pubblicamente raggiungibile non equivale a un’autorizzazione a sottoporlo a test di sicurezza.
Per una normale attività di amministrazione WordPress il caso più semplice è questo: scansiona il tuo sito, uno staging oppure un’infrastruttura del cliente per la quale il test è previsto esplicitamente dal mandato ricevuto.
Questa guida rimane volutamente nell’ambito del vulnerability assessment autorizzato.
Produzione o staging: traffico, log e possibili blocchi
Il tool può essere usato anche contro un sito di produzione, ma non bisogna considerare ogni comando equivalente.
Una scansione base produce traffico. L’enumerazione approfondita ne produce di più. Sistemi anti-bot, rate limiting, CDN e firewall possono inoltre bloccare alcune richieste oppure registrarle come attività sospetta.
Se stai lavorando su un’infrastruttura importante, conviene:
- conoscere prima le opzioni che intendi utilizzare;
- iniziare con una scansione base;
- monitorare access log, WAF e risorse server;
- ampliare l’enumerazione solo quando serve;
- preferire staging per test particolarmente intensivi.
Questa precauzione ha anche un altro vantaggio: se il firewall blocca determinate richieste, un risultato vuoto potrebbe dipendere dal sistema di protezione e non dall’assenza del componente cercato.
Come installarlo
Esistono diversi modi per installare WPScan. La scelta migliore dipende soprattutto dal sistema operativo e da quanto vuoi isolare le dipendenze.
La documentazione ufficiale nel repository indica i prerequisiti necessari per l’installazione tramite RubyGems e raccomanda invece il package manager nelle distribuzioni dedicate al penetration testing quando il pacchetto è disponibile.
Installazione su Kali Linux
Su Kali Linux puoi installare il pacchetto con:
sudo apt install wpscan
La documentazione Kali mantiene una pagina specifica dedicata allo strumento.
Se è già installato attraverso la distribuzione, è generalmente preferibile mantenerlo con lo stesso sistema anziché mescolare package manager e RubyGems.
Per aggiornare i pacchetti:
sudo apt update sudo apt upgrade
Installazione con RubyGems e Homebrew
Con un ambiente Ruby correttamente configurato puoi utilizzare RubyGems:
gem install wpscan
Su macOS è documentata anche l’installazione con Homebrew:
brew install wpscanteam/tap/wpscan
L’installazione tramite gem può richiedere compilatore e header di sviluppo perché alcune dipendenze utilizzano estensioni native. Su Debian e Ubuntu, ad esempio:
sudo apt install build-essential ruby-dev
Non conviene quindi diagnosticare un errore Failed to build gem native extension reinstallando il pacchetto ripetutamente: spesso il problema è nell’ambiente di compilazione o nelle dipendenze Ruby.
Eseguire WPScan con Docker
Docker è una soluzione interessante quando vuoi evitare di installare Ruby e le relative dipendenze direttamente sulla macchina.
Per scaricare l’immagine:
docker pull wpscanteam/wpscan
Un aspetto meno evidente riguarda il database locale. Se esegui un container con --rm, le modifiche interne vengono eliminate al termine dell’esecuzione. La documentazione suggerisce quindi di montare un volume persistente nella directory della cache.
Per aggiornare il database mantenendolo in un volume:
docker run -it --rm \ -v wpscan-db:/wpscan/.cache/wpscan/db \ wpscanteam/wpscan --update
Il vantaggio non è soltanto evitare download ripetuti: container e database locale hanno cicli di vita differenti, quindi mantenerli separati rende l’ambiente più prevedibile.
Come eseguire la prima scansione
Una volta completata l’installazione, il primo controllo non richiede una configurazione complessa.
Su un sito che sei autorizzato a testare puoi eseguire:
wpscan --url https://example.com
Il repository ufficiale descrive il comando base come il punto di partenza per effettuare la detection del sito e raccogliere gli “interesting findings”.
Cosa succede durante il controllo
Durante l’esecuzione vengono inviate richieste al sito per ricostruire una fotografia di ciò che è visibile dall’esterno.
Non limitarti a cercare eventuali righe di warning. Conviene osservare l’intera sequenza:
target → informazioni raggiungibili → versione WordPress → tema → componenti individuati → interesting findings → vulnerability data disponibili → riepilogo
Questo permette di capire da quale rilevazione deriva un finding.
Se, per esempio, non viene determinata con certezza la versione di un plugin, l’incertezza sulla versione si trasferisce anche alla valutazione delle vulnerabilità applicabili. Non avrebbe senso interpretare con la stessa sicurezza un componente rilevato con versione precisa e uno soltanto ipotizzato.
Aggiornare lo scanner e verificare l’ambiente
Per aggiornare il database locale:
wpscan --update
Per visualizzare le opzioni disponibili:
wpscan --help
Se hai effettuato l’installazione tramite RubyGems:
gem update wpscan
Se invece il pacchetto proviene dal package manager della distribuzione, continua a utilizzare quest’ultimo.
Questo evita una situazione comune nei tool da terminale: binary aggiornato da un sistema, dipendenze gestite da un altro e comportamento difficile da diagnosticare.
Cosa leggere nell’output prima delle vulnerabilità
Quando appare un risultato interessante, chiediti prima:
- che componente è stato identificato?
- la versione è conosciuta?
- come è stato rilevato?
- con quale livello di confidence?
- la vulnerabilità riguarda effettivamente quella versione?
- esiste una versione corretta?
L’output può indicare metodo di detection e confidence. In presenza di una vulnerabilità può inoltre mostrare riferimenti e, quando disponibile, la versione in cui il problema è stato corretto.
Il principio da ricordare è semplice: prima viene l’identificazione del componente, poi il confronto con la vulnerabilità.
API Token e Vulnerability Database: perché cambiano i risultati
Uno degli aspetti che genera più confusione è il ruolo dell’API token.
WPScan CLI può funzionare senza token. Il token serve però per recuperare dal WordPress Vulnerability Database i dati sulle vulnerabilità note associate a core, plugin e temi rilevati.
Cosa ottieni senza API token
Puoi eseguire:
wpscan --url https://example.com
anche senza registrarti.
La detection continuerà a funzionare. Se vengono individuati WordPress, un plugin o un tema, però, non saranno aggiunti all’output i vulnerability data recuperati attraverso l’API.
Questo spiega perché due scansioni dello stesso sito possono sembrare molto diverse pur utilizzando lo stesso software.
Senza token:
detection → sì vulnerability data via API → no
Con token:
detection → sì
+
componente/versione rilevati
↓
WordPress Vulnerability Database
↓
vulnerabilità note compatibili
La WPScan Vulnerability Database API contiene dati relativi al core WordPress, ai plugin e ai temi.
Come funziona il limite delle richieste API
Il piano gratuito prevede un numero limitato di chiamate API giornaliere, indicato nella pagina prezzi ufficiale.
Il numero di richieste non corrisponde semplicemente al numero di scansioni.
Secondo la documentazione dello scanner, viene utilizzata una richiesta per la versione WordPress, una per ogni plugin identificato e una per il tema.
Immagina quindi un sito in cui vengono individuati:
WordPress core = 1 richiesta 20 plugin = 20 richieste 1 tema = 1 richiesta
Un singolo assessment può quindi consumare numerose chiamate.
Quando il limite è esaurito, la scansione può continuare, ma senza i vulnerability data recuperati dall’API.
Questo dettaglio è fondamentale quando confronti due report: un report con meno vulnerabilità non significa necessariamente che il sito sia diventato più sicuro. Potrebbe semplicemente essere stato generato senza accesso ai relativi dati.
Come gestire il token senza inserirlo ogni volta nel comando
La forma immediata è:
wpscan --url https://example.com --api-token YOUR_API_TOKEN
Funziona, ma non è sempre la scelta migliore, soprattutto in ambienti condivisi o automatizzati.
Il tool supporta un file di configurazione:
cli_options: api_token: 'YOUR_API_TOKEN'
nel percorso:
~/.config/wpscan/scan.yml
È disponibile anche la variabile d’ambiente:
WPSCAN_API_TOKEN
Per pipeline, container e sistemi CI/CD è generalmente preferibile trattare il token come secret, evitando di inserirlo direttamente in repository, script pubblici o screenshot.
Enumerazione di plugin, temi, utenti e file esposti
La scansione standard non cerca necessariamente tutto ciò che può essere enumerato. Per approfondire specifici componenti si utilizza l’opzione --enumerate, abbreviata in -e.
Plugin e temi: detection non significa vulnerabilità
Per cercare plugin vulnerabili:
wpscan --url https://example.com --enumerate vp
Per cercare temi vulnerabili:
wpscan --url https://example.com --enumerate vt
Puoi aggiungere il token quando vuoi associare ai componenti rilevati i dati sulle vulnerabilità:
wpscan --url https://example.com \ --enumerate vp,vt \ --api-token YOUR_API_TOKEN
Esiste una distinzione utile tra chiedere allo scanner di cercare tutti i componenti e concentrarsi su quelli vulnerabili. Non conviene quindi lanciare automaticamente l’enumerazione più ampia possibile: scegli ciò che serve al tuo assessment.
Più importante ancora, plugin rilevato e plugin vulnerabile non sono sinonimi.
Il primo è un risultato di discovery. Il secondo richiede che il componente — idealmente anche la sua versione — possa essere collegato a vulnerability data pertinenti.
User enumeration: cosa significa davvero
Per enumerare gli utenti:
wpscan --url https://example.com --enumerate u
Se vengono ricavati username pubblicamente, non significa automaticamente che un account possa essere compromesso.
Significa però che una parte dell’informazione necessaria a un tentativo di autenticazione è pubblicamente ricostruibile.
La conseguenza pratica è diversa da “il sito è bucato”: occorre verificare come vengono protetti gli accessi, ad esempio con password robuste, autenticazione a più fattori, rate limiting e appropriate misure di hardening.
Backup, directory e altre esposizioni
È possibile cercare anche cartelle create da plugin di backup:
wpscan --url https://example.com --enumerate bf
Il problema non è la cartella in sé. È ciò che può diventare raggiungibile senza autorizzazione.
Un backup di WordPress lasciato pubblicamente scaricabile può esporre informazioni molto più sensibili di una semplice versione di plugin: database, configurazioni, URL interni e, in alcuni casi, segreti che non avrebbero mai dovuto essere pubblici.
Come interpretare i risultati della scansione
Il valore dello strumento dipende molto meno dal numero di warning visualizzati e molto di più dalla capacità di interpretarli.
La lettura utile segue questa sequenza:
cosa è stato rilevato?
↓
come è stato rilevato?
↓
quanto è certa la versione?
↓
quale vulnerabilità viene associata?
↓
quali versioni sono realmente interessate?
↓
esiste una patch?
↓
il finding è applicabile al mio sito?
Saltare uno di questi passaggi è il modo più rapido per trasformare un vulnerability scanner in una macchina per produrre falsi allarmi.
Versione rilevata, confidence e metodo di detection
Una versione può essere ricavata attraverso segnali differenti.
Se il markup o una risorsa pubblica indica chiaramente una release, la detection può essere forte. Se il componente viene dedotto da segnali indiretti, il risultato richiede maggiore cautela.
Nell’output puoi incontrare informazioni come:
Detected By Confidence Confirmed By
Il valore di confidence riguarda quanto lo scanner ritiene affidabile quella specifica detection. Non è una percentuale che misura la probabilità che il tuo sito venga hackerato.
Questo è un errore interpretativo importante da evitare.
Vulnerabilità note: affected version, fixed version e riferimenti
Supponiamo che venga identificato:
Plugin: example-plugin Version: 2.3.0
e che il database riporti:
Affected: <= 2.3.0 Fixed in: 2.3.1
La prima verifica consiste nel controllare che la versione realmente presente sul sito coincida con quella rilevata.
Poi bisogna capire se:
- il componente vulnerabile è realmente attivo;
- la vulnerabilità è applicabile alla configurazione;
- richiede autenticazione o privilegi particolari;
- esiste già una release corretta;
- la versione installata può essere aggiornata senza rompere il sito.
Il nome della CVE o la severità da soli non bastano a decidere la remediation.
Perché un finding non equivale a una compromissione
Una vulnerabilità descrive una condizione che può consentire un determinato comportamento indesiderato.
Una compromissione indica invece che quella o un’altra debolezza è stata effettivamente sfruttata.
Fra le due cose c’è un passaggio che una scansione black-box, da sola, normalmente non può dimostrare:
vulnerabilità presente
↓
condizioni necessarie soddisfatte
↓
tentativo di exploit
↓
exploit riuscito
↓
azione dell'attaccante
↓
eventuale persistence / malware / account creati
Se trovi una vulnerabilità critica su un sito che mostra anche comportamenti sospetti, il problema non è più soltanto “aggiorna il plugin”. A quel punto serve una vera diagnosi di un sito WordPress hackerato.
Cosa fare quando emerge una vulnerabilità
Un finding utile deve terminare con una decisione operativa.
La risposta non è automaticamente “elimina tutto” e neppure “aggiorna tutto alla cieca”. Prima verifica il componente e poi scegli la remediation meno distruttiva che rimuove realmente il rischio.
Verificare componente, versione e disponibilità della patch
Per ogni vulnerabilità materiale controlla almeno:
| Controllo | Domanda |
|---|---|
| Componente | È realmente installato? |
| Stato | È attivo o comunque raggiungibile? |
| Versione | È stata determinata correttamente? |
| Vulnerabilità | La versione installata rientra nel range interessato? |
| Condizioni | Servono autenticazione, ruolo o configurazioni specifiche? |
| Patch | Esiste una versione corretta? |
| Mitigazione | Esiste una misura temporanea affidabile se non puoi aggiornare subito? |
La tabella evita un errore tipico dei vulnerability scanner: trattare tutto ciò che viene rilevato come se avesse lo stesso livello di certezza e la stessa priorità operativa.
Aggiornare, sostituire o rimuovere il componente vulnerabile
Se una release corretta è disponibile e compatibile con il sito, l’aggiornamento è normalmente la soluzione più lineare.
Se non esiste una patch, le alternative possono essere:
- disattivare temporaneamente il componente;
- sostituirlo;
- rimuoverlo se non serve;
- limitare l’accesso alla funzionalità interessata;
- applicare una mitigazione documentata dal vendor;
- utilizzare temporaneamente controlli compensativi.
Un Web Application Firewall può ridurre l’esposizione a determinate classi di attacco, ma non dovrebbe diventare la giustificazione per mantenere indefinitamente software vulnerabile quando esiste una correzione applicabile.
Dopo la remediation, esegui nuovamente il controllo:
detect → verify → remediate → rescan → document
Quando il sito potrebbe essere già compromesso
Se alla vulnerabilità si accompagnano segnali come redirect sconosciuti, utenti amministratori non riconosciuti, file modificati, spam SEO, pagine estranee o attività anomala, una normale scansione non è sufficiente.
Bisogna verificare se esiste già una compromissione.
In quel caso l’obiettivo cambia:
prima: individuare esposizioni dopo: determinare se l'attaccante è entrato e cosa ha modificato
La remediation deve quindi includere analisi, pulizia, rotazione delle credenziali, verifica della persistence e chiusura della vulnerabilità iniziale. Quando serve un intervento specialistico, questo è il punto in cui un servizio di rimozione malware WordPress diventa pertinente: non come sostituto dello scanner, ma perché risolve un problema diverso.
Quando la scansione non trova nulla: perché il sito non è automaticamente sicuro
Un report senza vulnerability finding è un buon segnale, ma non è un certificato di sicurezza.
Il sistema può confrontare ciò che riesce a identificare con un database di vulnerabilità conosciute. Non può garantire che:
- ogni componente sia stato rilevato;
- ogni versione sia stata identificata;
- il database contenga ogni vulnerabilità esistente;
- non esistano vulnerabilità custom nel tema o nei plugin sviluppati ad hoc;
- non ci siano problemi nella configurazione del server;
- non siano presenti credenziali compromesse;
- il sito non contenga già malware;
- non esistano vulnerabilità sconosciute.
Le condizioni d’uso della WPScan API chiariscono che il database non può essere considerato una rappresentazione infallibile di tutte le vulnerabilità esistenti.
Vulnerabilità sconosciute e limiti del black-box scanning
Il limite deriva direttamente dal modello black-box.
Se una vulnerabilità esiste in un pezzo di codice che lo scanner non può osservare o identificare, potrebbe non avere abbastanza informazioni per segnalarla.
Allo stesso modo, un sistema di cache, un CDN o un firewall possono modificare ciò che viene restituito alle richieste e ridurre la capacità di detection.
Quindi:
lo scanner non rileva X
non equivale necessariamente a:
X non esiste
Questa differenza tra assenza di evidenza ed evidenza di assenza è fondamentale in qualsiasi assessment di sicurezza.
Vulnerability scanner, malware scanner, WAF e code review risolvono problemi diversi
È più utile pensare alla sicurezza come a più livelli complementari:
| Strumento/controllo | Domanda principale |
|---|---|
| WPScan | Cosa può essere rilevato dall’esterno e quali vulnerabilità note possono interessarlo? |
| Malware scanner | Ci sono file o pattern compatibili con codice malevolo? |
| Log analysis | Cosa è realmente accaduto nelle richieste e negli accessi? |
| WAF | Quale traffico sospetto posso filtrare o bloccare? |
| Code review | Esistono vulnerabilità nella logica o nel codice che gli scanner non vedono? |
| Hardening | Quali superfici di attacco posso ridurre prima che vengano sfruttate? |
Nessuno di questi controlli sostituisce automaticamente gli altri.
Il valore specifico di WPScan è offrire una prospettiva esterna, WordPress-specifica e collegata a un database di vulnerabilità conosciute.
È gratuito? API, licenza e uso professionale
Qui bisogna distinguere almeno tre elementi:
WPScan CLI WPScan vulnerability data/API uso o integrazione commerciale
Trattarli come un unico prodotto “gratis o a pagamento” porta facilmente a conclusioni sbagliate.
CLI, API e vulnerability data non hanno le stesse condizioni
Il repository distribuisce il software sotto la WPScan Public Source License.
La licenza indica fra gli usi consentiti in determinate condizioni il test dei propri sistemi e l’impiego come strumento all’interno di attività di penetration testing. Alcuni casi di commercializzazione o integrazione richiedono invece condizioni differenti.
Separatamente, la pagina prezzi definisce i piani e i limiti relativi all’accesso ai vulnerability data.
Sono quindi aspetti che vanno letti nel contesto concreto dell’utilizzo.
Cosa verificare prima di integrarlo in un servizio commerciale
La domanda corretta non è semplicemente:
sto guadagnando mentre uso questo strumento?
Bisogna chiedersi:
come sto utilizzando il software e i vulnerability data all’interno del servizio?
Per progetti commerciali, SaaS o integrazioni automatiche dei dati, verifica sempre la licenza e le condizioni ufficiali applicabili al tuo caso.
Questa distinzione è informativa e non sostituisce un parere legale.
Gli errori più comuni durante una scansione
Il comando è relativamente semplice da avviare. Gli errori più importanti arrivano dopo: nell’autorizzazione, nella scelta del controllo e nell’interpretazione del report.
Scansionare un dominio senza autorizzazione
La disponibilità pubblica di un dominio non equivale al consenso a un security test.
Prima di usare lo strumento su sistemi di terzi definisci target, autorizzazione e perimetro.
Considerare ogni finding una vulnerabilità sfruttabile
Se viene identificato un componente e collegato a una vulnerabilità, hai trovato un elemento da verificare, non necessariamente un exploit immediatamente applicabile.
Controlla versione, configurazione, prerequisiti, autenticazione richiesta e fix disponibile.
La distinzione diventa ancora più importante quando la detection della versione è incerta.
Fermarsi al report senza correggere e verificare di nuovo
Il report non mette in sicurezza il sito.
La parte che conta è ciò che succede dopo:
scansione → verifica → priorità → remediation → nuova scansione
Se aggiorni un plugin vulnerabile ma non controlli nuovamente il sito, non sai ancora se la remediation ha eliminato il finding.
E se il sito era già stato compromesso prima dell’aggiornamento, la patch chiude la vulnerabilità ma non rimuove automaticamente eventuali modifiche lasciate dall’attaccante.
Conclusione
WPScan è particolarmente utile quando vuoi osservare WordPress dal punto di vista di chi non possiede accesso amministrativo al sito. Può identificare core, plugin, temi e altre informazioni esposte e, con accesso al vulnerability database, collegare i componenti rilevati a vulnerabilità conosciute.
Il valore reale, però, non sta nel lanciare un comando e contare i warning.
Sta nella sequenza:
rilevare → capire come è stato rilevato → verificare la versione → valutare la vulnerabilità → correggere → controllare di nuovo
Usalo quindi come componente di un processo di sicurezza più ampio. Un finding non dimostra una compromissione e una scansione pulita non dimostra l’assenza di vulnerabilità.
Se amministri il tuo sito, parti da un controllo base autorizzato, aggiungi l’API token quando ti servono i vulnerability data e amplia l’enumerazione solo in funzione di una domanda precisa. Se invece emergono vulnerabilità critiche insieme a segnali di compromissione, il problema non è più soltanto vulnerability scanning: serve una vera attività di incident analysis e remediation.