SAST e DAST: che cosa s’intende

SAST e DAST sono acronimi che identificano due differenti tipi di test per la sicurezza delle applicazioni, meglio noti come AST (Application Security Testing). In questo articolo approfondiremo il ruolo cruciale che questi test svolgono nella fase di sviluppo di un software nonché le normative che ne regolano l’implementazione.

1. SAST e DAST, espressione della Security by Design
2. SDLC, il ciclo di vita del software
3. Dal modello agile al devsecops: il ruolo cruciale della sicurezza informatica
4. Perché SAST e DAST sono indispensabili durante l’SDLC
5. SAST, cos’è
6. DAST, cos’è
7. SAST e DAST a confronto
8. Altre tipologie di AST IAST RASP e SCA

SAST e DAST: espressione della Security-by-Design

Negli ultimi decenni, gli applicativi software hanno giocato un ruolo sempre più strategico per le aziende, portando all’attuale Quarta rivoluzione industriale. Al crescere della loro importanza nel core business aziendale, anche la preservazione delle loro funzionalità si è via via rivelata imprescindibile. Da un paradigma di sviluppo software a cascata (o by-default), in cui i test sulla sicurezza erano relegati all’ultimo stadio, si è passati dunque a una configurazione agile (o circolare), che li integra come parte fondante dell’implementazione e della progettazione software.

Questo è il principio cardine della security-by-design, regolata dalle norme

• ISO/IEC 27001, meglio noto come Standard internazionale per la sicurezza dell’informazione
• ISO/IEC 27034, sub-standard specificamente rivolto alla regolamentazione della sicurezza delle applicazioni.

Per comprendere appieno il ruolo svolto da SAST e DAST nell’implementazione di applicazioni web-based è opportuna una breve digressione su come questa venga effettivamente strutturata.

SDLC, ovvero il ciclo di vita del software

L’SDLC (Software Development Life Cycle) è un framework attraverso il quale vengono definiti tutti gli step di progettazione, test e distribuzione dei software. Questo framework viene impiegato per far sì che il software rispecchi i requisiti funzionali per i quali è stato progettato.
La sua importanza è tale da essere stato anch’esso inserito in uno standard internazionale: l’ISO/IEC 12207. In altre parole, SDLC non è altro che una scansione sequenziale di azioni il cui prodotto finale è appunto l’applicativo web o l’applicazione mobile.

Pertanto, esso può essere declinato in una serie di modelli, quali:

• a cascata
• Agile
• a V
• iterativo
• a spirale
• Big Bang, ecc.

Ai fini della trattazione sarà esaustivo concentrarsi essenzialmente sul modello Agile – di cui DevOps rappresenta un ulteriore avanzamento – per capire come questo abbia determinato un vero e proprio salto di qualità in ambito sviluppo e commercializzazione software.

Dal modello Agile al DevSecOps: il ruolo cruciale della sicurezza informatica

Il modello SDLC Agile non era che una prefigurazione di quello che oggi è considerato lo standard di produzione software: il DevSecOps. Questo modello prevede infatti la suddivisione del prodotto in piccole build con funzionalità incrementale e il fondamento della sua riuscita è costituito da due fattori principali:

• esecuzione di test durante ogni fase;
• manutenzione del prodotto in relazione ai report dei test e/o degli utenti che ne faranno uso.

Un processo, dunque, che si nutre di costante analisi e miglioramento. Quando il livello di integrazione delle procedure non interessa più soltanto il prodotto in sé, ma anche i team coinvolti nella sua implementazione si parla di un ulteriore salto di paradigma: il DevOps, appunto. DevOps in realtà è l’acronimo di Developement (sviluppo) e Operations (operazioni): questo modello, oltre a sfruttare l’automatizzazione e la standardizzazione del ciclo di vita delle applicazioni, implica un team di lavoro collaborativo, che quindi abbia luogo su piattaforme di automazione integrata.

Tutto si gioca in un flusso di integrazione e distribuzione continua:

• CI – I Continuous Integration
• CD – Continuous Delivery

