In breve: pentest o scansione delle vulnerabilità non è una domanda del tipo aut aut, ma una questione di ordine. Una scansione delle vulnerabilità trova in modo automatizzato falle note ed errori di configurazione, in fretta e a costo contenuto, ma con falsi allarmi e punti ciechi. Un penetration test verifica in modo mirato che cosa un aggressore potrebbe davvero ottenere. Un programma di bug bounty apre la verifica a ricercatori esterni e vale la pena solo quando scansioni e pentest sono routine. Per la maggior parte delle PMI l'ordine è: scansionare con regolarità, correggere i riscontri, far testare in modo mirato, istituire un punto di segnalazione per le vulnerabilità.
Perché la domanda si ripropone dopo PHP2Shell
Chi dopo PHP2Shell verifica il proprio sito con uno scanner online può ottenere risultati sconcertanti. Uno scanner segnala magari una falla critica, benché l'hoster abbia confermato la patch. Un altro non segnala nulla, benché il server usi ancora una vecchia versione di PHP, perché l'indicazione della versione è nascosta.
Il motivo sta nel modo di lavorare. Molti scanner deducono la vulnerabilità dalla versione visualizzata. Le distribuzioni però installano backport senza cambiare il numero di versione; secondo i resoconti, ad esempio Ubuntu 24.04 dopo l'aggiornamento continua a mostrare 8.3.6. Perché sia così lo spiega Perché php -v mostra lo stesso numero dopo l'aggiornamento. La prova affidabile la fornisce il changelog del pacchetto, vedere Verificare correttamente versione PHP e livello di patch.
Non è un argomento contro gli scanner, ma a favore del conoscerne i limiti e del combinarli con altri metodi.
Pentest o scansione delle vulnerabilità: i tre metodi a confronto
| Criterio | Scansione delle vulnerabilità | Penetration test | Bug bounty |
|---|---|---|---|
| Chi verifica? | Strumento automatizzato | Specialisti incaricati | Ricercatori esterni, spesso tramite una piattaforma |
| Che cosa si trova? | Falle note, versioni obsolete, errori di configurazione | Vulnerabilità sfruttabili, errori logici, concatenazioni | Ciò che i ricercatori trovano e segnalano, spesso l'insolito |
| Profondità | Ampia, ma superficiale | Profonda nell'ambito concordato | Variabile, dipende dai partecipanti |
| Falsi allarmi | Frequenti | Rari, i riscontri vengono provati | Molte segnalazioni da valutare |
| Pianificabilità | Alta, ripetibile a piacere | Alta, periodo e ambito fissi | Bassa, le segnalazioni arrivano di continuo |
| Presupposti in azienda | Qualcuno che valuti i risultati | Ambito concordato, ambiente di test o finestra di manutenzione | Processo maturo per valutazione, correzione e ricompensa |
| Impiego tipico | In continuo, ad esempio mensile o dopo modifiche | Prima del lancio, dopo modifiche importanti, a intervalli regolari | Come integrazione per applicazioni mature ed esposte |
Nessuno dei metodi sostituisce gli altri. La scansione mostra molto in poco tempo, il pentest mostra ciò che conta davvero e il bug bounty trova ciò a cui nessuno ha pensato.
Con gli scanner vale la pena anche una seconda occhiata al tipo di scansione. Una scansione dall'esterno vede solo ciò che vede ogni visitatore e deve spesso indovinare le versioni dalle risposte del server. Una scansione autenticata, in cui lo strumento legge con credenziali proprie i pacchetti installati sul server, fornisce risultati nettamente più affidabili, soprattutto sull'effettivo stato del pacchetto di PHP. Presuppone però che Lei configuri a tal fine un accesso limitato e lo protegga bene. Per le dipendenze delle proprie applicazioni PHP esistono a loro volta strumenti di verifica propri, ad esempio composer audit per i pacchetti di Composer.
L'ordine sensato per le PMI
- Inventario e scansione: prima sapere quali siti e server esistono, poi scansionare regolarmente. Non recepire i riscontri senza verifica, ma valutarli.
- Correggere le basi: eliminare software obsoleto, aggiornamenti mancanti ed evidenti errori di configurazione. Fissare un pentest su sistemi senza patch spreca budget.
- Penetration test mirato: per le applicazioni più importanti, ad esempio shop, portale clienti o interfacce, con ambito chiaramente concordato e test successivo.
- Verifica del codice per sviluppi propri: chi gestisce applicazioni PHP proprie integra il test con una revisione del codice sorgente. Come si svolge lo descrive Code review di sicurezza per progetti PHP.
- Punto di segnalazione per le vulnerabilità: una politica su come gli esterni possono segnalare le falle e un file security.txt secondo RFC 9116 in
/.well-known/security.txtcon contatto e data di scadenza. - Bug bounty, quando le basi sono a posto: solo quando le segnalazioni vengono valutate in modo affidabile e le falle corrette con rapidità.
Perché ne nasca una procedura stabile vale la pena guardare Gestione delle vulnerabilità per le PMI.
Che cosa nessuno dei metodi offre
Nessun metodo di verifica dimostra che un sistema sia sicuro. Mostra solo che cosa è stato trovato in un dato momento con determinati metodi. Un pulito rapporto di pentest di primavera non dice nulla su una falla come PHP2Shell, che diventa nota a ottobre.
Né scansione né pentest rispondono alla domanda se un server sia già compromesso. A tal fine serve una ricerca di tracce sul sistema stesso: processi, file, cronjob, account, connessioni. È un compito a sé con metodi propri.
Faccia verificare solo sistemi per i quali è autorizzato e, per i sistemi in hosting, chiarisca prima le regole del fornitore. Un penetration test richiede un incarico scritto con ambito, periodo e referenti.
Quando non serve un test esterno
Per un semplice sito aziendale senza moduli con dati sensibili, presso un hoster che installa gli aggiornamenti in modo affidabile, spesso basta una scansione regolare con valutazione critica dei risultati. Un penetration test sarebbe qui di solito sproporzionato. Più importanti sono software aggiornato, accessi robusti e backup.
Un test esterno conviene per shop, portali, sviluppi propri, interfacce verso sistemi interni e ovunque clienti o norme richiedano una prova indipendente.
Come aiuta concretamente PHP SOS?
- Configuriamo scansioni regolari e valutiamo i risultati, compresi i falsi allarmi dovuti ai backport.
- Aiutiamo a correggere le basi prima che il denaro confluisca in un pentest.
- Insieme a partner specializzati eseguiamo audit di sicurezza e penetration test con ambito concordato e test successivo.
- Supportiamo la creazione di un punto di segnalazione per le vulnerabilità e di un file security.txt.
Conclusione
Scansione, pentest e bug bounty sono gradini, non concorrenti. Chi comincia con scansioni regolari, corregge le basi e poi fa testare in modo mirato ottiene per il proprio budget la massima sicurezza. Il bug bounty è il coronamento per organizzazioni in cui il dovere è già assolto.
Domande frequenti
Che differenza c'è tra pentest e scansione delle vulnerabilità?
Una scansione delle vulnerabilità verifica in modo automatizzato se sono riconoscibili falle note o errori di configurazione. Un penetration test va oltre: specialisti cercano, in un quadro concordato, di sfruttare davvero le vulnerabilità e di concatenarle, e ne valutano le conseguenze.
Uno scanner scopre se il mio server ha la patch per PHP2Shell?
Solo in misura limitata. Molti scanner leggono la versione PHP visualizzata. Se la distribuzione installa un backport, il numero spesso resta uguale e lo scanner segnala una falla da tempo chiusa. Viceversa può essere mostrato un nuovo numero mentre girano ancora vecchi processi.
Un programma di bug bounty è adatto alle piccole aziende?
Di solito non ancora. Il bug bounty presuppone che le segnalazioni siano valutate in fretta e le falle corrette con rapidità. Un buon inizio è una semplice politica per la segnalazione delle vulnerabilità con un file security.txt.
Posso verificare da solo il mio sito con uno scanner?
I Suoi sistemi di norma sì, se ne ha l'autorizzazione. Se il sito è presso un hoster, chiarisca prima se le scansioni sono consentite o vadano annunciate. Sistemi altrui li verifichi solo con l'autorizzazione scritta del gestore.
Ogni quanto dovrebbe essere eseguito un pentest?
Non esiste una regola fissa. È consueto un test prima del lancio di una nuova applicazione, dopo modifiche importanti e a intervalli regolari, determinati dal Suo rischio e, se del caso, da requisiti di clienti o norme.