Guida · Cybersecurity · DORA

Sicurezza delle applicazioni ai sensi di DORA: SAST, DAST, SBOM e ciclo di vita sicuro nel settore bancario e assicurativo

DORA (regolamento (UE) 2022/2554) si applica dal 17 gennaio 2025 e trasforma la sicurezza del software in un obbligo soggetto a vigilanza: le entità finanziarie devono identificare e proteggere i sistemi TIC che supportano le loro funzioni essenziali o importanti, individuarne le anomalie e sottoporli a test, e dimostrarlo con evidenze. Questa guida traduce tali obblighi in pratiche concrete di sicurezza delle applicazioni (SAST, DAST, SBOM, gestione dei segreti, test di resilienza) e spiega come le integriamo nel ciclo di vita del software di banche e compagnie assicurative.

Non è una consulenza legale: è una guida operativa per CISO, CTO, responsabili dello sviluppo e della compliance. Riferimenti normativi verificati il 15 settembre 2026; gli obblighi concreti dipendono dal tipo di entità e dalla criticità di ciascuna funzione.

Cosa richiede DORA al software e dove lo dice

DORA non nomina strumenti né metodologie: fissa risultati. Il suo quadro per la gestione dei rischi informatici (articoli da 5 a 16) obbliga a inventariare le risorse, proteggerle, individuare le anomalie e ripristinare l'operatività; il capo sugli incidenti (articoli da 17 a 23) impone di classificare e segnalare; quello sui test di resilienza operativa digitale (articoli da 24 a 27) richiede un programma di test annuale; e quello sui terzi (articoli da 28 a 30) estende tutto quanto precede al software e ai servizi che l'entità acquista.

Il regolamento delegato (UE) 2024/1774, che integra il quadro per la gestione dei rischi informatici, scende nel dettaglio che interessa a un team di sviluppo: la politica dei progetti TIC deve coprire l'acquisizione, lo sviluppo e la manutenzione dei sistemi; tutti i requisiti, compresi quelli di sicurezza, devono essere testati prima di approvare il passaggio in produzione; e i risultati dei test di sicurezza devono essere tracciati e tradotti in misure aggiornate senza indebito ritardo quando il sistema supporta una funzione essenziale o importante.

Articolo 8 — identificazione: inventario delle risorse TIC, delle dipendenze e delle funzioni che supportano, mantenuto aggiornato.
Articolo 9 — protezione e prevenzione: politiche di sicurezza, gestione delle patch e degli aggiornamenti, segmentazione e controllo degli accessi.
Articolo 10 — individuazione: meccanismi di individuazione delle anomalie con soglie di allerta e monitoraggio continuo.
Articolo 11 — risposta e ripristino: piani di continuità operativa delle TIC e di ripristino sottoposti a test.
Articoli 24 e 25 — test: programma annuale che comprende, tra l'altro, valutazioni e scansioni delle vulnerabilità, analisi open source, esami del codice sorgente ove fattibile, test basati su scenari, test end-to-end e test di penetrazione.
Articolo 26 — TLPT: test di penetrazione guidati dalla minaccia (quadro TIBER-EU) almeno ogni tre anni per le entità designate dall'autorità.
Articoli da 28 a 30 — terzi: il software e i servizi TIC forniti da terzi rientrano nello stesso quadro, con clausole contrattuali minime e un registro degli accordi contrattuali.

Dalla norma alla pratica: nove controlli di sicurezza delle applicazioni

Sono i controlli che coprono gli obblighi precedenti in un ciclo di vita del software moderno. L'ordine conta: ciascuno genera l'evidenza di cui il successivo ha bisogno e che l'autorità di vigilanza chiederà.

1. Inventario e classificazione per funzione critica

Ogni applicazione, servizio e componente collegato alla funzione di business che supporta e alla relativa criticità. Senza questo non è possibile definire le priorità né giustificare il perimetro dei test (articolo 8).

2. Modellazione delle minacce in fase di progettazione

