Il paradosso dell'open source fra rischi, equità e accettazione

L'open source è sempre stato un paradosso, perché per quanto sia software sviluppato da sviluppatori appassionati e distribuito gratuitamente, viene monetizzato e finanziato da alcune delle più grandi aziende del mondo. Era penalizzato in partenza e qualcuno lo ha definito addirittura come "un cancro". Eppure si è dimostrato essere il più grande motore per l'innovazione e il progresso tecnologico. Nel mondo dell'open source ci saranno sempre paradossi, ma quello più grande è senz'altro quello relativo alle vulnerabilità della sicurezza.

Venticinque anni fa fu istituito il programma Common Vulnerabilities and Exposures (CVE) per standardizzare la denominazione e tenere traccia delle vulnerabilità ed esposizioni software comuni. In un periodo in cui era difficile identificare una vulnerabilità specifica, con tanti problemi in software diffusi come Sendmail, l'elenco CVE di MITRE si è distinto perché capace di organizzare i dati e fare chiarezza, perché, sebbene esistessero già progetti come Security Focus e Bugtraq, forniva il sistema di riconoscimento globale che mancava. Nell'anno in cui fu creato, il 1999, sono state catalogate appena 894 vulnerabilità, dimostrando così quanto fosse necessario identificarle in modo coerente, anche se in un volume relativamente ridotto. Il contesto storico di partenza è fondamentale per comprendere le sfide che CVE deve affrontare oggi.

Nel corso del tempo, il panorama delle vulnerabilità software è cambiato radicalmente. Nei primi sei anni di vita del programma, il numero di vulnerabilità identificate da CVE è aumentato di oltre il 450%, data la più ampia adozione del sistema. Questa crescita è continuata in modo esponenziale, raggiungendo quasi 15.000 vulnerabilità individuate prima del 2017, che hanno segnato un aumento del 125% in soli due anni, mentre nel 2023 il volume è salito di un ulteriore 50%, superando le 29.000 unità. Questa crescita esplosiva sottolinea la crescente complessità delle soluzioni software, la loro maggiore disponibilità e una crescente adozione di CVE da parte dei fornitori.

Il numero di vulnerabilità continua a crescere. Nel 2024 l'elenco CVE si è ampliato di un ulteriore 39%, raggiungendo le 40.000 vulnerabilità, in parte per via dello stato dell'autorità di numerazione CVE (CNA, CVE Numbering Authority) del kernel Linux. Questa parabola ascendente potrebbe subire un'altra accelerazione significativa se altri settori IT, come quelli dello sviluppo di giochi e applicazioni per dispositivi mobili, iniziassero a includere formalmente le proprie vulnerabilità in CVE. Perché è questo volume assoluto che dobbiamo tenere presente per impostare una strategia di gestione delle vulnerabilità adeguata.

Non basta "metterci una patch"

Sosteniamo da tempo che il mantra "mettici una patch", per quanto forse gestibile in tempi più semplici, negli ambienti complessi di oggi è insostenibile e strategicamente inconsistente, perché non si fonda su una valutazione del rischio corretta. Non tutte le vulnerabilità infatti richiedono correzioni immediate e dispendiose in termini di risorse, mentre è fondamentale tenere presente sfruttamento e potenziale impatto. Applicare le stesse soluzioni, qualunque sia la criticità identificata, è come raccomandare un intervento chirurgico aggressivo sia per neoplasie benigne che maligne: non tiene conto dell'effettiva gravità della minaccia, né del rischio insito nel trattamento stesso.

Per stabilire le priorità è dunque fondamentale tenere conto dello sfruttamento effettivo. L'analisi dei dati, che attinge da fonti come il catalogo KEV (Known Exploited Vulnerabilities) dell'Agenzia per la sicurezza informatica e delle infrastrutture (CISA) mostra in modo coerente che i tassi di sfruttamento nel corso del tempo rimangono notevolmente bassi, ben inferiori allo 0,5% annuo, come dire che circa 1 vulnerabilità su 200 viene effettivamente sfruttata. Tenendo presenti questi dati, dovremmo concentrarci su approcci più pragmatici e basati sul rischio effettivo.

Il nostro obiettivo è quello di individuare le vulnerabilità che hanno più probabilità di essere sfruttate e che possono anche causare danni significativi, come quelle che consentono l'accesso remoto e non autenticato con escalation dei privilegi elevati, che chiameremmo critiche o importanti. Concentrando le attività di correzione sulle vulnerabilità ad alto rischio e ad alto impatto, sfruttiamo al meglio le risorse disponibili per ridurre i rischi. Questo inevitabilmente significa anche accettare in modo strategico il rischio residuo inferiore, rappresentato dalle vulnerabilità che difficilmente verranno sfruttate o che avranno comunque un impatto, ma di livello basso e moderato. 

