I livelli di debito di sicurezza delle organizzazioni che operano nella regione EMEA crescono a livelli preoccupanti e in un mondo in cui ogni interazione con un’applicazione può essere un potenziale punto di ingresso per i cyber criminali, comprenderlo e gestirlo è più cruciale che mai.
È quanto evidenziato dal report State of Software Security (SoSS) 2024 di Veracode, società leader mondiale nella gestione del rischio applicativo.
È doveroso precisare che il debito di sicurezza consiste nell’insieme dei difetti software che rimangono irrisolti per più di un anno e che può accumularsi ulteriormente se gli sviluppatori non hanno tempo o risorse per risolvere difetti potenzialmente pericolosi.
Vediamo di seguito più in dettaglio i dati principali scaturiti dal report.
Indice degli argomenti
La criticità dei difetti di sicurezza del software
Esistono due metriche principali per valutare se i difetti di sicurezza di un software rappresentano un rischio critico per la sicurezza:
Scopri i trend AI del 2025: Scarica il report degli Osservatori del Politecnico di Milano
- La gravità è il potenziale impatto del difetto sulla riservatezza, l’integrità e la disponibilità.
- La sfruttabilità è la probabilità o la facilità con cui un utente malintenzionato potrebbe sfruttare un difetto.
Nel complesso, dal report si evince che circa il 3% di tutti i difetti di sicurezza di un software è considerato di gravità molto elevata e il 16% ha molte probabilità di essere sfruttato dai cyber criminali. Mentre, meno dell’1% di tutti i difetti ottiene valutazioni più alte (per entrambe le metriche di criticità).
Fonte immagine: Report VERACODE, “State of Software Security (SoSS) 2024 per l’area EMEA”.
Tipi di difetti più comuni
Oltre alle classificazioni in termini di gravità e di sfruttabilità, l’identificazione dei tipi di difetti presenti nel codice fornisce informazioni utili per la creazione di modelli di minaccia, la valutazione del rischio e la definizione delle priorità per la correzione.
Esistono diversi approcci per classificare i difetti del software. Tuttavia, la CWE e l’OWASP Top 10 sono due dei più popolari.
Fonte immagine: Report VERACODE – “State of Software Security (SoSS) 2024 per l’area EMEA”.
La supply chain del software e difetti in componenti di terze parti
La prevalenza di difetti relativi a componenti di terze parti vulnerabili richiede uno sguardo più approfondito alla sicurezza della catena di fornitura del software.
È doveroso ricordare che i difetti possono essere introdotti nel codice scritto dal team (di prima parte) o tramite software open source o altre librerie di terze parti importate nelle applicazioni.
Il rapporto rivela che circa il 63% delle applicazioni presenta difetti nel codice di prime parti e il 70% contiene difetti nel codice di terze parti. Ciò significa che molte app presentano difetti sia nel codice di prime parti sia in quello di terze parti, motivo per cui includere le scansioni di entrambe le fonti in vari punti del ciclo di vita dello sviluppo sicuro del software è fondamentale.
I tempi di correzione dei difetti nei software
Circa un terzo o un quarto di tutti i difetti, come si evince dal report, vengono corretti nei primi tre mesi.
Normalmente, i difetti in tutte le applicazioni sono risolti mediamente in circa nove mesi. Secondo il grafico sottostante, il 41% dei difetti di prima parte e il 48% di quelli di terze parti persistono oltre la soglia di un anno per diventare “debito di sicurezza”.
La tempistica per risolvere i difetti di terze parti è più lunga: 11 mesi rispetto ai 7 mesi dei difetti di prima parte.
Fonte immagine: Report VERACODE – “State of Software Security (SoSS) 2024 per l’area EMEA”.
Il 42% delle applicazioni attive (quelle che sono state analizzate per almeno un anno) presenta difetti che costituiscono un debito di sicurezza.
Fonte immagine: Report VERACODE – “State of Software Security (SoSS) 2024 per l’area EMEA”.
Interessante notare che, se non si considerano le applicazioni che hanno meno di un anno, il grafico a nido d’ape mostrato sotto riportato evidenzia che c’è una percentuale maggiore di app che non hanno debiti (perché sono troppo giovani per aver iniziato ad accumularli) e, conseguentemente, il rapporto di indebitamento scende dal 42% al 23%.
Fonte immagine: Report VERACODE – “State of Software Security (SoSS) 2024 per l’area EMEA”.
La prevalenza del debito di sicurezza
Dal report di Veracode si evince che, per quanto riguarda l’area EMEA, il 68% delle organizzazioni presenta un certo livello di debito di sicurezza nelle proprie applicazioni.
Ancora più preoccupante risulta che il 46% delle entità EMEA presenta difetti persistenti di elevata gravità che viene classificato come debito di sicurezza critico.
È doveroso sottolineare che tali difetti rappresentano il rischio più elevato per le applicazioni e quindi necessitano una correzione prioritaria.
Fattori che contribuiscono al debito di sicurezza
Di seguito, una panoramica dei fattori che influiscono sul debito di sicurezza
Età dell’applicazione
È doveroso sottolineare che il debito di sicurezza ha una componente temporale ed il grafico seguente suggerisce che esiste effettivamente un fattore di età che determina il debito. Inoltre, i difetti non corretti diventano debiti di sicurezza dopo un anno.
Pertanto, ne consegue che, a quel punto del ciclo di vita di un’applicazione, circa 42% di tutti i difetti si trasforma in debito di sicurezza. L’indebitamento cresce a circa 62% a tre anni e sale ulteriormente al 75% dopo cinque anni.
Fonte immagine: Report VERACODE – “State of Software Security (SoSS) 2024 per l’area EMEA”.
Dimensioni dell’applicazione
Il codebase della maggior parte delle applicazioni cresce nel tempo; quindi, è logico che possa esistere una correlazione tra l’età e l’accumulo di difetti meno recenti e che non sono stati risolti.
Le applicazioni di grandi dimensioni hanno la più alta percentuale di debito di sicurezza (40%) e di debito critico (47%). Le applicazioni di medie dimensioni scendono un po’ al di sotto di questa soglia e il livello di debito di sicurezza tra le applicazioni di piccole dimensioni è ancora più basso in entrambi i grafici.
Fonte immagine: Report VERACODE – “State of Software Security (SoSS) 2024 per l’area EMEA”.
Linguaggio di sviluppo dell’applicazione
Linguaggi di sviluppo diversi hanno posture di sicurezza, ambienti e controlli intrinsecamente diversi. Ne consegue che gli sviluppatori possono confrontare le prestazioni dei loro linguaggi e ottenere una visione delle aree su cui concentrarsi.
Dal report si evince che i linguaggi più importanti in termini di applicazioni totali, i.e. Java, .NET, JavaScript, si collocano per lo più a metà classifica per il debito di sicurezza e il debito critico. I residui di basi di codice legacy, come VB6 e Perl, mostrano il più alto tasso di indebitamento, mentre le app iOS e Android mostrano bassi livelli di debito critico.
Fonte immagine: Report VERACODE – “State of Software Security (SoSS) 2024 per l’area EMEA”.
Principali tipi di difetti
Si è tentati di pensare che tutti i debiti di sicurezza siano il risultato di una svista, di decisioni sbagliate, di una mancata esecuzione e via dicendo. Ma non è sempre così. Di fatto, spesso, gli sviluppatori prendono decisioni consapevoli per correggere alcuni difetti mentre in altri casi non intervengono.
La figura sotto riportata elenca le categorie CWE di difetti di prime parti che sono state analizzate nel report e da cui si evince che i difetti in cima alla lista tendono ad essere affrontati più velocemente perché sono percepiti come più rischiosi o sono più facili da risolvere.
Fonte immagine: Report VERACODE – “State of Software Security (SoSS) 2024 per l’area EMEA”.
La figura sotto riportata rivela, invece, molte nuove categorie CWE, nonché sostanziali cambiamenti nell’ordinamento tra le categorie esistenti per quanto riguarda le terze parti. Ad esempio, i problemi di gestione e autenticazione delle credenziali sono tra i meno propensi a diventare debito nel codice di prime parti, ma è vero il contrario per il codice di terze parti.
Inoltre, molte di queste differenze possono essere ricondotte al modo in cui questi difetti vengono risolti. Di fatto, lo sviluppatore imposta la priorità e corregge i difetti nel codice di prima parte, mentre il codice di terze parti viene, solitamente, in gran parte risolto aggiornando le librerie.
Fonte immagine: Report VERACODE – “State of Software Security (SoSS) 2024 per l’area EMEA”.
È doveroso sottolineare che i tipi di difetti di sicurezza differiscono da linguaggio a linguaggio di sviluppo.
Pertanto, è importante che gli sviluppatori siano consapevoli dei difetti più rilevanti per il loro linguaggio e di come essi vengono introdotti per eliminare la possibilità che si aggiungano al debito di sicurezza nel corso del tempo.
Fattori per settore e per dimensione delle organizzazioni
Il report fornisce altresì confronti della prevalenza del debito di sicurezza critico tra organizzazioni di diversi settori e dimensioni.
Le differenze non sono così cospicue, se si confrontano i settori nel loro complesso (massimo del 19% contro minimo del 12%). In generale, dal report risulta che le organizzazioni di medie e di grandi dimensioni abbiano più debiti di sicurezza rispetto alle aziende più piccole.
Ciò è, probabilmente, un riflesso della difficoltà inerente al mantenimento di una base di codice sempre più ampia man mano che l’organizzazione cresce.
Fonte immagine: Report VERACODE – “State of Software Security (SoSS) 2024 per l’area EMEA”.
Raccomandazioni per ridurre al minimo il debito di garanzia
Il rapporto offre cinque strategie per ridurre al minimo il debito di sicurezza.
Integrazione della sicurezza nel ciclo di vita dello sviluppo software
Invece di condurre test isolati – che si tratti di codice, processi o team – l’implementazione di una scansione continua utilizzando SAST, DAST e SCA in diverse fasi del ciclo di vita dello sviluppo, dalla progettazione alla distribuzione, rappresenta un approccio molto più efficace per ridurre il crescente debito di sicurezza. Il report evidenzia inoltre che, senza un’integrazione strutturata delle attività di scansione, è impossibile ottenere una visione completa e olistica dei rischi di sicurezza presenti nelle applicazioni.
Di seguito, il diagramma tratto dal report che illustra il processo di integrazione del security testing nel SDLC.
Fonte immagine: Report VERACODE – “State of Software Security (SoSS) 2024 per l’area EMEA”.
Garantire una correzione continua
Generalmente si tende a pensare che le organizzazioni che risolvono i difetti più rapidamente accumulino meno debito di sicurezza, e che un aumento della frequenza dei test porti a correzioni più veloci.
Tuttavia, ciò da solo non è sufficiente. Anche se scansioni più frequenti forniscono ai team di sviluppo una panoramica aggiornata dei difetti presenti nel codice, questa consapevolezza non garantisce automaticamente la loro risoluzione, e il debito di sicurezza continuerà ad aumentare nelle applicazioni.
In altre parole, affinché la scansione continua sia davvero efficace, deve essere accompagnata da un processo di correzione altrettanto continuo.
La figura sottostante mostra una misurazione della velocità di correzione per tutte le applicazioni attive, suddividendole in tre categorie: lenta, media e veloce. Dall’analisi emerge che meno del 50% delle applicazioni con una velocità di correzione elevata presenta un debito di sicurezza, e solo il 5% ha un debito critico. Al contrario, tra le applicazioni con una velocità di correzione lenta, oltre il 90% ha un debito di sicurezza, con circa un quarto di esse affette da debiti critici.
Ciò suggerisce che il terzo più lento in termini di correzione dei difetti accumula, in media, un debito di sicurezza quattro volte superiore rispetto a chi corregge più rapidamente. Inoltre, è interessante notare che il passaggio da una velocità di correzione lenta a una media non comporta una significativa riduzione del debito di sicurezza. Di conseguenza, è raccomandato ai team di sviluppo di puntare a un miglioramento costante nella rapidità delle correzioni.
Fonte immagine: Report VERACODE – “State of Software Security (SoSS) 2024 per l’area EMEA”.
Dare priorità alla correzione del debito di sicurezza critico
Gestire il debito di sicurezza come parte integrante della gestione del rischio consente di semplificare la priorità delle correzioni, concentrandosi principalmente sui rischi critici. Infatti, poiché il 60% delle vulnerabilità identificate nelle organizzazioni EMEA non è considerato debito di sicurezza o di gravità critica, gli sviluppatori possono concentrarsi più facilmente sulla risoluzione del 4% di falle che rappresentano i rischi più elevati. Successivamente, potranno affrontare i debiti di sicurezza meno critici o le vulnerabilità recenti, in base alla capacità e alla propensione al rischio dell’organizzazione.
In questo contesto, una strategia di prioritizzazione del debito di sicurezza può beneficiare dell’uso di strumenti di Application Security Posture Management (ASPM), che monitorano costantemente i rischi raccogliendo, analizzando e prioritizzando le problematiche di sicurezza lungo l’intero ciclo di sviluppo del software. Secondo il report, l’adozione di strumenti ASPM è in aumento, grazie alla loro capacità di offrire una visione completa e unificata dei rischi a livello di stack applicativo, facilitando così la gestione e la risoluzione delle vulnerabilità.
Fonte immagine: Report VERACODE – “State of Software Security (SoSS) 2024 per l’area EMEA”.
Sviluppare le competenze di sicurezza degli sviluppatori
Gli sviluppatori, per poter identificare strategie efficaci per risolvere il debito di sicurezza critico e stabilire le giuste priorità, devono innanzitutto comprendere cosa sia il debito di sicurezza e dove si annidi.
Secondo alcune altre indagini condotte da Veracode, oltre il 50% delle organizzazioni dovrebbe fornire ai propri sviluppatori una formazione formale sulla sicurezza più di una volta all’anno. Tuttavia, quasi il 70% degli sviluppatori segnala che i propri datori di lavoro non offrono una formazione adeguata in materia di sicurezza. di fatto, questo gap formativo genera attriti tra i team di sviluppo e quelli di sicurezza, ostacolando una protezione efficiente delle applicazioni.
Il report evidenzia, altresì, che alcune organizzazioni utilizzano “Security Labs” progettati per promuovere pratiche di codifica sicura in tutta l’azienda. Tali laboratori impiegano applicazioni e API reali e containerizzate che permettono agli sviluppatori di individuare, correggere ed esplorare difetti di sicurezza, oltre a comprendere l’impatto che tali difetti hanno sulle applicazioni. La figura sottostante dimostra che le organizzazioni che fanno uso di Security Labs riescono a correggere i difetti più rapidamente e tendono a ridurre l’accumulo di debito di sicurezza.
Secondo i dati riportati dal report risulta che solo il 37% delle organizzazioni che utilizzano Security Labs accumula debito di sicurezza, rispetto al 48% di quelle che non ne fanno uso. Inoltre, emerge una differenza significativa nei tempi di risoluzione dei problemi: i team che non utilizzano i laboratori impiegano in media sette mesi in più per ridurre il debito di sicurezza alla soglia del 37%.
Fonte immagine: Report VERACODE – “State of Software Security (SoSS) 2024 per l’area EMEA”.
Conoscere il profilo del debito di sicurezza del linguaggio di programmazione
Le applicazioni sviluppate in linguaggi diversi richiedono strategie personalizzate per affrontare e ridurre il debito di sicurezza, poiché ogni linguaggio ha specifici punti di forza e debolezza in termini di vulnerabilità. Per questo motivo, è cruciale comprendere le caratteristiche dei linguaggi di sviluppo utilizzati all’interno dell’organizzazione.
Si consiglia di sviluppare una strategia che tenga conto delle peculiarità e delle vulnerabilità comuni associate ai linguaggi adottati, al fine di ottimizzare l’efficacia delle correzioni e ridurre il debito di sicurezza complessivo. Ad esempio, un approccio che funziona bene per applicazioni scritte in Java potrebbe non essere altrettanto efficace per quelle sviluppate in JavaScript o Python. Pertanto, adeguare le strategie in base alle caratteristiche del linguaggio permette di affrontare più rapidamente i difetti specifici e migliorare la sicurezza a lungo termine.
Garantire la supply chain del software
Quando il codice di terze parti viene introdotto in un progetto, le organizzazioni si trovano a dover gestire una base di codice che include contributi provenienti da sviluppatori esterni, infrastrutture e pipeline di sviluppo al di fuori del loro controllo diretto.
A questo si aggiunge la complessità dell’albero delle dipendenze, che può espandersi rapidamente, creando ulteriori rischi di sicurezza.
Vediamo cosa necessario fare.
Comprendere le dipendenze open source
Le applicazioni sviluppate internamente possono includere decine, se non centinaia, di librerie esterne, sviluppate al di fuori dell’organizzazione. Queste dipendenze tendono a variare nel tempo. Il report sottolinea che le applicazioni JavaScript, che in passato contenevano quasi 500 librerie in media per applicazione, hanno visto una riduzione costante negli ultimi anni. Al contrario, linguaggi come Java, Ruby e Python stanno registrando una crescita delle dipendenze da codice di terze parti.
La figura sotto riportata mostra la proporzione di codice di un’applicazione costituita da codice di prima parte rispetto a quello di terze parti (misurato in byte). Alcuni linguaggi si basano principalmente su codice esterno, come Java (98%) e .NET (73%), mentre altri, come Go (3%) e C++ (12%), sono prevalentemente composti da codice proprietario. Linguaggi come JavaScript e Python presentano invece una distribuzione bimodale, con applicazioni che oscillano tra due estremi: alcune fortemente basate su codice di terze parti e altre principalmente proprietarie. Le applicazioni Ruby, d’altro canto, mostrano una variazione significativa, con una combinazione di codice di prima e terza parte.
Di conseguenza, le organizzazioni dovrebbero avere una chiara comprensione delle librerie più utilizzate per ciascun linguaggio di sviluppo e sapere quale percentuale del codice delle loro applicazioni dipenda da singoli sviluppatori open source.
Fonte immagine: Report VERACODE – “State of Software Security (SoSS) 2024 per l’area EMEA”.
Valutazione della sicurezza delle librerie di terze parti
Risulta particolarmente complicato, a parità di funzionalità, discernere quanto sia sicura una libreria rispetto a un’altra senza testarle direttamente. Per risolvere questo empasse, l’Open Source Security Foundations (OpenSSF) ha sviluppato il progetto “Scorecards” per scansionare i repository open source e identificare problemi di sicurezza potenziali ed effettivi.
Il progetto Scorecards fornisce controlli che possono essere utili agli sviluppatori quando esaminano i propri repository o ne valutano altri, dato che forniscono altresì un ricco set di controlli per ottenere informazioni più approfondite sulla sicurezza della catena di fornitura del software.
Come evidenziato dal rapporto sull’utilizzo delle “scorecard” dell’Open Source Security Foundation (OpenSSF), emergono alcune tendenze chiave:
- Le librerie con più collaboratori tendono ad avere punteggi di sicurezza più elevati.
- Le librerie aggiornate frequentemente presentano punteggi di sicurezza migliori.
- Una maggiore diversità tra i committer è un indicatore positivo di punteggi di sicurezza più alti.
- Lunghi intervalli tra i commit rappresentano un potenziale segnale di allarme per la sicurezza.
Pertanto, se si deve valutare una libreria che non è stata analizzata da OpenSSF e non può essere scansionata direttamente, l’esaminare l’attività dei commit può fornire indicazioni utili sulla sua sicurezza.
Conclusione
La gestione della supply chain del software richiede un approccio diverso rispetto alla gestione del codice interno.
Si consiglia di selezionare librerie open source sviluppate attivamente da una comunità diversificata di contributori, poiché è più probabile che tali librerie dispongano di controlli di sicurezza solidi nel loro repository.
Ciò consente agli sviluppatori interni di risolvere più rapidamente eventuali difetti presenti in queste librerie.
Proof of Concept: una guida pratica per eseguirlo con successo in 6 step
