SAST, DAST e SCA: differenze e quando usarli

La risposta breve: SAST, DAST e SCA sono tre modi diversi di cercare vulnerabilità in un'applicazione. Il SAST legge il codice sorgente senza eseguirlo, il DAST attacca l'applicazione mentre gira, la SCA controlla le librerie open source e di terze parti che il codice usa. Non sono alternative: ognuno vede una parte che gli altri non vedono.

Qui trovi cosa trova ciascuno, in che ordine introdurli e dove serve una persona.

SAST, DAST e SCA in breve

• SAST, static application security testing: analisi statica del codice scritto in casa. Lavora sul sorgente, prima che l'applicazione esista come servizio.
• DAST, dynamic application security testing: test dinamico dell'applicazione in esecuzione. Lavora dall'esterno, sulle pagine e sulle API, senza guardare il codice.
• SCA, software composition analysis: analisi delle componenti. Lavora sull'elenco delle librerie e dei pacchetti che l'applicazione importa, scritti da altri.

Ogni metodo ha un punto cieco, ed è dove un altro vede bene.

SAST: l'analisi statica del codice

OWASP descrive gli strumenti SAST come strumenti di analisi del codice sorgente, o delle sue versioni compilate, che aiutano a trovare difetti di sicurezza. Si possono inserire nell'ambiente di sviluppo dello sviluppatore e nella pipeline di integrazione continua, quindi il problema emerge mentre il codice si scrive, non dopo il rilascio.

Cosa fa bene

• Scala: gira su molto codice e si può ripetere a ogni build.
• Trova difetti noti come SQL injection e buffer overflow, che hanno una firma riconoscibile nel codice.
• Dice dove intervenire: file, riga e spesso il frammento di codice coinvolto. Per chi deve correggere è il dato più utile.

Dove si ferma

La stessa pagina OWASP elenca i limiti con franchezza. Gli strumenti SAST faticano a cercare in modo automatico problemi di autenticazione, di controllo degli accessi e di uso insicuro della crittografia, e ne trovano da soli solo una percentuale relativamente piccola. Producono molti falsi positivi, spesso non vedono i problemi di configurazione (che non stanno nel codice) e rendono difficile dimostrare che un difetto segnalato sia davvero sfruttabile.

In pratica il SAST funziona quando qualcuno legge i risultati. Il NIST SSDF, nel compito PW.7.2, fa proprio questo esempio: uno strumento di analisi statica che controlla il codice, con una persona che rivede le segnalazioni e corregge dove serve.

DAST: il test dell'applicazione in esecuzione

Il DAST ragiona come un attaccante che non ha il codice. Secondo OWASP gli scanner di vulnerabilità per applicazioni web lavorano di norma dall'esterno e cercano difetti come cross-site scripting, SQL injection, command injection, path traversal e configurazioni insicure del server. È la categoria che si chiama DAST.

Cosa fa bene

• Non dipende dal linguaggio: parla con l'applicazione via HTTP, quindi non importa in cosa è scritta.
• Vede il sistema intero: codice, framework, server e configurazione insieme, cioè quello che vede un attaccante.
• Segnala comportamenti osservati: parte da una richiesta e dalla risposta che ha prodotto, quindi la segnalazione si riproduce e si verifica più facilmente.

Dove si ferma

Serve un'applicazione funzionante, quindi arriva più tardi del SAST. Non indica la riga da correggere: dice che un parametro di una pagina è vulnerabile, poi qualcuno deve risalire al codice. E vede solo quello che riesce a raggiungere: le aree dietro un login complesso o i flussi che richiedono più passaggi restano scoperti se lo scanner non è configurato bene.

SCA: le componenti scritte da altri

Il software moderno è fatto in buona parte di librerie open source e di terze parti. OWASP lo dice in modo netto nella pagina sulla component analysis: chi usa componenti open source si prende la responsabilità di codice che non ha scritto. La SCA è il sottoinsieme solo software di quell'analisi.

Uno strumento SCA fa principalmente quattro cose:

1. Inventario: elenca ogni componente e la sua versione. Senza un inventario affidabile, secondo OWASP, il resto dell'analisi non si può fare con fiducia. È qui che entra la SBOM, la distinta base del software.
2. Vulnerabilità note: confronta ogni componente con le basi di dati delle vulnerabilità, come NVD e OSV.
3. Componenti vecchi o abbandonati: segnala versioni a fine vita o non più supportate.
4. Licenze: individua le licenze di ciascun componente, perché alcune impongono obblighi che possono andare contro gli obiettivi dell'azienda.

Il rischio che la SCA copre è salito di peso. Nell'OWASP Top 10:2025 la categoria A03, Software Supply Chain Failures, è al terzo posto, ed è stata la prima nel sondaggio della community: esattamente metà dei rispondenti l'ha messa in cima. OWASP ricorda che è nata nel 2013 come uso di componenti con vulnerabilità note e che oggi comprende tutti i guasti della catena di fornitura del software, non solo le vulnerabilità. Un punto pratico che la pagina sottolinea: vanno tracciate anche le dipendenze transitive, cioè le librerie importate dalle librerie che hai scelto tu.

Le differenze, punto per punto

• Cosa analizza: il SAST il codice scritto in casa, il DAST l'applicazione in esecuzione, la SCA le componenti di terze parti.
• Quando: il SAST mentre si scrive e a ogni build, la SCA a ogni build e poi di continuo (una libreria sicura oggi può avere una vulnerabilità pubblicata domani), il DAST in ambiente di test o di staging, prima del rilascio.
• Cosa serve per partire: il SAST richiede il sorgente e un linguaggio supportato, il DAST un'applicazione raggiungibile, la SCA i file delle dipendenze o l'artefatto compilato.
• Cosa restituisce: il SAST file e riga, il DAST la richiesta che ha prodotto il difetto, la SCA il componente, la versione vulnerabile e quella corretta.
• Punto cieco: il SAST non vede configurazione e ambiente, il DAST non vede il codice, la SCA non vede i difetti del codice scritto in casa.

