Sviluppo software sicuro: Guida DevSecOps 2026

Threat modelling per funzionalità e design review prima dello sviluppo

Il threat modelling non è un documento da produrre una volta all'anno, ma una breve sessione svolta all'inizio di ogni funzionalità significativa. Vi partecipano il product owner, chi scrive il codice e una figura con competenze di sicurezza. In genere bastano sessanta minuti per rispondere a quattro domande: cosa si costruisce, cosa può andare storto, quanto è probabile e come ridurlo.

Gli schemi più usati restano STRIDE per classificare le minacce e i modelli di abuso, mentre tecniche come le storie di abuso e i diagrammi di flusso dei dati rendono visibili i confini di fiducia. Il risultato è un elenco di requisiti di sicurezza verificabili, che entrano nel backlog come qualsiasi altra attività, con una stima e un responsabile assegnato.

Design review e criteri di accettazione

Quando la funzionalità tocca autenticazione, pagamenti, dati personali o integrazioni esterne, è opportuno un design review formale prima dell'implementazione. Si esaminano il modello dei permessi, la validazione degli ingressi, la gestione degli errori e la registrazione degli eventi. Ogni requisito approvato diventa un criterio di accettazione, così la verifica non dipende dalla memoria di chi rilascia.

SAST, DAST e SCA nella pipeline con soglie di fallimento esplicite

Una pipeline di sicurezza efficace non produce report consultivi, ma interrompe la promozione quando una soglia concordata viene superata. La scansione statica (SAST) analizza il codice sorgente durante la compilazione; l'analisi dinamica (DAST) prova l'applicazione in esecuzione su un ambiente di test; l'analisi delle dipendenze (SCA) confronta le librerie con banche dati di vulnerabilità note.

La differenza tra un controllo utile e rumore di fondo sta nelle soglie, da definire in anticipo: quale severità blocca la build, quali eccezioni sono ammesse, chi approva una deroga e per quanto tempo resta valida. Le esenzioni devono avere una data di scadenza, altrimenti si accumulano e diventano permanenti.

Esempi di soglie operative

• Blocco immediato per vulnerabilità critiche o alte sfruttabili su percorsi esposti a Internet.
• Blocco per segreti rilevati nel repository o nella cronologia dei commit.
• Segnalazione senza blocco per informativa a bassa severità, con revisione periodica.

Segreti, dipendenze e catena di fornitura

La scansione dei segreti cerca chiavi API, token e password nel codice e in tutta la cronologia Git. Quando un segreto viene esposto, la correzione non consiste nel rimuoverlo dal file: la chiave va revocata e ruotata, perché resta recuperabile nei commit precedenti. La procedura prevede la revoca immediata, l'emissione di una nuova credenziale, l'aggiornamento dei sistemi che la usano e la verifica che la vecchia non funzioni più.

Sul fronte delle dipendenze, l'uso di file di lock impedisce aggiornamenti silenziosi e rende gli ambienti riproducibili. La verifica delle firme dei pacchetti e della loro provenienza riduce il rischio di artefatti alterati. Un inventario software in formato CycloneDX, noto come SBOM, documenta componenti e versioni. Le attestazioni di provenienza secondo lo standard SLSA collegano ogni artefatto alla pipeline che lo ha prodotto.

L'analisi dell'infrastruttura come codice (IaC) sottopone i file di configurazione a controlli automatici: permessi eccessivi, cifratura assente, servizi esposti.

Baseline OWASP ASVS, SLA di remediation e Cyber Resilience Act

OWASP ASVS fornisce una base di verifica strutturata in livelli crescenti. Conviene assegnare a ogni applicazione un livello obiettivo in funzione dell'esposizione e dei dati trattati, e registrare la conformità raggiunta.

Le vulnerabilità accettate nel backlog hanno bisogno di scadenze. Si definisce un tempo massimo di correzione per severità e lo si applica come qualsiasi impegno di prodotto, con revisione periodica dei casi in ritardo. Il modello del security champion assegna a un membro del team di sviluppo il ruolo di riferimento per la sicurezza, in collegamento con il team centrale: la sicurezza entra nelle decisioni quotidiane invece di essere delegata a un reparto separato.

Per i prodotti con elementi digitali immessi nel mercato dell'Unione europea si applica il Cyber Resilience Act (Regolamento UE 2024/2847), che introduce obblighi di sicurezza lungo l'intero ciclo di vita, dalla progettazione al supporto post-vendita, oltre alla gestione delle vulnerabilità e alla comunicazione degli incidenti gravi. Il rilascio va accompagnato da un sign-off esplicito che attesta i controlli eseguiti e seguito da un monitoraggio post-release su log, avvisi e canali di segnalazione.