Source Code Review DORA per Secure SDLC e Testing Applicativo

Il Digital Operational Resilience Act richiede alle entità finanziarie di integrare pratiche di source code review DORA all’interno di un secure SDLC DORA per mitigare i rischi legati alle vulnerabilità applicative e al codice malevolo.

Significato di “where feasible”

L’Articolo 25 del DORA stabilisce che i programmi di test software devono includere revisioni del codice sorgente “ove fattibile”. Questo vincolo si applica quando il codice sorgente è effettivamente disponibile per l’entità finanziaria. Di conseguenza, la code review è obbligatoria per il software sviluppato internamente e per sviluppi custom realizzati da terzi su misura, mentre può essere esclusa per i pacchetti “off-the-shelf” quando il codice non viene fornito.

Code review, SAST, DAST e manual review

Le entità finanziarie devono adottare un approccio rigoroso al test software DORA in linea con il Regolamento Delegato (UE) 2024/1774:

• Static Application Security Testing (SAST): Analisi statica del codice sorgente per rilevare vulnerabilità logiche e di sicurezza senza esecuzione del programma.
• Dynamic Application Security Testing (DAST): Test dinamici svolti con il software in funzione per individuare falle che emergono durante l’esecuzione.
• Security Testing per sistemi esposti: Verifiche approfondite di sicurezza sono richieste per applicazioni e sistemi accessibili da Internet prima dell’entrata in produzione.

Applicazioni custom e funzioni critiche

Il livello e l’intensità dei test devono essere correlati alla criticità delle funzioni aziendali supportate dagli asset ICT. Per applicazioni che sostengono funzioni critiche o importanti, DORA prevede:

• Verifica attraverso il testing che i nuovi sistemi siano adeguati a operare come previsto.
• Analisi della qualità del software sviluppato internamente per prevenire errori che possano causare interruzioni operative.
• Implementazione di controlli per salvaguardare l’integrità del codice sorgente, prevenendo manipolazioni non autorizzate durante sviluppo e distribuzione.

Integrazione nel ciclo di sviluppo (Secure SDLC)

• Segregazione degli ambienti: Gli ambienti di sviluppo e di test devono essere separati rigorosamente dall’ambiente di produzione.
• Gestione dei dati di test: È vietato l’uso di dati reali negli ambienti non di produzione, salvo che siano anonimizzati, pseudonimizzati o randomizzati, con tutela di integrità e riservatezza.
• Governance dei progetti: I progetti ICT che impattano funzioni critiche devono essere riportati regolarmente all’organo di gestione.

Evidenze per audit e gestione remediation

• Identificazione delle anomalie: Ogni vulnerabilità o anomalia rilevata deve essere analizzata.
• Action plan: È obbligatorio predisporre un piano d’azione per correggere le carenze, definendo responsabilità e tempistiche.
• Monitoraggio: L’implementazione delle misure correttive va costantemente monitorata per assicurare che il rischio residuo rimanga entro i limiti previsti.

FAQ

• Il code review è obbligatorio? Sì, è necessario per tutto il software sviluppato internamente o custom. Per il software di terze parti, è obbligatorio “ove fattibile”, cioè quando il fornitore mette a disposizione il codice sorgente.
• SAST basta? No. È richiesto che le revisioni del codice comprendano sia SAST che DAST per una valutazione di sicurezza applicativa completa.
• Come definire le priorità? Le priorità devono seguire un approccio basato sul rischio, con precedenza ai sistemi che supportano funzioni critiche o importanti e a quelli esposti su reti esterne o Internet.

Costruisci software resiliente: richiedi una valutazione del tuo secure SDLC e del tuo programma di testing applicativo per allineare i tuoi processi di sviluppo ai requisiti tecnici del DORA.