Software penetration test: cos'è e cosa trova

Un software penetration test è un test di sicurezza offensivo autorizzato che ha come bersaglio un'applicazione, non la rete su cui gira: chi lo esegue prova a sfruttare i difetti del software in esecuzione per dimostrare cosa otterrebbe davvero un attaccante. Il perimetro comprende applicazioni web e API, app mobile, software desktop e i componenti di terze parti che l'applicazione porta con sé.

Chi cerca questo termine di solito sta cercando uno strumento. Conviene separare subito le due cose: uno scanner segnala classi di difetti noti, un test dimostra quali sono sfruttabili nella tua applicazione. Vediamo cosa entra nel perimetro, cosa emerge, come si legge il report e in quale punto del ciclo di sviluppo il test ripaga.

Che cos'è un software penetration test

La cornice generale è quella del penetration test: attività offensiva concordata, delimitata da regole d'ingaggio e documentata. Cambia l'oggetto. Un test di rete parte da cosa è raggiungibile (indirizzi, porte, servizi, versioni); un test sul software parte da cosa fa l'applicazione: quali funzioni espone, quali dati vede ciascun ruolo, quali passaggi si possono saltare, cosa succede quando un input non è quello previsto.

Il NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (settembre 2008), nell'Appendice C descrive lo scopo: determinare se il software applicativo contiene vulnerabilità sfruttabili e se si comporta e interagisce in modo sicuro con i suoi utenti, con le altre applicazioni (per esempio le basi di dati) e con il proprio ambiente di esecuzione. Le tre relazioni contano quanto il codice: molti difetti non stanno dentro una funzione, stanno nel modo in cui due componenti si parlano.

Cosa entra nel perimetro

"Software" è una parola larga, e ciascuna di queste aree richiede preparazione e competenze diverse: definire il perimetro in modo esplicito è il primo lavoro dello scoping.

Applicazioni web e API

È il caso più frequente e ha una metodologia dedicata, la OWASP Web Security Testing Guide. Se il tuo perimetro è un portale o un'area riservata, il riferimento è la scheda sul web application penetration test, che entra nel dettaglio di quel caso.

App mobile

Un'app installata sul telefono dell'utente vive su un dispositivo che non controlli. Il progetto OWASP Mobile Application Security organizza le verifiche in otto gruppi di controllo: archiviazione dei dati (MASVS-STORAGE), crittografia (MASVS-CRYPTO), autenticazione e autorizzazione (MASVS-AUTH), comunicazione di rete (MASVS-NETWORK), interazione con la piattaforma (MASVS-PLATFORM), qualità del codice e build (MASVS-CODE), resistenza a reverse engineering (MASVS-RESILIENCE), privacy (MASVS-PRIVACY).

Software desktop e componenti nativi

Un client installato, un servizio Windows, un firmware, un componente scritto in C o C++ portano difetti che il web non ha: gestione della memoria, privilegi del processo, percorsi dei file, canali di comunicazione locali, meccanismo di aggiornamento. Qui il test lavora sul binario, con analisi statica e dinamica e spesso con fuzzing sugli ingressi.

Componenti di terze parti

Nel software che rilasci, la parte scritta in casa è di solito la minoranza. L'edizione 2025 del Top 10 di OWASP allarga la categoria di conseguenza: quella che nel 2013 nasceva come "uso di componenti con vulnerabilità note" oggi è A03:2025 Software Supply Chain Failures, definita da OWASP come i cedimenti o le compromissioni nel processo di costruzione, distribuzione o aggiornamento del software. Non sono solo le librerie non aggiornate: rientrano gli strumenti di build, la pipeline, la distribuzione degli aggiornamenti.

Anche il legislatore guarda lì: il D.Lgs. 138/2024, che recepisce la NIS2, all'articolo 24 comma 3 chiede di tenere conto della qualità complessiva dei prodotti e delle pratiche di sicurezza dei propri fornitori, comprese le loro procedure di sviluppo sicuro. Se sviluppi software per aziende soggette alla NIS2, quella frase riguarda te.