Gestire il rischio in modo efficace non significa eliminare tutte le vulnerabilità, quanto piuttosto dare la priorità a quelle che rappresentano una minaccia reale e probabile e di accettare consapevolmente altri rischi gestibili.

E tutto questo che c'entra con l'open source?

Le preoccupazioni relative alle vulnerabilità prive di patch spesso si concentrano sull'open source, principalmente perché è un sistema totalmente trasparente, in cui codice e CVE sono di pubblico dominio. I fornitori proprietari, al contrario, spesso non segnalano le falle a basso impatto che non ritengono necessario correggere, risultando così poco chiari sui rischi effettivi. Una piccola falla in un prodotto open source che viene pubblicata nell'elenco CVE potrebbe non essere segnalata, non essere corretta o introdotta priva di patch, a insaputa dell'utente, nel software proprietario.

È questa diversa visibilità che crea un doppio standard. Le policy dell'open source che richiedono l'assenza di vulnerabilità note puntano intrinsecamente alla trasparenza, non necessariamente alla presenza di un rischio più elevato. È fondamentale quindi che la tua organizzazione accetti implicitamente la possibilità che i software proprietari che utilizzi ogni giorno contengano vulnerabilità non segnalate, per gestire i rischi in modo corretto. I rischi devono essere valutati in modo coerente ed esplicito per tutti i software, concentrandosi sulla probabilità di sfruttamento e sull'impatto di ciascuno, piuttosto che penalizzare la visibilità intrinseca dell'open source.

Per gestire le vulnerabilità in modo equo è necessario riconoscere l'unicità dell'open source, che è trasparente per definizione (e questo è un bene!) e che sembra contenere più rischi. L'open source semplicemente esplicita il rischio implicito del software proprietario.

Ci sono dei dati interessanti che lo confermano. Il confronto tra Red Hat e i dati del Risk Report 2024 relativi a un noto fornitore di software proprietario ci fornisce alcuni spunti molto interessanti che confermano la nostra ipotesi. Se il fornitore proprietario segnalasse solo bug di grande impatto (ossia facilmente sfruttabili), ci si aspetterebbe un numero simile di problemi critici, importanti, moderati e bassi. In altre parole, a meno che i bug di sicurezza non siano sempre importanti, malevoli e dannosi, ci si aspetterebbe di vedere un numero maggiore di vulnerabilità meno impattanti. Ma i problemi di scarsa gravità segnalati sono pochi. Per inciso, questo fornitore utilizza la stessa scala di gravità a quattro punteggi impiegata da Red Hat.

Contare le vulnerabilità potrebbe dunque fornire un quadro ingannevole: il maggior numero di problemi con gravità inferiore riportati nell'elenco CVE e segnalati in modo trasparente nei progetti open source (nel 2024 le vulnerabilità con rischio moderato e basso di Red Hat sono state il 92%), rispetto a quelli del fornitore proprietario (che nel 2024 riportava appena un 5,5%) non ci parla in realtà dei rischi, quanto piuttosto dei diversi approcci nella condivisione delle informazioni.

Invece di contare i problemi o considerarne la gravità, è meglio concentrarsi sulla cosa più importante: quanti di questi vengono effettivamente sfruttati. Nel 2024 solo lo 0,26% (cioè 11 su oltre 4.200) delle vulnerabilità rilevate nel software open source Red Hat è stato sfruttato su una qualsiasi piattaforma in situazioni reali. Assegnare la priorità esclusivamente in base ai numeri porta a un consumo di risorse significativo per problemi che in realtà rappresentano una minaccia minima.

Sia i fornitori proprietari che quelli open source danno la priorità a ciò che conta di più, la differenza principale è la trasparenza nella condivisione delle vulnerabilità prive di patch e a basso impatto. Utilizzando software closed source accettiamo implicitamente questo rischio residuo, ma ora è il momento di applicare la stessa valutazione pragmatica e basata sul rischio in modo esplicito a tutto il software, incluso il software open source. In teoria siamo d'accordo: interveniamo dove è necessario e tralasciamo altri aspetti marginali.

Siamo leader per la sicurezza e ci sentiamo di consigliare di non contare semplicemente le vulnerabilità, quanto piuttosto di promuovere una strategia incentrata sulle effettive possibilità di sfruttamento delle minacce e sul potenziale impatto aziendale. Implementare quindi dei processi che diano la priorità alle poche minacce che potrebbero risultare davvero dannose e promuovere una cultura che comprenda e accetti consapevolmente il rischio residuo gestibile. Sfrutta le risorse che hai a disposizione per mitigare le minacce che mettono davvero in pericolo la tua organizzazione.

Se vuoi approfondire, ho parlato di questo argomento alla SOSS/Fusion conference dello scorso anno, basandomi sui dati del 2023, e quest'anno ho affrontato nuovamente la questione alla VulnCon 2025, aggiornando l'intervento con i dati del 2024.