SAST vs DAST vs IAST vs SCA - Application Security Testing

Mappa globale - Application Security Testing

#

Che cos'e' l'Application Security Testing

#

L'Application Security Testing (AST) comprende tutti i metodi per trovare vulnerabilita' in un'applicazione prima che un attaccante le sfrutti. Esistono quattro approcci principali, ognuno con una prospettiva diversa: sul codice, sull'applicazione in esecuzione, sull'interno del runtime, o sulle dipendenze di terze parti.

Conoscere quando usare ciascuno - e quali vulnerabilita' trova o non trova - e' fondamentale per l'esame Security+.

SAST - Static Application Security Testing

#

Il SAST analizza il codice sorgente di un'applicazione senza eseguirla, cercando pattern che indicano vulnerabilita' note. E' chiamato "white-box" perche' ha visibilita' completa sul codice.

Esempio di output reale: uno scanner SAST su test.c segnala alla riga 73 l'uso di SetSecurityDescriptorDacl con parametro NULL per l'ACL. Un'ACL NULL significa accesso per chiunque, incluso un attaccante che potrebbe impostare "Everyone: Deny All" rendendo l'oggetto inaccessibile persino agli amministratori.

Dev parallel: SAST e' quello che gia' conosci come analisi statica nel tuo workflow quotidiano. SonarQube, PHPStan, ESLint con plugin di security analizzano il codice sorgente senza eseguirlo. Il limite e' lo stesso: non rilevano vulnerabilita' che emergono solo a runtime (una logica di autenticazione che "funziona" ma puo' essere bypassata). In Symfony, PHPStan al livello 8 e' essenzialmente un SAST.

DAST - Dynamic Application Security Testing

#

Il DAST analizza l'applicazione mentre e' in esecuzione, mandando input reali e osservando le risposte. E' "black-box": non vede il codice sorgente, simula esattamente la prospettiva di un attaccante esterno.

Dev parallel: composer audit e npm audit sono non intrusivi (leggono solo le versioni, zero rischio per l'app). Un test DAST che lancia davvero un payload SQLi contro un endpoint e' intrusivo: puo' far esplodere una query, riempire un log, o bloccare il servizio. E' lo stesso principio di terraform plan (non intrusivo, sola lettura) vs terraform apply (intrusivo, modifica davvero l'infrastruttura).

IAST - Interactive Application Security Testing

#

L'IAST usa un agente strumentato dentro l'applicazione durante il runtime. E' "gray-box": ha visibilita' sia sul codice che sul comportamento reale, combinando i vantaggi di SAST e DAST.

L'IAST e' meno comune all'esame Security+ rispetto a SAST e DAST, ma compare nelle domande di confronto. Il punto chiave: e' gray-box (ne' completamente cieco come DAST, ne' solo su codice fermo come SAST).

SCA - Software Composition Analysis

#

La SCA analizza le dipendenze e librerie di terze parti usate dall'applicazione, cercando CVE note nei componenti open source. Non analizza il codice custom: si concentra su quello che importi, non su quello che scrivi.

Dev parallel: per Barno con Symfony e Node, SCA e' gia' parte del workflow quotidiano. composer audit e npm audit sono SCA integrati nel package manager. GitHub Dependabot e' SCA automatizzato come GitHub Action: apre una PR in automatico quando trova una CVE in una dipendenza. Trivy e' SCA per immagini Docker: trivy image myapp:latest scansiona tutti i package installati nell'immagine e li confronta con il database CVE.

Confronto finale e Pipeline CI/CD

#

Ogni metodo ha il suo posto ideale nella pipeline. Usarli insieme fornisce copertura a diversi livelli.

flowchart LR
    DEV[Developer commit]
    SCA[SCA\nnpm audit\ncomposer audit]
    SAST[SAST\nSonarQube\nSemgrep]
    BUILD[Build artifact]
    IAST[IAST\nContrast Security\nin test env]
    STAGING[Staging deploy]
    DAST[DAST\nOWASP ZAP\nBurp Suite]
    PROD[Production]

    DEV --> SCA
    SCA --> SAST
    SAST --> BUILD
    BUILD --> IAST
    IAST --> STAGING
    STAGING --> DAST
    DAST --> PROD

Dev parallel: questo e' il DevSecOps pipeline ideale per un progetto Symfony/Node. In pratica: Dependabot per SCA automatico su GitHub, PHPStan + ESLint in pre-commit hook per SAST leggero, SonarQube integrato nella GitHub Action per SAST completo su ogni PR, OWASP ZAP in modalita' automated scan contro lo staging prima del deploy in produzione.