Il Secure SDLC (Secure Software Development Life Cycle, ciclo di vita sicuro dello sviluppo software) è l’insieme delle pratiche che integrano la sicurezza in ogni fase del processo di sviluppo del software — dalla raccolta dei requisiti all’architettura, dall’implementazione al testing, dal rilascio alla manutenzione — invece di considerarla un’attività di verifica separata da eseguire alla fine. L’obiettivo è spostare la sicurezza a sinistra (shift left): individuare e correggere le vulnerabilità il prima possibile nel processo di sviluppo, quando il costo di correzione è minimo.
Il costo della vulnerabilità nel tempo
Studi classici (IBM Systems Sciences Institute) mostrano che il costo di correzione di un bug di sicurezza cresce esponenzialmente con il ritardo:
| Fase di scoperta | Costo relativo |
|---|---|
| Requisiti / Design | 1× |
| Implementazione | 6× |
| Testing | 15× |
| Post-rilascio (produzione) | 100× |
Una vulnerabilità di SQL injection scoperta in code review costa ore di lavoro; la stessa vulnerabilità scoperta dopo un incidente in produzione costa giorni di remediation, notifica breach, reputazione e potenzialmente sanzioni GDPR.
Modelli di riferimento
Microsoft SDL (Security Development Lifecycle, 2004): il modello originale, introdotto da Microsoft dopo le crisi di sicurezza di Windows XP. Strutturato per fasi (training, requirements, design, implementation, verification, release, response) con attività di sicurezza obbligatorie per ognuna.
OWASP SAMM (Software Assurance Maturity Model): framework open source per valutare e migliorare le pratiche di sicurezza dello sviluppo, organizzato in cinque domini (Governance, Design, Implementation, Verification, Operations) con tre livelli di maturità.
BSIMM (Building Security In Maturity Model): misura empiricamente le pratiche di sicurezza delle organizzazioni che sviluppano software, basato su dati reali di decine di aziende. Descrittivo (cosa fanno le organizzazioni mature) più che prescrittivo.
Attività chiave per fase
Requisiti: identificare i requisiti di sicurezza funzionali e non funzionali; definire il livello di classificazione del dato; valutare i requisiti di compliance (GDPR, PCI DSS, ecc.).
Design: eseguire il threat modeling (identificazione sistematica delle minacce architetturali tramite metodologie come STRIDE o PASTA); definire i principi di sicurezza dell’architettura (principio del minimo privilegio, defense in depth, fail secure).
Implementazione: code review con focus sulla sicurezza; SAST (Static Application Security Testing) — analisi statica del codice sorgente alla ricerca di pattern vulnerabili; gestione sicura delle dipendenze (SCA, Software Composition Analysis) per rilevare librerie con CVE note.
Testing: DAST (Dynamic Application Security Testing) — test della applicazione in esecuzione; IAST (Interactive AST) — strumentazione del runtime; penetration testing dell’applicazione prima del rilascio.
Rilascio e operazioni: gestione sicura dei segreti (no credenziali hardcodate); pipeline CI/CD con controlli di sicurezza automatizzati; monitoraggio continuo in produzione; processo di patch management per le vulnerabilità post-rilascio.
DevSecOps
L’evoluzione moderna del Secure SDLC in ambienti agili e CI/CD è il DevSecOps: l’integrazione della sicurezza direttamente nella pipeline DevOps, con controlli automatizzati ad ogni commit (SAST, SCA, container scanning, IaC scanning). L’obiettivo è che la sicurezza non rallenti la velocità di sviluppo ma sia parte trasparente del processo.