E IAST, secrets e infrastructure as code?

Attorno alle tre sigle ce ne sono altre. Secondo la DevSecOps Guideline di OWASP, l'IAST (interactive application security testing) inserisce dei sensori dentro l'applicazione e ne osserva il comportamento mentre viene usata durante i test: vede l'interno del codice, che al DAST manca, mentre l'applicazione è in esecuzione, cosa che al SAST manca. La scansione dei secrets cerca chiavi, token e password lasciati nel codice o nella cronologia del repository. La scansione dell'infrastructure as code controlla i template (Terraform, CloudFormation, manifest Kubernetes) prima che diventino risorse cloud. Sono complementi, non sostituti.

Servono tutti e tre? E in che ordine?

Il NIST Secure Software Development Framework (SP 800-218, versione 1.1 del febbraio 2022, con una revisione 1.2 in bozza dal dicembre 2025) non nomina prodotti, ma prevede entrambe le attività: la pratica PW.7 riguarda la revisione e l'analisi del codice leggibile, la PW.8 il test del codice eseguibile, e fra gli esempi della PW.8.2 c'è l'inserimento dei test dinamici di vulnerabilità nella suite di test automatici. Per le componenti esterne, la PW.4.1 indica fra gli esempi di raccogliere informazioni sulla provenienza di ciascun componente, citando la SBOM e l'analisi della composizione del sorgente e dei binari.

Per un'azienda mid-market che sviluppa applicazioni proprie, un ordine ragionevole è questo:

1. SCA per prima. Si introduce in fretta, lavora su un dato concreto (quale componente, quale versione) e copre la parte di codice che nessuno in azienda ha scritto né letto.
2. SAST nella pipeline, partendo dalle regole più affidabili e allargando quando il team ha preso il ritmo di gestire le segnalazioni. Uno strumento che produce centinaia di avvisi ignorati non serve.
3. DAST sulle applicazioni esposte, in staging, prima dei rilasci importanti e a intervalli regolari.

Il criterio che decide, più dello strumento, è chi legge i risultati e chi corregge. Il NIST indica di registrare e smistare ogni problema trovato nel flusso di lavoro del team di sviluppo (PW.7.2 e PW.8.2): un risultato che resta in una console separata non diventa una correzione. È il principio del DevSecOps: i controlli girano nella pipeline e i risultati arrivano a chi scrive il codice.

Dove gli scanner si fermano: il penetration test

I tre strumenti trovano bene i difetti noti e ripetibili. Faticano invece proprio dove OWASP colloca i limiti del SAST: autenticazione, controllo degli accessi, logica applicativa. Un utente che modificando un identificativo nell'URL vede l'ordine di un altro cliente non lascia una firma nel codice e non produce un errore che uno scanner riconosca.

Il NIST SSDF, nella PW.8.2, indica il penetration test per simulare come un attaccante proverebbe a compromettere il software negli scenari ad alto rischio. È un'attività che si aggiunge ai test automatici, non che li sostituisce. Trovi come funziona in software penetration test: cos'è e cosa trova e, per le applicazioni web, in web application penetration test.

Dal codice al cloud

Per chi lavora sul cloud, SAST, DAST e SCA sono metà del quadro. Una libreria vulnerabile pesa in modo diverso se gira in un container esposto su internet con un ruolo che legge il database dei clienti, o in un servizio interno senza accessi rilevanti. Il collegamento fra il difetto nel codice e il contesto in cui gira è il lavoro delle piattaforme CNAPP, che si sono allargate verso la pipeline di sviluppo.

Wiz, di cui siamo partner, lo fa con Wiz Code. Secondo la pagina del prodotto, la componente di application security posture management raccoglie e correla i risultati di scanner propri e di terze parti (SAST, SCA, DAST e altri), la SCA rileva le vulnerabilità nelle dipendenze dirette e transitive e dà priorità a quelle raggiungibili usando il contesto a runtime del Wiz Sensor, e le correzioni si propongono nell'IDE, nelle pull request o nella pipeline. La mappatura dal cloud al codice riporta un rischio trovato in produzione al sorgente che l'ha generato. Il resto della piattaforma è nel nostro approfondimento su Wiz e la cloud security di Google.

Cosa c'entrano NIS2 e ISO 27001

Nessuna norma obbliga a usare SAST, DAST o SCA per nome. Ma per chi sviluppa software sono il modo più diretto di produrre evidenze su misure che le norme chiedono.

• NIS2: l'art. 24, comma 2, del D.Lgs. 138/2024 elenca fra gli elementi minimi delle misure di gestione del rischio la lettera e), "sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete, ivi comprese la gestione e la divulgazione delle vulnerabilità". La lettera d) aggiunge la sicurezza della catena di approvvigionamento, che per il software passa anche dalle librerie di terze parti.
• ISO/IEC 27001:2022: nell'Annex A i controlli 8.25, 8.28 e 8.29 riguardano lo sviluppo sicuro del software e i relativi test di sicurezza. Un auditor chiederà come si verifica il codice prima del rilascio: i risultati di questi test, con le correzioni tracciate, sono la risposta.

Da dove partire

Se le tue applicazioni girano sul cloud, il primo passo utile è sapere quali difetti del codice arrivano davvero in produzione e cosa raggiungono una volta lì. Con la fotografia del tuo cloud mettiamo in fila i rischi del tuo ambiente, codice compreso, e ti diciamo da quali conviene partire.