Prima di scrivere codice: quali asset gestisce l'applicazione, chi può attaccarla e da dove. È il controllo più economico e quello che evita più difetti; alimenta i requisiti di sicurezza che l'RTS impone di testare.

3. SAST a ogni modifica del codice

Analisi statica integrata nella pipeline, con quality gate che bloccano il passaggio in produzione in base alla severità. È il modo pratico di adempiere all'esame del codice sorgente che DORA richiede «ove fattibile» (articolo 25) e di lasciare traccia di ogni rilievo e della relativa correzione.

4. SCA e SBOM: la catena di fornitura del software

Inventario dei componenti di terze parti (SBOM) e analisi della composizione per conoscerne le vulnerabilità nel tempo. Copre il rischio di terzi degli articoli da 28 a 30 e la sicurezza della catena di fornitura richiesta anche da NIS2.

5. Gestione dei segreti e infrastructure as code

Nessun segreto nei repository né nelle immagini; credenziali ruotate e gestite centralmente; infrastruttura dichiarata come codice e analizzata come il software stesso (articolo 9).

6. DAST e test di penetrazione prima della produzione

Test dinamici sull'ambiente di pre-produzione a ogni versione rilevante e test di penetrazione pianificati all'interno del programma annuale (articoli 24 e 25). I rilievi entrano nello stesso flusso di correzione di quelli del SAST.

7. Gestione delle vulnerabilità con scadenze per criticità

Un unico registro delle vulnerabilità (codice, componenti, infrastruttura) con scadenze di correzione in base alla severità e alla criticità della funzione, ed evidenza del patching (articolo 9).

8. Logging, rilevamento e risposta

Log centralizzati, rilevamento continuo (SIEM/SOC) e playbook di risposta testati con esercitazioni (articoli 10 e 11). Gli incidenti gravi vengono classificati e segnalati all'autorità entro le scadenze delle norme tecniche di DORA: notifica iniziale nel giro di ore, poi relazione intermedia e relazione finale.

9. Test di resilienza e TLPT

Programma annuale documentato per tutti i sistemi essenziali o importanti (articolo 24) e, per le entità designate, test guidati dalla minaccia ogni tre anni (articolo 26), con i rilievi incorporati nel piano di remediation.

Sovrapposizioni utili: NIS2 e ISO/IEC 27001

Per le entità finanziarie DORA è la norma di settore e prevale su NIS2 (direttiva (UE) 2022/2555) negli ambiti che disciplina, ma conviene conoscerle entrambe: NIS2 si applica ad altre società del gruppo e a molti fornitori, e il suo articolo 21 elenca misure che coincidono punto per punto con i controlli precedenti: sicurezza nell'acquisizione, nello sviluppo e nella manutenzione dei sistemi, gestione e divulgazione delle vulnerabilità, sicurezza della catena di fornitura, crittografia, controllo degli accessi e autenticazione a più fattori.

ISO/IEC 27001:2022 è il modo più efficiente di organizzare le evidenze: i controlli dell'Allegato A su ciclo di vita di sviluppo sicuro, requisiti di sicurezza delle applicazioni, architettura sicura, codifica sicura, test di sicurezza in fase di sviluppo e accettazione, sviluppo esternalizzato e separazione degli ambienti (da 8.25 a 8.31) sono esattamente ciò che un ispettore DORA vuole vedere documentato. Vermont Solutions opera con certificazione ISO/IEC 27001:2022.

Checklist in dodici punti per il CISO e il CTO

