SAST e DAST: differenze, quando usarli e come integrarli nel DevSecOps

Nel ciclo di sviluppo software moderno, la sicurezza non può più essere considerata un’attività di verifica a posteriori: le vulnerabilità applicative sono diventate uno dei principali vettori di attacco contro le aziende, e ogni bug non identificato in fase di sviluppo si traduce in un costo esponenzialmente più alto se scoperto in produzione. È in questo contesto che il SAST (Static Application Security Testing) e il DAST (Dynamic Application Security Testing) giocano un ruolo decisivo: due metodologie complementari di application security testing che, integrate correttamente nel ciclo DevSecOps, permettono di intercettare vulnerabilità in momenti diversi e con prospettive diverse.

In questa guida vediamo cosa sono concretamente SAST e DAST, quali sono le differenze tra le due metodologie, quando ha senso usare l’una, l’altra o entrambe, e come integrarle in modo efficace nella strategia di sicurezza delle applicazioni aziendali. Affrontiamo anche altre tecniche correlate (IAST, RASP, SCA) e il ruolo crescente del testing applicativo nel contesto normativo italiano ed europeo, con particolare riferimento alla direttiva NIS2 e alle certificazioni ISO 27001/27034.

1. Cos’è l’Application Security Testing (AST)
2. Security-by-design e il ruolo del testing nel SDLC
3. SAST: cos’è e come funziona
4. DAST: cos’è e come funziona
5. SAST e DAST a confronto: differenze chiave
6. Altre tecniche: IAST, RASP e SCA
7. Come integrare SAST e DAST nel DevSecOps
8. SAST, DAST e conformità: NIS2, ISO 27001 e ISO 27034

Cos’è l’Application Security Testing (AST)

L’Application Security Testing, comunemente abbreviato in AST, è l’insieme delle pratiche e degli strumenti utilizzati per identificare vulnerabilità nelle applicazioni software durante il loro intero ciclo di vita. Si tratta di un’area distinta dal più ampio Vulnerability Assessment infrastrutturale: mentre quest’ultimo si concentra sulla rete, sui sistemi operativi e sui servizi esposti, l’AST guarda specificamente al codice e al comportamento applicativo, cercando difetti che potrebbero essere sfruttati da un attaccante per compromettere l’applicazione stessa o i dati che essa gestisce.

Le vulnerabilità applicative sono oggi una delle principali porte d’ingresso negli incidenti di sicurezza aziendali. OWASP (Open Web Application Security Project) ha stilato la classifica aggiornata delle top 10 vulnerabilità delle applicazioni e dei software web-based più critiche, tra cui figura per l’appunto l’Insecure Design

SAST e DAST non sono però gli unici strumenti dell’AST. Negli ultimi anni l’arsenale si è ampliato con tecniche come IAST (Interactive AST), RASP (Runtime Application Self-Protection) e SCA (Software Composition Analysis), ciascuna progettata per coprire angoli specifici del problema. Vedremo più avanti il ruolo di ciascuna.

Security-by-design e il ruolo del testing nel SDLC

Il principio cardine che guida l’application security moderna è la security-by-design: l’idea che la sicurezza non sia un’attività da svolgere a fine sviluppo, ma una caratteristica da progettare e integrare fin dalle primissime fasi del Software Development Life Cycle (SDLC). Questo approccio, formalizzato anche dagli standard internazionali ISO/IEC 27001 (gestione della sicurezza delle informazioni) e ISO/IEC 27034 (sicurezza specifica delle applicazioni), nasce dalla constatazione che individuare una vulnerabilità in produzione costa fino a 100 volte di più che individuarla durante la progettazione.

Il modello SDLC tradizionale “a cascata” prevedeva un’unica fase di testing alla fine, prima del rilascio. I modelli moderni — Agile, DevOps e oggi DevSecOps — hanno invece distribuito il testing lungo tutto il ciclo di sviluppo, integrandolo nelle pipeline di Continuous Integration e Continuous Delivery (CI/CD). È quello che viene chiamato shift-left: spostare il testing “a sinistra” nel ciclo, cioè il più presto possibile.

