SAST o DAST: ogni scanner lascia vulnerabilità che l’altro può trovare

SAST e DAST non sono intercambiabili: il primo cerca difetti nel codice prima che l’applicazione venga eseguita, il secondo osserva il comportamento di una build funzionante. Nel caso OpenMRS, entrambe le tecniche hanno trovato vulnerabilità sfuggite all’altra e ai test manuali: il testo dello studio indica 824 vulnerabilità per SAST e 25 per DAST, mentre la tabella ne riporta 823 e 23. La discrepanza è interna alla pubblicazione; il rapporto fra i totali non è una previsione per altre applicazioni.

La scelta di pipeline è usare l’analisi statica durante lo sviluppo e quella dinamica dopo la build, in un ambiente in cui i percorsi da testare siano raggiungibili. La guida OWASP ai test mobili definisce SAST come esame senza esecuzione e DAST come esame durante il funzionamento; colloca il primo nello sviluppo e il secondo dopo la build, prima della distribuzione. Il contesto della guida è mobile, ma la distinzione di metodo e fase aiuta anche a scegliere i controlli per una pipeline web.

Accesso al codice e prerequisiti

Per SAST serve un artefatto che lo strumento sappia interpretare: sorgente, codice compilato o binari, secondo il prodotto. La guida OWASP all’analisi statica descrive controlli eseguibili nell’ambiente di sviluppo, prima del commit o nell’integrazione continua, senza predisporre un’applicazione in funzione. Questo permette di attribuire un avviso alla porzione di codice appena modificata. Il risultato dipende però dal supporto per linguaggio e framework e dalle regole attivate: la stessa istruzione può avere un significato diverso a seconda dei controlli che la precedono.

Per DAST serve invece un servizio avviato e raggiungibile. Su un’applicazione web, l’indirizzo pubblico del solo login non basta a valutare le funzioni riservate: occorrono account di prova, gestione della sessione e percorsi che conducano lo scanner alle pagine o alle API pertinenti. Il sorgente non è un requisito per inviare richieste, ma diventa utile quando bisogna trasformare una risposta anomala nella modifica di codice corretta.

Quali difetti emergono e quale prova rimane

SAST segue istruzioni e flussi di dati per individuare, per esempio, un input non affidabile che raggiunge una query o una funzione sensibile senza un controllo adeguato. Può ispezionare un ramo del programma che la scansione dinamica non attraversa. In cambio produce soprattutto una prova nel codice: posizione, regola violata e talvolta percorso dei dati. Per stabilire se il difetto sia sfruttabile, bisogna valutare se la funzione sia raggiungibile, quali controlli la precedano e quale configurazione venga distribuita.

DAST esercita l’applicazione tramite richieste e osserva risposte e cambiamenti di stato. Può far emergere errori di configurazione, dati rivelati da messaggi del server, comportamenti di autenticazione o protezioni HTTP mancanti nella build testata. La sua prova è legata a uno specifico endpoint, a credenziali e a una configurazione: più vicina al comportamento osservabile, ma spesso meno precisa nell’indicare la riga responsabile. Una risposta sospetta richiede comunque una verifica prima di diventare una vulnerabilità accertata.

Le categorie si sovrappongono senza rendere equivalenti i risultati. Un’iniezione può apparire sia come flusso rischioso nel sorgente sia come risposta a una richiesta costruita ad hoc; uno scanner può trovare un punto d’ingresso che l’altro non raggiunge. Inoltre DAST vede soltanto ciò che il percorso di navigazione, i ruoli e i dati di prova gli consentono di esercitare. Una scansione completata con successo non implica che siano stati percorsi tutti i flussi autenticati.

Falsi positivi e lavoro di triage

Il conteggio degli avvisi è un indicatore fragile: un solo difetto può generare molte segnalazioni, e una segnalazione può risultare innocua dopo l’analisi del contesto. Con SAST il revisore ricostruisce il flusso fino alla funzione segnalata e controlla se le condizioni per sfruttarla sono reali. Con DAST riproduce la richiesta, distingue la risposta dell’applicazione da quella di un proxy o dell’ambiente e cerca poi la causa nel codice o nella configurazione.

La reputazione di una tecnica per i falsi positivi non basta a stimare questo costo. La valutazione SATE VI del NIST rileva differenze nell’efficacia degli strumenti statici secondo casi di prova, classi di difetto e complessità del codice. Confrontare il numero grezzo di avvisi di prodotti diversi, senza deduplicazione e verifica, confonde volume di output e vulnerabilità distinte. Un campione di risultati sulla propria applicazione è più utile per stimare quanto lavoro richiederà ciascuno strumento.

Dove collocarli nella pipeline

SAST ha senso nelle verifiche delle modifiche e nella build, con regole rapide dove serve un riscontro immediato e un’analisi più estesa quando la pipeline concede più tempo. È utile distinguere i nuovi risultati dal debito già presente: bloccare ogni modifica per avvisi preesistenti rende il segnale poco interpretabile. Il criterio per interrompere una build dovrebbe seguire la gravità e l’affidabilità delle regole effettivamente valutate sul progetto.

DAST entra dopo che una build è stata avviata in un ambiente di test rappresentativo, prima del rilascio quando il processo lo permette. Il framework di automazione di ZAP consente di definire bersagli, autenticazione, sessioni, esplorazione e scansioni attive in un piano eseguibile. L’automazione rende ripetibile il controllo, ma la copertura dipende dagli account, dai percorsi e dai dati preparati. Una funzione mai raggiunta dallo scanner resta fuori dal risultato anche se il lavoro automatizzato termina senza errori.

Quando il secondo controllo aggiunge copertura

Se il codice è disponibile, SAST è il primo controllo utilizzabile; dopo l’avvio della build, DAST aggiunge evidenza sulle superfici realmente esposte e sulle impostazioni dell’ambiente. Se invece è disponibile solo un servizio funzionante, DAST offre un punto di partenza, ma non esamina i rami interni mai attivati dalle sue richieste. Sostituire uno strumento con l’altro significa quindi rinunciare alla visibilità del codice oppure alla prova del comportamento in esecuzione.

La combinazione minima non richiede che i due sistemi producano lo stesso elenco di difetti. Richiede un controllo del codice abbastanza vicino alla modifica da permettere una correzione tempestiva e una prova sulla build che raggiunga le funzioni importanti, comprese quelle dietro autenticazione. Il criterio decisivo è quante vulnerabilità distinte emergono dal secondo passaggio e quanto costa confermarle, non la somma degli avvisi restituiti.

Leggi anche:

• Matomo senza cookie: una riga di codice non elimina ogni obbligo
• DigComp 3.0: trasformare 21 competenze in un piano che non insegua ogni app
• n8n o Zapier Agents: una singola esecuzione può nascondere molti task