SAST, Static Application Security Testing: perché è fondamentale

Lo Static Application Security Testing (SAST) è la metodologia che analizza il codice sorgente di un’applicazione — senza eseguirla — alla ricerca delle vulnerabilità introdotte durante lo sviluppo. È il controllo di sicurezza più “a monte” che esista: interviene quando l’applicazione è ancora nelle mani di chi la scrive, dove correggere una falla costa una frazione di quanto costerebbe scoprirla in produzione.

In questo articolo vediamo come funziona il SAST, cosa rileva e cosa non può rilevare, come si confronta con il DAST — il suo complemento naturale — e dove si colloca in una strategia di verifica completa delle applicazioni web.

1. Cos’è il SAST e come funziona
2. Cosa rileva il SAST — e cosa non può vedere
3. SAST vs DAST: il confronto
4. Il SAST nel ciclo di sviluppo
5. Oltre gli strumenti automatici

Cos’è il SAST e come funziona

Il SAST appartiene alla famiglia del white-box testing: lo strumento ha piena visibilità sul codice — sorgente, bytecode o binario — e lo esamina dall’interno, senza bisogno che l’applicazione sia in esecuzione. Il funzionamento segue una logica di analisi statica: il codice viene scomposto in rappresentazioni interne (alberi sintattici, grafi di flusso), e su queste strutture lo strumento applica regole che riconoscono i pattern di codifica insicura — tracciando, ad esempio, come un input non fidato attraversa l’applicazione fino a raggiungere un’operazione sensibile.

Il risultato è un report che indica la vulnerabilità, la sua severity e — punto di forza del metodo — la posizione esatta nel codice: file e riga dove intervenire, spesso con l’indicazione della correzione. È il motivo per cui il SAST è tanto uno strumento di sicurezza quanto uno strumento per gli sviluppatori: dà un riscontro immediato su ciò che si sta scrivendo, mentre lo si scrive.

Cosa rileva il SAST — e cosa non può vedere

L’analisi statica eccelle sulle vulnerabilità che vivono nel codice: le falle di iniezione come la code injection e la SQL injection, il cross-site scripting, le credenziali scritte in chiaro nel sorgente, la gestione insicura dei dati, i buffer overflow — in larga parte le categorie censite dalla OWASP Top 10 e dalla SANS/CWE Top 25.

Ma il perimetro finisce dove finisce il codice, ed è qui che il SAST mostra i suoi due limiti strutturali. Il primo: non vede l’applicazione in funzione — errori di configurazione dell’ambiente, problemi nelle API di terze parti, vulnerabilità che emergono solo dall’interazione tra componenti in esecuzione restano fuori dal suo raggio. Il secondo: la mancanza di contesto produce falsi positivi — lo strumento segnala pattern potenzialmente pericolosi senza poter verificare se siano davvero sfruttabili, e un flusso di segnalazioni non filtrate finisce per essere ignorato da chi sviluppa, che è il modo più silenzioso in cui un programma di sicurezza fallisce.

SAST vs DAST: il confronto

Il complemento naturale del SAST è il Dynamic Application Security Testing, che testa l’applicazione in esecuzione dall’esterno, come farebbe un attaccante. Le differenze, punto per punto:

La conclusione operativa è che non esiste un vincitore: SAST e DAST coprono ciascuno i punti ciechi dell’altro, e la domanda giusta non è quale scegliere ma quando usare ciascuno. C’è però un caso frequente che la tabella chiarisce subito: se l’applicazione è sviluppata da terzi e il codice sorgente non è accessibile — la situazione della maggior parte delle aziende che usano software commissionato — il SAST semplicemente non è praticabile, e la verifica passa dall’analisi dinamica. Del funzionamento e dei vantaggi del testing dinamico abbiamo parlato nell’approfondimento su tutto il potenziale del DAST.

Per completezza va citato il resto della famiglia: la Software Composition Analysis (SCA) analizza le librerie e le dipendenze di terze parti — un fronte che né SAST né DAST coprono direttamente, e che pesa sempre di più visto che le applicazioni moderne sono in larga parte assemblate da componenti open source, come insegna la vulnerabilità Vulnerable and Outdated Components della OWASP Top 10. L’Interactive Application Security Testing (IAST) è invece l’approccio ibrido: strumenti che osservano l’applicazione dall’interno mentre è in esecuzione, combinando la profondità del SAST con il contesto del DAST — al prezzo di un’integrazione più invasiva.

Il SAST nel ciclo di sviluppo

Il valore del SAST si moltiplica quando smette di essere un controllo occasionale e diventa parte del flusso di lavoro: integrato negli ambienti di sviluppo e nelle pipeline di integrazione continua, analizza automaticamente ogni modifica al codice e restituisce il riscontro allo sviluppatore prima che la modifica prosegua. È il principio dello shift-left — spostare la sicurezza il più a sinistra possibile nel ciclo di vita del software — che sta alla base dell’approccio DevSecOps: la sicurezza come parte del processo di sviluppo, non come collaudo finale.

I benefici sono concreti anche in termini economici: una vulnerabilità corretta durante la scrittura del codice costa ore di lavoro; la stessa vulnerabilità scoperta in produzione costa patch d’emergenza, fermi, nuovi test — e nel peggiore dei casi diventa la porta d’ingresso di un incidente. Per chi sviluppa software in proprio o lo commissiona con continuità, pretendere che il fornitore integri l’analisi statica nel processo è una clausola contrattuale che si ripaga da sola.

Oltre gli strumenti automatici

C’è infine un limite che SAST e DAST condividono, in quanto strumenti automatici: riconoscono i pattern noti, non capiscono la logica di business. Un processo di acquisto che permette di modificare il prezzo, un flusso di autorizzazione aggirabile saltando un passaggio, un privilegio ottenibile cambiando un parametro: nessuno scanner segnala queste falle, perché non violano regole di codifica — violano il senso dell’applicazione. Per farle emergere serve un analista umano che provi attivamente a sovvertire i flussi, che è esattamente il terreno del web application penetration testing condotto manualmente.

La strategia matura, per le applicazioni che contano, combina quindi tre livelli: l’analisi statica durante lo sviluppo, quella dinamica sull’applicazione in funzione, e il test manuale periodico che verifica ciò che gli strumenti non vedono — con tempi e occasioni che abbiamo mappato nell’approfondimento su quando fare un web application penetration test.