Indice dei contenuti
- Cos’è davvero il threat modeling (e cosa non è)
- Il paradosso del “lo faremo dopo”
- Quando il threat modeling diventa un documento morto
- Applicazioni cloud: il cambiamento continuo ignorato
- STRIDE: l’acronimo che pochi conoscono davvero
- Dev team e sicurezza: una frattura culturale
- Perché si scoprono le minacce solo dopo l’incidente
- Integrare il threat modeling nel ciclo di sviluppo
- Il costo reale di ignorarlo
Il threat modeling viene spesso citato come “best practice”, ma raramente vissuto come tale. Nei documenti di progetto compare, nei framework di sicurezza è sempre presente, nei corsi viene spiegato con diagrammi ordinati e acronimi rassicuranti. Eppure, quando avviene un incidente serio, una violazione o un data breach, la frase che torna più spesso è sempre la stessa: “se avessimo fatto threat modeling prima…”.
Questo articolo nasce proprio da qui. Non per spiegare cos’è il threat modeling a livello introduttivo, ma per analizzare perché viene sistematicamente ignorato, ridotto a documento statico o affrontato troppo tardi. E soprattutto per chiarire perché il threat modeling non è un file da archiviare, ma una pratica viva, continua, che deve evolvere insieme al software, al cloud e all’organizzazione.
Cos’è davvero il threat modeling (e cosa non è)
Il threat modeling non è una checklist, non è una slide di fine progetto e non è un esercizio da fare “una volta per stare tranquilli”. È un processo strutturato per identificare minacce, valutare impatti e progettare mitigazioni prima che i problemi diventino incidenti reali.
Il suo valore non sta tanto nel modello finale, quanto nelle domande che costringe a porsi. Chi può attaccare questo sistema? Da dove? Con quali obiettivi? Quali asset sono davvero critici? Cosa succede se questa parte viene compromessa?
Il problema è che nella pratica il threat modeling viene spesso trattato come un obbligo formale. Un documento PDF prodotto all’inizio del progetto, firmato, archiviato e mai più riaperto. In quel momento smette di essere threat modeling e diventa solo compliance cosmetica.
Il paradosso del “lo faremo dopo”
Uno dei motivi principali per cui il threat modeling arriva sempre tardi è culturale. Nei team di sviluppo domina ancora l’idea che la sicurezza sia qualcosa da affrontare dopo: dopo il rilascio, dopo il primo cliente, dopo che il prodotto “funziona”.
Questa mentalità è figlia di anni di sviluppo orientato alla velocità, dove tutto ciò che rallenta viene percepito come un ostacolo. Il threat modeling, se fatto bene, rallenta. Costringe a fermarsi, a discutere, a mettere in dubbio scelte architetturali già prese.
Il risultato? Viene rimandato. Prima si scrive il codice, poi si deploya in cloud, poi si aggiungono integrazioni, API, automazioni. E solo quando qualcosa va storto ci si chiede quali minacce non erano state considerate.
Quando il threat modeling diventa un documento morto
Uno degli errori più comuni è trattare il threat modeling come un output anziché come un processo. Si crea un modello iniziale, spesso durante la fase di design, e poi non viene mai più aggiornato.
Nel frattempo, però, il sistema cambia. Cambiano le dipendenze, cambiano i flussi di dati, cambiano i provider cloud, cambiano i confini di rete. Ma il documento resta lo stesso. Questo crea un falso senso di sicurezza estremamente pericoloso.
Un threat model non aggiornato è spesso peggio di nessun threat model. Illude il team di aver già valutato i rischi, mentre in realtà il sistema reale non assomiglia più a quello disegnato nei diagrammi.
Applicazioni cloud: il cambiamento continuo ignorato
Nel contesto cloud, il problema si amplifica. Le applicazioni moderne non sono statiche: sono composte da microservizi, funzioni serverless, pipeline CI/CD, servizi gestiti e integrazioni di terze parti.
Ogni modifica introduce nuove superfici di attacco. Una nuova API pubblica, un bucket esposto, un ruolo IAM troppo permissivo. Ma raramente queste modifiche vengono accompagnate da una rivalutazione del threat modeling.
Il motivo è semplice: il cloud dà l’illusione che la sicurezza sia “inclusa”. Se il provider è grande e certificato, allora il sistema sarà sicuro. Ma il shared responsibility model dice tutt’altro. Il provider protegge l’infrastruttura, non le tue scelte architetturali.
Senza un threat modeling continuo, il cloud diventa un moltiplicatore di rischi silenziosi.
STRIDE: l’acronimo che pochi conoscono davvero
Molti sviluppatori hanno sentito nominare STRIDE, ma pochi sanno davvero applicarlo. E ancora meno team lo usano in modo sistematico.
STRIDE non è solo un acronimo da ricordare, ma una lente attraverso cui osservare il sistema:
- Spoofing
Chi può fingere un’identità? - Tampering
Cosa può essere modificato? - Repudiation
Cosa non può essere tracciato? - Information Disclosure
Cosa può trapelare? - Denial of Service
Cosa può essere reso indisponibile? - Elevation of Privilege
Chi può ottenere più potere del previsto?
Il problema è che nei team di sviluppo spesso manca la formazione. Il threat modeling viene visto come qualcosa da “security team”, mentre i Dev team non vengono messi nelle condizioni di usarlo come strumento quotidiano.
Dev team e sicurezza: una frattura culturale
Una delle cause strutturali del fallimento del threat modeling è la separazione tra chi sviluppa e chi si occupa di sicurezza. Quando il threat modeling è delegato a un team esterno o a una funzione isolata, perde efficacia.
Chi scrive il codice conosce i dettagli reali del sistema. Chi fa sicurezza spesso arriva dopo, quando le decisioni architetturali sono già consolidate. Il threat modeling dovrebbe essere un momento di confronto, non un audit a posteriori.
Senza integrazione reale tra sviluppo e sicurezza, il threat modeling diventa un esercizio teorico, scollegato dalla realtà del codice e delle pipeline.
Perché si scoprono le minacce solo dopo l’incidente
Quando avviene un incidente serio, l’analisi post-mortem rivela quasi sempre lo stesso schema. La minaccia non era “sofisticata”, ma prevedibile. Un accesso non autenticato, un ruolo troppo permissivo, un flusso di dati non cifrato.
Queste non sono minacce zero-day. Sono errori di progettazione che un threat modeling fatto bene avrebbe potuto intercettare. Il problema è che nessuno si era fermato a porsi le domande giuste.
Il threat modeling serve proprio a questo: rendere esplicite le ipotesi implicite. Quando non viene fatto, le ipotesi restano invisibili fino a quando non vengono sfruttate.
Il threat modeling come pratica viva
La svolta arriva quando il threat modeling smette di essere un evento e diventa una pratica continua. Non un documento, ma una conversazione ricorrente.
Ogni cambiamento significativo dovrebbe attivare una revisione: una nuova integrazione, un cambio di architettura, un nuovo flusso di dati. Non serve rifare tutto da zero, ma aggiornare il modello esistente.
Questo approccio richiede maturità organizzativa, ma riduce drasticamente il numero di sorprese. Il threat modeling vivo cresce insieme al sistema, invece di inseguirlo.
Integrare il threat modeling nel ciclo di sviluppo
Per funzionare davvero, il threat modeling deve essere parte del ciclo di sviluppo, non un’attività separata. Deve vivere accanto al design, al codice, ai test.
In contesti DevSecOps, questo significa introdurlo nei momenti giusti: durante le design review, nelle retrospettive, nei cambi architetturali. Anche una sessione breve, ma frequente, è più efficace di un workshop annuale.
Il valore non sta nella perfezione del modello, ma nella continuità dell’attenzione.
Il costo reale di ignorarlo
Ignorare il threat modeling non fa risparmiare tempo. Lo sposta semplicemente più avanti, quando il costo è molto più alto. Correggere un problema di sicurezza in produzione è sempre più costoso che prevenirlo in fase di design.
C’è anche un costo reputazionale. Ogni incidente mina la fiducia, soprattutto quando emerge che il problema era evitabile. In questi casi, il danno non è solo tecnico, ma organizzativo.
Conclusione: smettere di arrivare tardi
Il threat modeling viene ignorato non perché sia inutile, ma perché è scomodo. Costringe a rallentare, a discutere, a mettere in discussione scelte già fatte. Ma è proprio questo il suo valore.
Trattarlo come una pratica viva significa accettare che la sicurezza non è mai “finita”. Significa smettere di inseguire gli incidenti e iniziare a prevenirli davvero.
Arrivare tardi è una scelta. E nel mondo della cyber security, è quasi sempre quella sbagliata.
Domande frequenti
- Cos’è il threat modeling in parole semplici?
È un processo per identificare in anticipo le minacce a un sistema e progettare contromisure efficaci. - Perché il threat modeling viene spesso ignorato?
Perché è percepito come rallentamento e viene visto come attività formale, non come pratica continua. - STRIDE è obbligatorio per fare threat modeling?
No, ma STRIDE è uno dei framework più efficaci e diffusi per strutturare l’analisi delle minacce. - Il threat modeling serve anche per piccoli progetti?
Sì, anzi è ancora più utile quando le risorse sono limitate e gli errori costano di più. - Quanto spesso va aggiornato un threat model?
Ogni volta che cambia l’architettura, i flussi di dati o le integrazioni principali. - Il cloud riduce la necessità di threat modeling?
No, il cloud aumenta la complessità e rende il threat modeling ancora più necessario. - Chi dovrebbe fare threat modeling?
Sviluppatori, architetti e sicurezza insieme. Non è un’attività da delegare a un solo team. - Il threat modeling previene tutti gli attacchi?
No, ma riduce drasticamente il numero di vulnerabilità prevedibili. - È necessario usare tool specifici?
I tool aiutano, ma il valore principale è nel ragionamento, non nello strumento. - Il threat modeling sostituisce i test di sicurezza?
No, li completa. Serve prima per prevenire, non dopo per scoprire.
