Open source: le dipendenze sono un problema (di sicurezza)

I dati raccolti da Veracode nello studio "State of Software Security 2025: A New View of Maturity" attraverso analisi statiche, DAST (Dynamic Application Security Testing) e studi sui componenti open source, sono il frutto dell'analisi di quasi mezzo milione di applicazioni e rivelano che ben l'80,3% di esse presenta almeno una vulnerabilità. Quasi la metà risulta invece affetta da problematiche di sicurezza relative alle dieci principali criticità OWASP (Open Web Application Security Project).

Il ruolo dei componenti di terze parti nella sicurezza delle applicazioni

Secondo la rilevazione, un aspetto particolarmente allarmante riguarda il ruolo dei componenti di terze parti. Il rapporto mostra infatti che il 70% delle applicazioni contiene vulnerabilità all'interno di librerie o componenti non sviluppati internamente, rispetto al 64% del codice scritto appositamente per un'applicazione. Le problematiche insite nei componenti esterni risultano, inoltre, più gravi.

In tre organizzazioni su dieci, oltre il 96% del debito di sicurezza ai livelli più critici è localizzato proprio in questo ambito. Le numerose dipendenze che caratterizzano queste librerie possono complicare notevolmente gli aggiornamenti, specialmente quando le nuove versioni introducono modifiche incompatibili o quando un progetto open source risulta meno attivo e meno aggiornato.

Le libreria open source hanno un problema di dipendenze

Il report sottolinea anche una questione non meno rilevante legata al codice open source. La quota di debito di sicurezza attribuibile ad esso è infatti relativamente bassa, i difetti che ne derivano tendono però a essere tra i più critici. Un ulteriore elemento di preoccupazione è il tempo necessario per risolvere tali problematiche: la "half-life" dei difetti presenti nel codice open source si attesta sui 12 mesi, contro gli 8 mesi medi registrati per il codice sviluppato internamente.

I motivi di questa disparità risiedono soprattutto in fattori strutturali. Le librerie di terze parti, infatti, possono avere più dipendenze che rendono difficile la loro sostituzione o l'aggiornamento senza rischiare di compromettere il funzionamento di un'applicazione. Inoltre, il processo di valutazione del rischio reale non si limita ad una semplice analisi statica. Molte vulnerabilità, pur essendo classificate ad alto rischio, potrebbero non rappresentare una minaccia concreta se le funzionalità interessate non vengono mai utilizzate o se esistono altre misure di sicurezza che ne bloccano eventuali exploit.