In questo paradigma, SAST e DAST occupano momenti diversi ma complementari. Il SAST agisce in modo precoce, durante la fase di codifica, ed è eseguibile anche su codice non ancora compilato o eseguibile. Il DAST agisce invece più avanti, quando l’applicazione è funzionante e accessibile, simulando il comportamento di un attaccante esterno. Insieme, coprono prospettive che nessuno dei due da solo potrebbe garantire.

SAST: cos’è e come funziona

Il SAST (Static Application Security Testing) è una metodologia di analisi del codice sorgente, del bytecode o del codice binario di un’applicazione, eseguita senza che il software sia in esecuzione. Per questa caratteristica viene anche chiamato white-box testing o “test della scatola bianca”: chi esegue l’analisi ha pieno accesso al codice e ne conosce la struttura interna.

L’obiettivo del SAST è identificare vulnerabilità che derivano da pattern di codifica insicuri: utilizzo di funzioni deprecate o vulnerabili, gestione errata dell’input utente, hardcoded credentials, errori nella gestione della memoria, configurazioni di sicurezza inadeguate. Strumenti SAST comuni includono SonarQube, Checkmarx, Veracode, Fortify e GitHub Advanced Security: tutti analizzano il codice scansionando milioni di righe in tempi molto rapidi e producendo report che indicano riga per riga le problematiche riscontrate.

Il principale punto di forza del SAST è la tempestività: può essere integrato nell’IDE dello sviluppatore (rilevando i problemi mentre il codice viene scritto) o nella pipeline CI/CD (bloccando il commit di codice non sicuro). Questo significa che le vulnerabilità vengono identificate quando correggerle è ancora rapido ed economico. Il limite principale, invece, è che il SAST analizza il codice in isolamento: non vede il comportamento dell’applicazione in esecuzione, non rileva problemi di configurazione del runtime e tende a generare un numero significativo di falsi positivi — vulnerabilità segnalate che, nel contesto reale, non sono sfruttabili.

DAST: cos’è e come funziona

Il DAST (Dynamic Application Security Testing) è la metodologia speculare: analizza l’applicazione mentre è in esecuzione, simulando il comportamento di un attaccante esterno che cerca di sfruttarne le vulnerabilità. È chiamato anche black-box testing perché tipicamente non richiede accesso al codice sorgente: lo strumento DAST interroga l’applicazione dall’esterno, invia input malevoli, osserva le risposte e identifica i punti deboli.

Le vulnerabilità che il DAST individua sono quelle che emergono nel comportamento runtime: SQL injection, cross-site scripting, autenticazione e gestione delle sessioni vulnerabili, esposizione di informazioni sensibili nelle risposte HTTP, configurazioni errate dei server applicativi. Strumenti DAST diffusi includono OWASP ZAP, Burp Suite Professional, Acunetix, Invicti e Qualys WAS.

Il punto di forza del DAST è la concretezza: identifica vulnerabilità realmente sfruttabili, perché le testa nel contesto reale di funzionamento dell’applicazione. Non dipende dal linguaggio di programmazione usato e copre anche i problemi che il SAST non vede, come quelli di configurazione del server o delle componenti di terze parti integrate a runtime. Il limite è che richiede un’applicazione funzionante in un ambiente di test o staging, è più lento del SAST (un’analisi completa può richiedere ore o giorni) e produce report meno granulari: indica che esiste una vulnerabilità ma non sempre la riga di codice esatta che la genera.

SAST e DAST a confronto: differenze chiave

SAST e DAST non sono alternative ma complementi. Le organizzazioni mature adottano entrambe le metodologie integrandole in momenti diversi della pipeline, perché ciascuna è efficace dove l’altra è debole.
Vediamo le principali differenze.

