Ampiamente e sempre più diffuso nelle imprese, spesso troppo nascosto agli occhi dei team di cyber security, fonte (involontaria) di vulnerabilità. È il ritratto che Synopsys fa del codice open source nella nuova edizione - l'ottava - del suo Open Source Security and Risk Analysis Report. La cui morale è, in sostanza, che le imprese devono migliorare decisamente nella loro capacità di "vedere" il codice che usano.

I dati pubblicati da Synopsys derivano dalla sua attività di auditing del parco applicativo dei clienti. L'attività è in buona parte preventiva, in un'ottica di gestione del rischio: quando un'azienda si fonde con un'altra, magari per una acquisizione, gli audit di Synopsis evidenziano subito eventuali problemi di incompatibilità o di compliance.

Nel 2022 il Synopsys Cybersecurity Research Center ha condotto circa 1.700 audit di questo tipo, che le hanno permesso di realizzare il suo nuovo report. Gli audit riguardano tutta la cosiddetta "codebase", quindi sia il codice che realizza applicazioni e servizi usati, sia le librerie che questo codice richiede.

Nel valutare il report va tenuto presente che Synopsys è una grande sostenitrice dell'approccio SBOM. Le Software Bill Of Materials, che elencano dettagli e caratteristiche di tutti i componenti software di una applicazione, permettono secondo la società di tenere traccia di quello che si usa davvero in azienda tra codice commerciale, proprietario e soprattutto open source. E quindi di sapere sempre dove bisogna eventualmente intervenire quando si presentano nuove vulnerabilità e minacce.

Non tutti sono altrettanto d'accordo sull'efficacia delle SBOM. Ma è certo che i dati raccolti da Synopsys danno quantomeno una fotografia di come e quanto la gestione "zoppicante" del proprio parco software possa essere un problema lato cyber security.

Il successo open source

Synopsys si concentra sul codice open source perché ritiene sia quello meno controllabile da parte delle imprese che lo usano. Allo stesso tempo, l'open source è largamente e sempre più integrato con la dotazione software delle aziende stesse, anche se spesso queste non sanno di stare usando codice "libero" massicciamente.

In media, spiega invece Synopsys, il 96% delle codebase analizzate conteneva elementi open source. Sempre in media, ciascuna codebase conteneva 595 diversi componenti open source. Il problema è che in larga percentuale le codebase si sono rivelate... problematiche. L'84% conteneva almeno una vulnerabilità open source nota, il 48% una vulnerabilità ad alto rischio già sfruttata. L'89% integrava codice open source vecchio di almeno quattro anni, il 91% codice che non aveva avuto nuovi sviluppi negli ultimi due anni.

La questione non è nuova, lato sviluppo open source. A fronte di grandi progetti sostenuti e seguiti costantemente da molti sviluppatori indipendenti e da grandi software house, ci sono innumerevoli progetti meno importanti che si basano sulla buona volontà di poche persone. Non si possono dare per scontate la manutenzione regolare e la messa in sicurezza di tali progetti, anche se questi possono avere una larga platea di utilizzatori.

E non dovrebbe esserlo, oggi. Synopsys conferma che le aziende sono ormai abbastanza informate sul rischio che comportano i cosiddetti supply chain attack. Allo stesso tempo, però, non sembrano in grado di affrontare davvero il problema perché non hanno una concreta visibilità sulla propria supply chain software. Non sanno cioè davvero quale software usano, da dove viene, in che stato si trova. E per questo non riescono nemmeno a manutenerlo.

Synopsys nel 2022 ha eseguito 1.481 audit "approfonditi", ossia con una analisi dettagliata di risk assessment, di altrettante codebase. Il 91% conteneva almeno una versione non aggiornata di componenti open source. Una versione, cioè, che poteva essere aggiornata o "patchata" ma non lo era stata. Ci possono essere diversi motivi per non applicare update o patch, ma secondo Synopsys una percentuale così elevata di mancanze deve derivare anche dalla poca visibilità che i team DevSecOps hanno sul proprio parco software e sugli aggiornamenti disponibili.

Il testimone migliore di questa lacuna è anche tra i più pericolosi: nonostante il gran parlare che si è fatto in merito a Log4Shell, il 5% delle codebase esaminate da Synopsys conteneva una versione vulnerabile di Log4J. "Ci aspettiamo di vedere vulnerabilità come Log4J nelle componenti di base delle aziende ancora per degli anni", spiega poi senza grande ottimismo Synopsys. A meno che le aziende non cambino il loro approccio alla gestione dei software che usano.