Negli ultimi tempi, abbiamo visto molti giornali da tutto il mondo riportare notizie di vulnerabilità zero-day identificate dall’intelligenza artificiale. Questi episodi hanno sollevato un interrogativo: è possibile che il software open source stia diventando troppo rischioso per le imprese? Il tema è tutt’altro che marginale, considerando che l’open source rappresenta oltre tre quarti della base di codice aziendale. Eppure, la risposta è immediata: il software open source rimane intrinsecamente sicuro, strutturalmente resiliente e ha fondamenta affidabili.
L’open source costituisce la base di tutta la tecnologia moderna, andando ben oltre l’IT aziendale e Linux. Server applicativi, database, routing di rete, ambienti di sviluppo e tutti gli altri componenti invisibili che compongono il nostro tessuto tecnologico si basano in qualche misura su progetti open source.
Non esiste in sostanza un’alternativa all’open source. Il software proprietario, controllato da un’unica azienda, è ciò che vi si avvicina di più, ma non ne possiede la scalabilità, la varietà e la diffusione capillare. Con il software proprietario il codice sorgente è una scatola nera: solo il fornitore decide cosa correggere e quando. Se viene scoperta una vulnerabilità, è possibile che rimanga segreta, nota soltanto agli attaccanti che l’hanno individuata. Questo modello operativo può dare un’illusione di sicurezza, ma non fa altro che spostare il rischio dove non possiamo vederlo, rendendolo di fatto un’incognita. Nel software proprietario, le vulnerabilità proliferano nell’ombra.
L’open source ribalta questo paradigma rendendo il codice accessibile a tutti, incarnando il principio secondo cui “con sufficienti occhi, tutti i bug diventano evidenti”. Se tutti possono leggere il codice, chiunque può individuare e segnalare problemi. Oggi, questo paradigma si estende anche all’AI che amplifica enormemente la capacità di ispezione del codice. Inoltre, vista la dipendenza dall’open source di così tante organizzazioni, esiste una forte motivazione collettiva nel risolvere le vulnerabilità.
Nessun metodo di sviluppo garantisce software perfettamente sicuro, ma la natura trasparente e collaborativa dell’open source offre vantaggi distintivi rispetto ai modelli proprietari nel contrastare le minacce moderne. Le imprese sono sempre state vigili sulle vulnerabilità man mano che emergono, e continueranno a esserlo. Ciò che è cambiato è la velocità. Dal 2016 il numero di CVE pubblicati è cresciuto di oltre il 520%. Gli strumenti di scansione basati sull’AI oggi scoprono vulnerabilità zero-day critiche in ore anziché mesi, ma meno dell’uno percento delle vulnerabilità scoperte dall’AI è stato corretto. La vera sfida ora è la capacità operativa dell’impresa di assorbire e distribuire le correzioni con sufficiente rapidità.
Il problema è reso più complesso dalla mancanza di coordinamento. Ogni grande organizzazione dipende dagli stessi pacchetti open source di base – Spring Framework, Jackson, Log4j, Pandas, OpenSSL – eppure, in assenza di coordinamento, ciascuna scopre in modo indipendente le stesse vulnerabilità, sviluppa patch in isolamento e mantiene fork privati di cui nessun altro può beneficiare. Il risultato è uno sforzo ridondante, con costi enormi e qualità disomogenea, mentre l’ecosistema nel suo complesso rimane esposto. Per restare sicure, le organizzazioni devono contribuire alle community upstream, accelerare i loro standard operativi, e soprattutto devono farlo insieme.
Cosa possono fare le imprese già oggi
L’open source rimane la base più sicura per l’innovazione, ma ridurre la finestra di esposizione alle minacce richiede azioni immediate. Ecco alcuni passaggi concreti e attuabili che le imprese possono intraprendere oggi per proteggere le proprie supply chain:
· Scegliere piattaforme supportate da fornitori responsabili: l’infrastruttura è la base su cui poggia tutto il resto. È fondamentale assicurarsi che i fornitori che la supportano contribuiscano attivamente ai progetti open source che distribuiscono. Un fornitore con una solida esperienza di contributi upstream, nel backporting di sicurezza e nella divulgazione responsabile ha un interesse reale nel mantenere la salute della community, non solo nel fornire servizi alle aziende.
· Costruire un inventario completo delle dipendenze: partite da un audit del vostro portfolio applicativo per mappare la situazione di partenza. Identificate ogni libreria open source, ogni dipendenza transitiva e ogni versione attualmente in produzione.
· Definire i tempi del ciclo patch-to-production: date una misura chiara alla vostra situazione attuale. Quanto tempo impiega effettivamente una patch upstream ad attraversare le scansioni di sicurezza interne, i test, i change advisory board e le pipeline di deployment? Una volta definiti i tempi, stabilite obiettivi ambiziosi per ridurre questa finestra temporale.
· Automatizzare le pipeline di rebuild e redeploy: con la frequenza delle minacce che si riduce sempre più da mesi a ore, gli aggiornamenti manuali non sono più sostenibili. Preparate il vostro ambiente per rebuild applicativi frequenti, deterministici e automatizzati, in modo da poter integrare pacchetti sicuri a velocità elevata.
· Adottare soluzioni di sicurezza attive: utilizzate soluzioni di supply chain attive che forniscano baseline zero-CVE e protezione runtime, come Red Hat Hardened Images, Red Hat Trusted Libraries e OpenShift Advanced Cluster Security, per accelerare i processi.
Accelerare il cambiamento con Project Lightwell
IBM e Red Hat stanno costruendo un motore di remediation progettato per supportare le imprese che vogliono automatizzare le pipeline per integrare più velocemente le correzioni. Abbiamo recentemente lanciato Project Lightwell, un investimento congiunto da 5 miliardi di dollari sostenuto da una forza globale di oltre 20.000 ingegneri, con l’obiettivo di ridefinire la sicurezza della supply chain del software nell’era dell’AI.
Project Lightwell scala la metodologia collaudata da Red Hat in vent’anni di backporting di patch di sicurezza a livello enterprise. Stiamo estendendo questa precisa disciplina ingegneristica oltre l’ambito del sistema operativo verso i framework applicativi e dipendenze, iniziando da Maven/Java ed espandendoci verso PyPI, npm e altri ancora. Combinando l’AI per l’acquisizione ad alto volume delle minacce con l’esperienza ingegneristica umana, correggiamo in modo mirato le versioni stabili realmente in uso, evitando aggiornamenti indiscriminati che metterebbero a rischio l’operatività.
Senza un meccanismo che permetta di accettare le correzioni upstream, ogni backport sviluppato autonomamente da un’impresa crea un fork privato permanente, che deve essere mantenuto attraverso ogni successiva vulnerabilità, aggiornamento e modifica delle dipendenze. Questo aumenta costi e rischi per l’organizzazione. Project Lightwell rompe questo ciclo: Red Hat sviluppa la correzione, la mette a disposizione dell’impresa e la aggiunge al progetto open source originario. In questo modo, la correzione diventa parte del codebase pubblico. Questo approccio si allinea alla direzione tracciata dal recente Ordine Esecutivo su AI e cybersecurity emanato dall’amministrazione Trump che prevede la creazione di un “AI cybersecurity clearinghouse” per coordinare scansione, validazione e remediation delle vulnerabilità nelle infrastrutture critiche. Project Lightwell è concepito per essere la spina dorsale operativa del settore privato in supporto a questo mandato.
Lavorare insieme per proteggere le imprese e l’intero ecosistema open source
Mettere in sicurezza la supply chain del software è una sfida che riguarda tutto il settore, e che nessuna singola impresa può affrontare da sola. Attraverso Project Lightwell stiamo collaborando con un gruppo selezionato di leader del settore finanziario e delle infrastrutture critiche per creare un clearinghouse aziendale sicuro.
Questa rete di intelligence collaborativa offre tre capacità che nessuna impresa può sviluppare autonomamente.
1. I partecipanti condividono le scoperte di nuove vulnerabilità e ricevono patch coordinate prima della divulgazione pubblica, trasformando scoperte isolate in difesa condivisa.
2. Ogni patch viene consegnata pronta per la produzione, con firma crittografica, corredata di SBOM machine-readable e security advisory per soddisfare i requisiti di compliance.
3. Project Lightwell opera secondo un mandato upstream-always: ogni correzione sviluppata viene sottoposta ai progetti open source di origine. Lavorando insieme in questo clearinghouse non ci limitiamo a proteggere le singole imprese: restituiamo sistematicamente i progressi in ambito sicurezza alla community, mantenendo l’open source sicuro per tutti.
L’open source ha costruito l’impresa moderna. L’azione coordinata e Project Lightwell contribuiscono a mantenere questo codice sicuro intervenendo più rapidamente, come un ecosistema che opera insieme, in modo aperto.