Momento di esecuzione. Il SAST si esegue durante lo sviluppo, anche sul codice non compilato. Il DAST si esegue su applicazioni funzionanti, tipicamente in ambiente di staging o test pre-produzione.

Tipo di accesso. Il SAST richiede pieno accesso al codice sorgente. Il DAST testa l’applicazione dall’esterno, senza necessariamente conoscere come è scritta internamente.

Tipo di vulnerabilità identificate. Il SAST trova difetti di codice (hardcoded secrets, uso scorretto di API crittografiche, pattern insicuri). Il DAST trova difetti di comportamento (XSS, SQL injection, autenticazione debole, gestione delle sessioni vulnerabile).

Velocità di esecuzione. Il SAST è veloce su singoli file, ma può rallentare su codebase molto estese. Il DAST è generalmente più lento perché deve interagire con l’applicazione e attendere le risposte.

Falsi positivi. Il SAST tende a generare più falsi positivi, perché analizza il codice senza conoscere il contesto runtime. Il DAST ha meno falsi positivi, ma può avere più falsi negativi (vulnerabilità non rilevate perché non testabili dall’esterno).

Integrazione nell’SDLC. Il SAST è facilmente integrabile nell’IDE e nei tool di code review. Il DAST si integra nelle pipeline CI/CD ma richiede ambienti applicativi funzionanti, quindi tipicamente più avanti nel processo.

In sintesi: il SAST individua i bug nel codice prima che diventino vulnerabilità reali, il DAST conferma quali tra quei bug (e quali nuovi) sono effettivamente sfruttabili nel mondo reale. Ignorare uno dei due significa accettare un compromesso di sicurezza significativo.

Altre tecniche: IAST, RASP e SCA

SAST e DAST sono le metodologie più conosciute, ma il panorama dell’Application Security Testing si è ampliato negli ultimi anni con tecniche più sofisticate, ciascuna progettata per colmare specifiche lacune.

L’IAST (Interactive Application Security Testing) combina i vantaggi di SAST e DAST. Funziona installando un agente all’interno dell’applicazione che, durante l’esecuzione dei test (manuali o automatici), monitora il comportamento del codice e segnala in tempo reale le vulnerabilità individuate. Rispetto al DAST tradizionale, IAST riduce drasticamente i falsi positivi perché ha visibilità sia del codice sia del runtime. È particolarmente adatto ad ambienti CI/CD ad alta velocità di rilascio.

Il RASP (Runtime Application Self-Protection) non è propriamente uno strumento di testing ma di protezione: si tratta di un agente integrato nell’applicazione che, una volta in produzione, monitora il comportamento e blocca in tempo reale eventuali tentativi di sfruttamento delle vulnerabilità residue. È complementare a SAST e DAST: questi ultimi servono a trovare e correggere i bug prima del rilascio, RASP protegge da quelli che eventualmente sono sfuggiti alle analisi precedenti.

La SCA (Software Composition Analysis) analizza invece le dipendenze open source e di terze parti utilizzate dall’applicazione. È diventata cruciale negli ultimi anni perché la maggior parte delle applicazioni moderne è costruita assemblando librerie esterne (npm, PyPI, Maven, NuGet) che possono contenere vulnerabilità note. La SCA identifica le componenti vulnerabili e segnala quando una libreria utilizzata corrisponde a una CVE nota. Strumenti come Snyk, Dependabot, OWASP Dependency-Check e Black Duck sono oggi standard di mercato.

Come integrare SAST e DAST nel DevSecOps

L’integrazione di SAST e DAST in un processo DevSecOps richiede pianificazione: gli strumenti vanno calibrati per evitare di rallentare la pipeline o sommergere gli sviluppatori di falsi positivi. Le organizzazioni mature seguono tipicamente questo approccio.