Cosa trova un test sul software

Il CWE Top 25 Most Dangerous Software Weaknesses, che MITRE pubblica sulla base dei dati sulle vulnerabilità note, dà l'ordine di grandezza. Nell'edizione 2025 le prime cinque debolezze sono, nell'ordine: cross-site scripting (CWE-79), SQL injection (CWE-89), cross-site request forgery (CWE-352), autorizzazione mancante (CWE-862), scrittura fuori dai limiti di memoria (CWE-787). La lista tiene insieme mondi diversi: le prime quattro sono difetti applicativi tipici del web, la quinta è un difetto di memoria tipico del software nativo. Un test deve poter coprire entrambi i registri.

Le liste, però, dicono dove guardare, non cosa troverai. La parte che nessun elenco anticipa è quella dei difetti di logica: passaggi che l'applicazione consente e che non dovrebbe. Applicare due volte lo stesso buono sconto, confermare un ordine senza che il pagamento sia riuscito, leggere il documento di un altro cliente cambiando un identificativo. Tecnicamente il software funziona, e per questo nessuno strumento li segnala: li trova una persona che ha capito il processo. Sono anche i difetti con l'effetto più diretto sul conto economico.

Perché uno scanner da solo non basta

Non è un'obiezione contro gli strumenti: analisi statica, analisi dinamica e analisi delle dipendenze sono il livello di base, girano a ogni build e senza di loro un test manuale spreca tempo. Il punto è cosa resta fuori.

Il NIST SP 800-115 lo scrive senza giri di parole. Sugli strumenti di scansione applicativa osserva che, come tutti gli strumenti basati su corrispondenza di pattern e su firme, hanno tipicamente alti tassi di falsi positivi, e che soffrono anche degli alti tassi di falsi negativi propri degli strumenti a firma; aggiunge che le vulnerabilità sfuggite agli scanner possono essere intercettate con più scanner o con forme di testing aggiuntive. Sull'analisi delle vulnerabilità dentro un penetration test nota poi che i processi manuali possono individuare vulnerabilità nuove o poco note che gli scanner automatici possono non vedere, al prezzo di essere più lenti.

La stessa logica sta nel Secure Software Development Framework del NIST (SP 800-218, versione 1.1, febbraio 2022), dove la pratica PW.8 chiede di decidere se testare il codice eseguibile per trovare vulnerabilità non identificate da revisioni, analisi o test precedenti: il testing offensivo sta a valle degli strumenti, non al loro posto.

Il confronto tra penetration test e vulnerability assessment mette in fila la differenza tra ampiezza e profondità, e la scheda su cos'è un vulnerability assessment spiega cosa copre la scansione periodica.

Come si svolge

Lo schema di riferimento resta quello del NIST SP 800-115, che descrive quattro fasi: planning (dove si fissano regole, approvazione formale del management e obiettivi, senza eseguire alcun test), discovery, attack e reporting, con un ritorno alla discovery quando lo sfruttamento apre strade nuove.

Sul software la scelta di quanto far sapere al tester ha conseguenze concrete, e l'Appendice C del SP 800-115 le enuncia con precisione. Le tecniche white box, cioè l'analisi diretta del codice sorgente, sono le più efficienti sulle applicazioni sviluppate in casa, ma non rilevano i difetti di sicurezza nelle interfacce tra componenti né i problemi introdotti in fase di compilazione, collegamento o configurazione al momento dell'installazione. Le tecniche black box, che lavorano sull'eseguibile senza conoscere il codice, servono per i componenti compilati a rischio alto, per le interazioni tra componenti e per l'interazione dell'applicazione con utenti, altri sistemi e ambiente esterno. La combinazione delle due, che il documento chiama gray box, copre entrambe le zone cieche.

Tradotto in cose da preparare: il codice o il binario nella versione esatta che andrà in produzione, un ambiente di test fedele, credenziali per ciascun ruolo, la documentazione delle API, l'elenco delle dipendenze e un referente tecnico che sappia dire se una funzione è pensata per fare quello che fa.

Come si legge il report

