SDLC sicuro e strumenti SAST e DAST

Il Secure Software Development Lifecycle (SSDLC) integra le attività di sicurezza in ogni fase dello sviluppo software, dai requisiti alla progettazione, alla codifica, ai test, alla distribuzione e alla manutenzione. L'SDLC tradizionale considera la sicurezza un controllo finale, costoso e inefficace. La filosofia del secure SDLC consiste nell'individuare e correggere le vulnerabilità il prima possibile, perché correggere i difetti rilevati durante la progettazione costa molto meno che correggere quelli scoperti in produzione.

Shift left significa anticipare la sicurezza (spostandola verso sinistra nella sequenza temporale dello sviluppo) invece di aggiungerla all'ultimo momento. In pratica, significa includere i requisiti di sicurezza nelle user story, eseguire il threat modeling durante la progettazione, effettuare la revisione del codice e i test SAST durante lo sviluppo, ed eseguire DAST prima del rilascio. I team che applicano lo shift left scoprono le vulnerabilità quando correggerle è meno costoso: durante lo sviluppo, non in produzione.

Il threat modeling identifica e documenta sistematicamente le minacce alla sicurezza durante la fase di progettazione. Il modello STRIDE suddivide le minacce in: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service ed Elevation of Privilege. PASTA (Process for Attack Simulation and Threat Analysis) è una metodologia incentrata sul rischio che simula gli obiettivi degli aggressori. I modelli delle minacce producono contromisure prioritarie prima che venga scritta una sola riga di codice.

SAST (test white-box) analizza il codice sorgente, il bytecode o i binari senza eseguire l'applicazione, cercando schemi di codifica associati a vulnerabilità note. Gli strumenti SAST possono analizzare rapidamente l'intera codebase e segnalare problemi come credenziali hardcoded, punti di iniezione SQL e deserializzazione non sicura. Vengono eseguiti all'interno dell'IDE o della pipeline CI e riportano i risultati con i numeri di file e riga, rendendo semplice la correzione.

Un limite importante di SAST è la tendenza a produrre falsi positivi, segnalando come vulnerabile codice che in realtà è sicuro. Questa fatica da allarmi porta gli sviluppatori a ignorare i risultati senza analizzarli. Gli strumenti SAST inoltre non possono rilevare problemi di configurazione a runtime, vulnerabilità di autenticazione che dipendono dal comportamento a runtime o vulnerabilità nelle chiamate API di terze parti. SAST è più efficace se combinato con la formazione degli sviluppatori, così da consentire una corretta valutazione dei risultati.

DAST (test black-box) verifica un'applicazione in esecuzione inviando payload di attacco ai suoi endpoint HTTP e analizzando le risposte alla ricerca di indicatori di vulnerabilità. DAST non richiede l'accesso al codice sorgente: verifica l'applicazione come farebbe un aggressore. È particolarmente efficace nell'individuare problemi a runtime come l'elusione dell'autenticazione, l'XSS riflesso nelle risposte e la configurazione errata del server. Tra gli strumenti DAST rientrano OWASP ZAP, Burp Suite e Netsparker.

SAST e DAST sono complementari, non concorrenti. SAST individua tempestivamente i problemi a livello di codice e si integra con l'IDE, ma non ha visibilità sul comportamento a runtime. DAST individua le vulnerabilità a runtime e non richiede il codice sorgente, ma non può analizzare i percorsi di codice che non vengono attivati dalle sue sonde automatizzate. Utilizzandoli insieme, con SAST nella pipeline CI e DAST su un ambiente di staging, si massimizza la copertura delle vulnerabilità nell'intero SDLC.

IAST combina aspetti di SAST e DAST strumentando l'applicazione a runtime. Un agente IAST viene eseguito all'interno dell'applicazione (sul server) e osserva l'esecuzione del codice mentre il traffico di test la attraversa. Può correlare l'input utente contaminato lungo i percorsi del codice fino ai punti sensibili, individuando vulnerabilità con un tasso di falsi positivi inferiore rispetto al SAST puro. IAST è particolarmente efficace nelle applicazioni Java e .NET e si integra naturalmente nelle esecuzioni dei test funzionali.

Software Composition Analysis (SCA) identifica le librerie open source e le dipendenze di terze parti presenti in un'applicazione e le confronta con i database delle vulnerabilità (NVD, OSV). Poiché le applicazioni moderne possono includere centinaia di dipendenze, molte delle quali transitive, strumenti SCA come OWASP Dependency-Check, Snyk e Renovate sono essenziali per individuare le CVE note prima che gli aggressori possano sfruttarle nella supply chain.

L'integrazione degli strumenti di sicurezza nelle pipeline CI/CD garantisce che nessun codice raggiunga la produzione senza superare i controlli di sicurezza. Una tipica pipeline DevSecOps esegue: SAST a ogni commit, SCA in caso di modifiche alle dipendenze, scansione delle immagini dei container prima del push nel registry, scansione IaC per Terraform/CloudFormation e DAST su una distribuzione di staging. I controlli di sicurezza falliti bloccano la build, rafforzando una cultura della sicurezza predefinita.

Gli strumenti automatizzati non possono sostituire la revisione del codice umana incentrata sulla logica di sicurezza. La revisione tra pari dovrebbe verificare che: i controlli di autenticazione e autorizzazione siano nei punti corretti; la gestione degli errori non divulghi informazioni sensibili; le funzioni crittografiche utilizzino algoritmi e parametri approvati; e la logica di business non possa essere aggirata. I security champion all'interno dei team di sviluppo, cioè sviluppatori con una formazione sulla sicurezza, colmano il divario tra il team di sicurezza e quello tecnico.

Verifichi la Sua comprensione dei concetti di CompTIA Security+ (SY0-701) trattati in questa lezione.

In questa lezione ha imparato che: il secure SDLC integra la sicurezza in tutte le fasi dello sviluppo invece di aggiungerla all'ultimo momento; SAST analizza il codice senza eseguirlo, mentre DAST verifica le applicazioni in esecuzione; e SCA identifica le dipendenze open source vulnerabili, mentre i controlli di sicurezza CI/CD applicano automaticamente i risultati. Nel prossimo argomento esamineremo i servizi di directory con LDAP e Active Directory.