Se, quindi, da un lato il DevOps implica una fusione di competenze di operazione e sviluppo, il DevSecOps include il fattore sicurezza IT. Ciò significa che la sicurezza del software diviene responsabilità condivisa ed è pertanto necessario assumerla come linea guida sin nei primissimi step di progettazione e implementazione del software.

Perché SAST e DAST sono indispensabili durante l’SDLC

SAST e DAST rientrano nel più ampio insieme delle pratiche di cybersecurity note come Vulnerability Assessment, ossia volte a individuare tutte le potenziali vulnerabilità di un sistema informatico.

OWASP (Open Web Application 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: ossia la progettazione e implementazione scorretta delle applicazioni web. L’utilità di questa tipologia di strumento per la cybersecurity sta proprio nel suo carattere di automazione. Mentre strumenti di ethical hacking, come ad esempio il penetration test, necessitano dello studio specifico caso per caso, SAST e DAST si presentano come procedure eseguibili con l’ausilio di procedure automatizzate, in grado anche fornire un report immediato sulla situazione.

Certo è che la lettura dei dati in esso contenuti richiede necessariamente l’intervento di un esperto in web-application security per poter essere correttamente interpretata: d’altro canto, l’automazione del processo apporta notevoli benefici in termini di tempistiche e relativa maggior facilità di applicazione. Approfondiamo ora nello specifico in cosa consistano effettivamente SAST e DAST.

SAST: cos’è

Il SAST (Static Application Security Test) è anche conosciuto come Test della Scatola Bianca (o White Box Security Test).

SAST viene così denominato perché si occupa di analizzare le criticità presenti nel codice binario, nel bytecode e nel codice sorgente dell’applicazione web senza che questo venga eseguito. L’obiettivo principale è quello di scandagliare il programma per verificarne la conformità alle linee guida di coding: qualora questa venisse a mancare in una qualsiasi porzioni di codice, infatti, potrebbe costituire una facile porta di accesso per un hacker. Con il SAST, insomma, si riescono a rilevare i bug da risolvere attraverso l’installazione di adeguate patch di sicurezza.

DAST: cos’è

Il DAST (Dynamic Application Security Test), noto anch’esso con il duplice appellativo di test della scatola nera (Black Box Security Test). Dal canto suo, il DAST non ha accesso al codice sorgente, ma, simulando il comportamento che l’applicativo assumerebbe nel suo build di esecuzione, ne individua problematiche di:

• input e output
• gestione degli errori
• configurazioni.

DAST quindi è un’analisi eseguita dall’esterno, che prende in esame essenzialmente il comportamento dell’applicativo web-based nell’interazione con l’utente contestualizzandolo in un determinato ambiente di runtime.

SAST e DAST a confronto

SAST e DAST sono strumenti di cybersecurity spesso utilizzate in complementarietà: l’una infatti è debole lì dove l’altra eccelle.
Ecco quindi un esaustivo raffronto tra i pro e i contro di entrambe le tecniche di analisi.

• l’analisi SAST segnala errori di codice, mentre la DAST anomalie di runtime;
• SAST è più facilmente integrabile in un IDE, ma genera un numero maggiore di falsi positivi o falsi negativi non trascurabile. Mentre il DAST è fortemente dipendente dall’ambiente in cui viene eseguita, nonché più lenta e meno scalabile
• di contro, SAST non è molto efficiente nel trovare errori nel flusso di dati.

Altre tipologie di AST: IAST, RASP e SCA

Oltre agli ormai noti SAST e DAST, le metodologie di testing si sono sviluppate fino a comprendere un’ampia gamma di soluzioni. Eccone una breve carrellata:

• SCA (Software Composition Analysis), utilizzata per testare applicativi legacy che utilizzano codici open source o di terze parti
• IAST (Interactive application security testing) combina i vantaggi di SAST e DAST ed è specificamente rivolto ad applicazioni web mobili. IAST è in grado di rilevare e segnalare anomalie anche quando l’applicazione è in esecuzione.
• RASP (Autoprotezione delle applicazioni runtime): è un’applicazione runtime integrata direttamente nell’applicativo mobile per  consentirgli proteggersi in autonomia. RASP è in grado di identificare e bloccare in tempo reale eventuali attacchi malware.