Gestione dipendenze software e open source analysis DORA

La crescente complessità delle infrastrutture informatiche nel settore finanziario impone una valutazione approfondita delle dipendenze software. Con il Digital Operational Resilience Act (DORA), la gestione delle librerie di terze parti e l’open source analysis diventano elementi centrali nel garantire la resilienza operativa e la sicurezza degli asset digitali, come previsto dall’Articolo 25 del regolamento.

Open source analysis prevista da DORA

DORA stabilisce che le analisi di software open source siano incluse nel programma di test della resilienza operativa digitale. L’obiettivo è gestire i rischi legati alla catena di approvvigionamento del software: una vulnerabilità in una libreria condivisa può compromettere l’intera infrastruttura di una entità finanziaria. Secondo i requisiti normativi, l’open source analysis permette di identificare preventivamente le falle di sicurezza nei componenti di terze parti per mantenere controllo sui rischi operativi.

Dipendenze software e Regolamento Delegato (UE) 2024/1773

Il Regolamento Delegato (UE) 2024/1773 impone alle entità finanziarie di analizzare il codice sorgente e il software proprietario proveniente da terzi o da progetti open source prima della messa in produzione, ricercando vulnerabilità e codice malevolo. Sono richiesti test statici e dinamici, la rilevazione di anomalie e l’adozione di piani di remediation.

Inventory delle dipendenze e monitoraggio delle vulnerabilità CVE

Una gestione efficace delle dipendenze richiede il tracciamento sistematico delle librerie di terze parti, monitoraggio delle versioni, aggiornamenti tempestivi e la registrazione puntuale di ogni vulnerabilità che impatti i sistemi ICT. Le procedure devono prevedere:

• Monitoraggio e tracciamento costante delle librerie, incluse le open source, con relativa gestione degli aggiornamenti.
• Registrazione di ciascuna vulnerabilità rilevata.
• Prioritizzazione della distribuzione delle patch rispetto alla criticità della vulnerabilità e al profilo di rischio degli asset interessati.
• Per asset critici o rilevanti, il monitoraggio deve essere stringente; per asset off-the-shelf non critici, il tracciamento va comunque garantito ove possibile.

SBOM: stato dell’arte per la conformità

Anche se DORA e gli RTS non menzionano esplicitamente la SBOM (Software Bill of Materials), la necessità di tracciare librerie e versioni rende la SBOM lo standard tecnico più efficace e utilizzato per assicurare la conformità. Una SBOM funziona da inventario completo dei componenti software, agevolando il monitoraggio proattivo e la risposta tempestiva a nuove vulnerabilità pubbliche (CVE) che coinvolgano specifiche librerie impiegate dall’entità.

Integrazione nell’SDLC e nella gestione delle patch

L’open source analysis richiesta da DORA deve essere integrata nel ciclo di vita dello sviluppo software (SDLC). Le entità sono tenute a proteggere l’integrità del codice sorgente – sia interno che di terze parti – e a collegare queste attività con la gestione delle patch. Gli aggiornamenti software devono essere testati e implementati in ambienti di staging rappresentativi prima della distribuzione in produzione, per evitare interruzioni operative. Se una vulnerabilità open source non è coperta da patch, è obbligatorio individuare ed attivare altre misure di mitigazione.

FAQ

• DORA obbliga la SBOM? La normativa richiede di tracciare l’uso di librerie di terze parti e open source, monitorandone versioni e aggiornamenti. Sebbene non usi il termine “SBOM”, la creazione di una distinta base del software rappresenta la soluzione tecnica più efficace per rispettare questo requisito.
• Come gestire librerie in applicazioni legacy? Le entità devono monitorare se gli asset ICT sono ancora supportati da vendor o sviluppatori. Per asset legacy o non più supportati, è indispensabile un piano di gestione dei rischi che ne mitighi l’obsolescenza.
• L’analisi open source sostituisce il pentest? No. L’analisi open source si concentra sulle dipendenze e sul codice e fa parte dei test ordinari di resilienza previsti dall’Articolo 25. Tali attività devono essere integrate con vulnerability assessment e penetration test per valutare la sicurezza complessiva dei sistemi.

Governa la tua supply chain software: richiedi una revisione del rischio software e delle dipendenze critiche per allineare il tuo sviluppo ai requisiti di sicurezza del DORA.