In fase di sviluppo, il SAST viene integrato direttamente nell’IDE dello sviluppatore (con plugin che evidenziano i problemi mentre il codice viene scritto) e nei tool di code review tipo GitHub o GitLab (con scansioni automatiche su ogni pull request). Le politiche di blocco vanno calibrate sulle sole vulnerabilità ad alta severità per evitare attriti con gli sviluppatori.

In fase di build e test, una scansione SAST più approfondita viene eseguita nella pipeline CI, insieme alla SCA per le dipendenze. Vulnerabilità critiche bloccano automaticamente il build; quelle medie generano alert da indirizzare nello sprint successivo.

In fase di staging, il DAST viene eseguito sull’applicazione deployata in ambiente di test, idealmente con scenari di test che simulano i flussi utente reali. Se l’organizzazione utilizza IAST, l’agente è già attivo durante i test funzionali e raccoglie automaticamente i dati di sicurezza.

In fase di produzione, RASP (se adottato) protegge l’applicazione in tempo reale, mentre periodiche scansioni DAST esterne verificano l’esposizione effettiva. I risultati confluiscono in dashboard centralizzate che permettono al team di sicurezza di monitorare la postura applicativa nel tempo.

Una distinzione importante riguarda il ruolo degli esperti di application security. Sebbene SAST e DAST siano fortemente automatizzati, l’interpretazione dei risultati richiede competenze specifiche: distinguere i falsi positivi, valutare la sfruttabilità reale di una vulnerabilità nel contesto specifico, prioritizzare gli interventi sulla base dell’impatto di business. È qui che il valore di un servizio professionale di Application Security Testing si distingue dall’uso “fai-da-te” degli strumenti.

SAST, DAST e conformità: NIS2, ISO 27001 e ISO 27034

Nel contesto normativo italiano ed europeo, l’application security testing non è più solo una best practice tecnica ma una necessità di conformità. La direttiva NIS2, recepita in Italia con il D.Lgs. 138/2024, impone alle aziende rientranti nel suo perimetro (operatori di servizi essenziali e soggetti importanti) di adottare misure tecniche e organizzative adeguate per garantire la sicurezza delle reti e dei sistemi informativi. Tra queste misure rientra esplicitamente la sicurezza nello sviluppo, acquisizione e manutenzione dei sistemi, area in cui SAST e DAST sono strumenti standard di mercato.

La certificazione ISO/IEC 27001 (Sistemi di gestione della sicurezza delle informazioni) prevede controlli specifici sulla sicurezza del ciclo di sviluppo applicativo (Annex A.14, ora aggiornato nella revisione 2022). Il sub-standard ISO/IEC 27034 è interamente dedicato all’Application Security e fornisce un framework strutturato per implementare un programma di sicurezza applicativa che includa pratiche di testing come SAST e DAST.

Per le aziende soggette a NIS2 o in percorso di certificazione ISO 27001, dotarsi di un programma strutturato di application security testing non è un’opzione ma un requisito documentale e operativo: gli auditor verificano l’esistenza di processi formalizzati e l’effettiva esecuzione delle attività di testing, oltre alla gestione delle vulnerabilità identificate.

Affidare l’Application Security Testing a un partner specializzato

SAST e DAST sono strumenti potenti ma il loro valore reale dipende dalla competenza con cui vengono integrati nei processi aziendali e interpretati i risultati. Per molte aziende italiane — soprattutto PMI con team di sviluppo limitati o senza specifiche competenze di security — la scelta più efficace è affidarsi a un partner specializzato in Application Security che svolga le attività di testing in modalità servizio, fornendo report leggibili dal management, prioritizzazione delle vulnerabilità e supporto nella remediation.

Onorato Informatica offre servizi di Vulnerability Assessment applicativo e Penetration Test su Web App, Mobile e API che integrano metodologie SAST, DAST e analisi manuale, con report orientati alla conformità (NIS2, ISO 27001) e accompagnamento nella correzione delle vulnerabilità individuate.