Il valore del test si misura su ciò che arriva alla fine. Un report utile contiene:

• una sintesi per chi decide, con il rischio espresso in termini di dati e processi, non di identificativi tecnici;
• i findings con severità e con il contesto che la giustifica: il punteggio CVSS, alla versione 4.0 mantenuta da FIRST, misura la vulnerabilità in sé, non quanto pesa nel tuo caso;
• per ogni finding la catena riproducibile: richiesta, parametro, versione, risposta, prova. Se lo sviluppatore non riesce a riprodurre il problema, la correzione diventa un'ipotesi;
• la remediation prioritizzata, con indicazioni tecniche e non formule generiche, e un retest concordato per verificare che le correzioni tengano.

Se il test serve a dimostrare qualcosa a un cliente o a un auditor, il criterio di verifica si fissa prima: l'OWASP Application Security Verification Standard (ASVS), alla versione 5.0.0 rilasciata il 30 maggio 2025, offre requisiti verificabili a cui agganciare l'esito.

Quando entra nel ciclo di sviluppo

Il SSDF distingue due pratiche che nel linguaggio commerciale finiscono confuse. PW.7 riguarda la revisione e l'analisi del codice leggibile da una persona; PW.8 riguarda il test del codice eseguibile, e tra gli esempi di attuazione cita il fuzzing sugli ingressi e, quando le risorse lo consentono, il penetration testing per simulare come un attaccante potrebbe compromettere il software negli scenari a rischio alto. Lo stesso PW.8 chiede di registrare problemi e correzioni raccomandate nel flusso di lavoro o nel sistema di ticketing del team di sviluppo: un report che vive fuori dal tracker non produce correzioni.

L'Appendice C del SP 800-115 è esplicita sul quando: la valutazione della sicurezza applicativa va integrata nel ciclo di vita del software, non svolta solo quando l'applicazione è pronta; i test vanno poi ripetuti periodicamente una volta in produzione, quando vengono applicate patch, aggiornamenti o modifiche significative, e quando cambia in modo rilevante il panorama delle minacce in cui l'applicazione opera.

Nel mid-market si traduce in quattro momenti: prima del go-live, quando cambia un pezzo importante (nuovo provider di autenticazione, API aperte a un partner, riscrittura di un modulo), quando un cliente o una gara chiede l'esito di un test recente, e a cadenza definita sul software che genera fatturato. Se i rilasci sono frequenti e il test annuale invecchia in poche settimane, il modello continuativo si chiama penetration test as a service.

Cosa chiedono le norme

Nessuna norma nomina l'espressione "software penetration test", ma diversi obblighi ci arrivano per sostanza.

• Il D.Lgs. 138/2024, articolo 24 comma 2, include tra le misure minime la sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete, comprese la gestione e la divulgazione delle vulnerabilità (lettera e), e politiche e procedure per valutare l'efficacia delle misure di gestione dei rischi (lettera f).
• L'Allegato A della ISO/IEC 27001:2022 prevede la gestione delle vulnerabilità tecniche (controllo 8.8) e i test di sicurezza in fase di sviluppo e accettazione (controllo 8.29): il quadro completo è nella scheda sull'Allegato A della ISO 27001.
• Per il comparto finanziario, DORA colloca il penetration test nel programma di test di base, con il test guidato dalla minaccia riservato ai soggetti individuati dalle autorità competenti: il dettaglio è nell'articolo sui test di resilienza operativa e TLPT.

L'evidenza che serve a un auditor non è il contratto del test: è la sequenza documentata di finding, correzioni e verifiche.

Dal report al codice corretto

Un test sul software dice cosa è sfruttabile oggi, non se qualcuno ci sta provando adesso: quello si vede dai log dell'applicazione, raccolti e correlati dentro un presidio operativo. Il test riduce la superficie sfruttabile, il monitoraggio continuo riduce il tempo in cui un tentativo resta inosservato. AmagisTech lavora con il mid-market italiano su entrambi i fronti: se hai un'applicazione da mettere alla prova, parliamone in una call di scoping.