Inventario delle applicazioni collegato alle funzioni essenziali o importanti, riesaminato almeno una volta all'anno.
Requisiti di sicurezza definiti per applicazione e testati prima di ogni passaggio in produzione.
SAST con quality gate nella pipeline ed evidenza di correzione per ogni rilievo.
SBOM generato a ogni build e analisi della composizione con avvisi per le nuove vulnerabilità.
Gestione centralizzata dei segreti e scansione dell'infrastructure as code.
DAST in pre-produzione e test di penetrazione annuale documentati all'interno del programma di test.
Registro unico delle vulnerabilità con scadenze di correzione per severità e criticità.
Log centralizzati, rilevamento continuo e playbook di risposta testati con esercitazioni.
Procedura di classificazione e segnalazione degli incidenti gravi con scadenze e responsabili.
Clausole di sicurezza, audit e uscita nei contratti di software e servizi TIC.
Programma annuale di test di resilienza approvato dalla direzione e, se del caso, TLPT pianificato.
Evidenze di tutto quanto precede generate dal processo stesso, non raccolte a mano prima dell'ispezione.

Come lo facciamo in Vermont Solutions

Integriamo i controlli nella pipeline di delivery dell'entità, non in un progetto a parte: SAST, analisi della composizione e SBOM a ogni build, DAST in pre-produzione, gestione dei segreti e analisi dell'infrastructure as code, con quality gate che lasciano evidenze automatiche. Progettiamo modelli di identità a privilegio minimo (IAM/PAM, Zero Trust) e implementiamo visibilità e rilevamento continui (SIEM/SOC) con processi di risposta allineati alla continuità operativa.

Lavoriamo su piattaforme critiche di banche e assicurazioni che non possono fermarsi (core legacy, grid di calcolo, Kubernetes ibrido) e con certificazione ISO/IEC 27001:2022. In una compagnia assicurativa europea, il rafforzamento degli accessi (MFA sui ruoli critici e dismissione dei protocolli legacy) ha aumentato il punteggio di sicurezza di Microsoft 365 del 30 % rispetto a una base dell'11,48 %, senza attriti per gli utenti.

Domande frequenti

DORA obbliga a fare SAST e DAST?

Non nomina strumenti. Impone di testare i requisiti di sicurezza prima della produzione, di esaminare il codice sorgente ove fattibile e di eseguire test di penetrazione all'interno di un programma annuale. SAST e DAST sono il modo pratico e tracciabile di adempiervi.

Ogni quanto vanno eseguiti i test di sicurezza?

Il programma di test di resilienza operativa digitale è annuale per i sistemi che supportano funzioni essenziali o importanti (articolo 24), e comprende al suo interno valutazioni delle vulnerabilità e test di penetrazione. Le entità designate dalla propria autorità eseguono inoltre test di penetrazione guidati dalla minaccia (TLPT) almeno ogni tre anni (articolo 26).

Cosa succede con il software che acquistiamo da terzi?

Rientra nello stesso quadro: gli articoli da 28 a 30 impongono due diligence, clausole contrattuali minime (sicurezza, audit, incidenti, uscita) e un registro degli accordi contrattuali. In pratica si copre con SBOM, analisi della composizione e clausole di sicurezza nei contratti.

NIS2 si applica anche a una banca o a una compagnia assicurativa?

Per le entità finanziarie DORA è la norma di settore e prevale negli ambiti che disciplina. NIS2 resta rilevante per altre società del gruppo e per molti fornitori, e le misure del suo articolo 21 coincidono con i controlli di questa guida.

Quali sono le scadenze per segnalare un incidente grave?

Le norme tecniche di DORA fissano una notifica iniziale entro poche ore dalla classificazione dell'incidente come grave, una relazione intermedia entro pochi giorni e una relazione finale a circa un mese. Le scadenze esatte dipendono dalla norma tecnica in vigore e dall'autorità competente; la procedura interna deve fissarle con nomi e ore.

Assessment di sicurezza delle applicazioni ai sensi di DORA

Esaminiamo il Suo inventario delle applicazioni critiche, la pipeline di delivery e le evidenze disponibili, e Le consegniamo il piano dei controlli con responsabili e scadenze. Senza modificare nulla in produzione finché il piano non è approvato.

Richiedere un assessment →

Contenuti correlati

Ultimo aggiornamento: 2026-09-15. Contenuto editoriale di Vermont Solutions, citabile con attribuzione e link a questa pagina. Non costituisce consulenza legale.