Il 21 ottobre 2026 PHP ha rilasciato le correzioni per due vulnerabilità critiche di esecuzione remota di codice, CVE-2026-109618 e CVE-2026-109619, entrambe classificate con un punteggio di gravità pari a 9,2 su 10. Le informazioni sulle falle erano però già circolate il giorno precedente, compromettendo il processo di divulgazione coordinata. Le due vulnerabilità, indicate complessivamente come PHP2Shell, interessavano il motore PHP e non una specifica applicazione. I ricercatori avevano dimostrato la possibilità di eseguire codice da remoto, senza autenticazione, su installazioni di WordPress, Drupal e Joomla, nelle configurazioni necessarie allo sfruttamento.
Il caso è particolarmente significativo per la sua cronologia. AWS ha identificato retrospettivamente tentativi di sfruttamento risalenti al 17 ottobre, quattro giorni prima del rilascio delle patch. Le rilevazioni provenivano dagli honeypot MadPot e non dimostravano compromissioni riuscite di sistemi reali, ma confermavano che la vulnerabilità era già oggetto di attività ostili prima della divulgazione pubblica. Il problema non riguardava quindi soltanto la velocità di aggiornamento dei sistemi: parte del rischio si era manifestata quando gli amministratori non disponevano ancora di una correzione ufficiale. La ricostruzione pubblicata da Akamai mostra quanto una divulgazione anticipata possa ridurre ulteriormente il tempo disponibile per intervenire.
Nella stessa settimana Node.js ha distribuito le correzioni per Node2Shell, identificata come CVE-2026-111497, una vulnerabilità di corruzione della memoria nel decoder Brotli sviluppato da Google. Il problema si è esteso ben oltre Node.js, coinvolgendo componenti utilizzati da .NET, Python, Java e altri ambienti software. La vulnerabilità era stata individuata da ricercatori di OpenAI attraverso Codex Security, un sistema di analisi del codice basato sull'intelligenza artificiale.
Questi episodi hanno riportato al centro una questione che accompagna da decenni il dibattito sulla sicurezza informatica: la disponibilità pubblica del codice sorgente costituisce un vantaggio per la sicurezza oppure facilita il lavoro degli attaccanti? L'evoluzione recente dell'intelligenza artificiale rende la domanda particolarmente attuale, perché modifica sensibilmente i costi e i tempi necessari per individuare vulnerabilità.
La risposta richiede però di distinguere la capacità di scoprire un difetto dalla possibilità di sfruttarlo e, soprattutto, dalla capacità di correggerlo. La tesi che intendo sostenere è che l'intelligenza artificiale non abbia reso obsoleto il modello open source, ma stia mettendo in crisi i tempi e i processi con cui il software viene mantenuto in sicurezza.
La scoperta delle vulnerabilità sta accelerando
La ricerca di vulnerabilità è stata storicamente un'attività ad alta intensità di competenze e di tempo. Analizzare un'applicazione complessa richiedeva la comprensione della sua architettura, l'identificazione delle superfici di attacco, la ricostruzione dei flussi di esecuzione e la verifica delle condizioni necessarie allo sfruttamento di un difetto. Anche in presenza di strumenti automatici, una parte consistente del lavoro rimaneva manuale.
I modelli di intelligenza artificiale stanno progressivamente riducendo questo costo. Nel 2026, ad esempio, il modello Mythos di Anthropic è stato utilizzato per individuare numerose vulnerabilità nei sistemi di alcune istituzioni finanziarie americane, contribuendo ad accelerare attività di analisi e correzione che in precedenza richiedevano tempi più lunghi. Un elemento particolarmente interessante riguarda la capacità di correlare difetti apparentemente indipendenti, ricostruendo catene di attacco che possono produrre conseguenze più gravi delle singole vulnerabilità considerate isolatamente.
Non significa che l'individuazione delle vulnerabilità sia diventata un problema risolto. I modelli continuano a produrre falsi positivi e non sempre sono in grado di valutare correttamente le condizioni operative necessarie per sfruttare un difetto. Tuttavia, l'automazione sta rendendo economicamente sostenibili analisi che prima sarebbero state troppo costose rispetto al beneficio atteso.
Questa trasformazione ha conseguenze particolari nell'ecosistema open source. Secondo una ricerca della Cloud Security Alliance, nel corso del 2026 diversi progetti hanno limitato o sospeso alcuni canali di segnalazione delle vulnerabilità a causa del crescente volume delle comunicazioni. Il progetto curl, ad esempio, ha terminato a gennaio il proprio programma di bug bounty a pagamento, pur mantenendo disponibile il canale per la segnalazione dei problemi di sicurezza. La decisione era stata motivata anche dalla necessità di ridurre gli incentivi all'invio di rapporti automatici di scarsa qualità.
La situazione è resa più complessa dal miglioramento progressivo degli strumenti. Greg Kroah-Hartman, uno dei principali manutentori del kernel Linux, ha osservato che le segnalazioni prodotte con l'assistenza dell'intelligenza artificiale risultano sempre più spesso fondate. Di conseguenza, non è più possibile considerare l'intero fenomeno come semplice rumore generato automaticamente.
Una segnalazione tecnicamente corretta richiede comunque un processo di verifica, correzione, test e distribuzione. Ogni modifica deve essere valutata rispetto alle possibili regressioni e alla compatibilità con le versioni mantenute. Nei progetti affidati a gruppi ristretti di sviluppatori, spesso volontari, la capacità di gestire questo lavoro può diventare il principale limite operativo.
Si sta quindi creando uno squilibrio tra la velocità con cui vengono individuati nuovi difetti e le risorse disponibili per correggerli. L'intelligenza artificiale può contribuire anche alla seconda attività, ma non elimina la necessità di verificare la correttezza delle modifiche e di assumersi la responsabilità del loro rilascio.
La sicurezza attraverso l'oscurità
L'accelerazione della ricerca automatizzata ha riaperto il dibattito sulla cosiddetta security by obscurity, ossia sull'utilità di limitare l'accesso alle informazioni relative all'implementazione di un sistema. Secondo questa impostazione, mantenere riservato il codice sorgente aumenterebbe il costo necessario per individuare e sfruttare eventuali vulnerabilità.
L'argomento non è privo di fondamento. La disponibilità del sorgente permette a un ricercatore di analizzare direttamente strutture dati, funzioni e flussi di esecuzione, mentre un software distribuito esclusivamente in forma compilata richiede normalmente un'attività preliminare di reverse engineering. La questione è stabilire quanto questa differenza incida ancora sulla sicurezza effettiva.
Un caso recente è quello della vulnerabilità individuata da Wiz nei binari proprietari di GitHub attraverso un assistente di reverse engineering basato sull'intelligenza artificiale. Il ricercatore ha spiegato di aver studiato quel bersaglio per circa due anni, senza riuscire a giustificare l'investimento necessario per completare manualmente l'analisi. L'impiego dell'IA ha modificato il rapporto tra il tempo richiesto e la probabilità di ottenere risultati utili.
Un esperimento pubblicato da Thales ha mostrato che, in uno specifico scenario di valutazione, un modello dotato di strumenti di analisi è riuscito a individuare otto vulnerabilità su dieci in un binario compilato in circa tre minuti. Il risultato non può essere generalizzato a qualsiasi programma proprietario, ma dimostra come il costo del reverse engineering possa ridursi significativamente quando l'analisi viene assistita da modelli sufficientemente capaci.
Il discorso è differente per le applicazioni web che eseguono la propria logica sul server. In questi sistemi l'attaccante non dispone normalmente né del sorgente né dei binari del backend e deve ricostruire il comportamento dell'applicazione attraverso le interfacce esposte. La riservatezza dell'implementazione può quindi rappresentare un ostacolo concreto, soprattutto nella ricerca di vulnerabilità legate alla logica di business o ai controlli di autorizzazione.
Anche in questo ambito, tuttavia, le capacità degli strumenti automatici stanno crescendo. Uno studio riportato da Stingrai ha evidenziato limiti ancora significativi degli agenti di penetration testing rispetto ai ricercatori umani, mentre i risultati ottenuti da XBOW su HackerOne hanno dimostrato che sistemi automatici possono raggiungere livelli competitivi nella ricerca di vulnerabilità reali. I due risultati non sono direttamente confrontabili, ma indicano che l'efficacia dell'analisi automatizzata dipende dal contesto e dalla tipologia di difetto ricercato.
Inoltre, una parte dei problemi di sicurezza delle applicazioni web non richiede alcuna conoscenza del codice sorgente. Errori di configurazione, controlli di accesso insufficienti e vulnerabilità presenti nei componenti condivisi possono essere individuati attraverso il comportamento del sistema. A questo si aggiungono i casi nei quali il sorgente viene esposto accidentalmente, come nelle installazioni web che rendono accessibili directory .git, file di configurazione o informazioni di deploy.
La riservatezza del codice può dunque aumentare il costo di alcune analisi, ma non costituisce una garanzia di sicurezza. Il suo valore dipende dal tipo di vulnerabilità e dalla quantità di informazioni che un attaccante può comunque ricavare dall'interazione con il sistema.
Il ruolo dei componenti condivisi
La contrapposizione tra software aperto e proprietario diventa ancora meno significativa quando si considera l'architettura delle applicazioni moderne. Il codice sviluppato direttamente rappresenta spesso soltanto una parte del software effettivamente eseguito in produzione. Runtime, framework, librerie e componenti di sistema costituiscono una base comune sulla quale vengono realizzate applicazioni differenti.
Una vulnerabilità in un componente condiviso può interessare un numero elevato di prodotti, indipendentemente dalla licenza con cui questi vengono distribuiti. Per un attaccante, la possibilità di individuare un difetto riutilizzabile su sistemi diversi può essere più interessante rispetto all'analisi di una singola applicazione.
PHP2Shell rappresenta un esempio particolarmente chiaro. Le vulnerabilità riguardavano direttamente il motore PHP e, nelle configurazioni basate su mod_php, era stata dimostrata la possibilità di ottenere esecuzione remota di codice prima ancora che venisse elaborata la logica applicativa. Il problema non dipendeva quindi da errori introdotti dagli sviluppatori dei singoli CMS, ma da un difetto del componente sottostante, pur in presenza di specifiche condizioni necessarie allo sfruttamento.
Lo stesso problema è emerso nei prodotti commerciali. Nell'ottobre 2026 è stata documentata una campagna che aveva compromesso 25 server, sfruttando PHP2Shell anche attraverso pannelli di gestione di prodotti proprietari. I ricercatori hanno ipotizzato un collegamento con un gruppo di origine cinese, senza che tale attribuzione costituisse una conclusione definitiva. Il caso dimostra come la riservatezza del codice applicativo non elimini le vulnerabilità presenti nei componenti sui quali il prodotto è costruito.
Node2Shell offre un secondo esempio, particolarmente interessante per gli ambienti .NET. La vulnerabilità riguardava il decoder Brotli, una libreria nativa sviluppata da Google e incorporata in diversi runtime. La presenza del componente vulnerabile poteva interessare quindi applicazioni realizzate in linguaggi differenti, compresi quelli normalmente considerati sicuri nella gestione della memoria.
Occorre però distinguere la presenza di una libreria vulnerabile dall'effettiva possibilità di sfruttarla. Nel caso di .NET, Microsoft ha precisato che l'esposizione dipendeva dall'elaborazione di dati Brotli non attendibili attraverso specifici percorsi applicativi, tra cui la decompressione delle richieste ASP.NET Core, quella automatica delle risposte HTTP e le API di System.IO.Compression. Le prime due funzionalità non sono abilitate per impostazione predefinita. L'analisi del rischio deve quindi verificare non soltanto la versione installata, ma anche se e come il componente venga utilizzato.
La distinzione è essenziale. Una vulnerabilità può essere presente nel software senza essere raggiungibile da un attaccante nelle condizioni operative esistenti. Viceversa, una componente apparentemente secondaria può diventare una superficie di attacco critica quando viene utilizzata per elaborare input esterni non attendibili.
Dalla scoperta alla correzione: il problema della finestra di esposizione
I casi di ottobre mostrano che la pubblicazione tempestiva di una patch non coincide necessariamente con la riduzione immediata del rischio. Il processo di correzione comprende almeno due fasi distinte: il lavoro del produttore, che deve sviluppare e distribuire l'aggiornamento, e quello di chi gestisce il software, che deve individuare i sistemi interessati, verificare la compatibilità della modifica e applicarla effettivamente.
La finestra di esposizione di un sistema non coincide necessariamente con il periodo compreso tra la divulgazione di una vulnerabilità e l'installazione della relativa patch. Il difetto può infatti essere sfruttato prima della divulgazione pubblica, come suggeriscono i tentativi osservati da AWS nel caso PHP2Shell. È quindi più preciso distinguere il periodo complessivo di esposizione dalla finestra di mancato aggiornamento, cioè l'intervallo durante il quale una correzione è già disponibile ma non è stata ancora applicata.
Questa seconda finestra dipende direttamente dai processi di manutenzione dell'organizzazione. Node2Shell ne offre un esempio concreto. Node.js ha pubblicato le correzioni il 21 ottobre e Microsoft ha rilasciato aggiornamenti straordinari per .NET 8, 9 e 10 il 25 ottobre, rispettivamente nelle versioni 8.0.33, 9.0.22 e 10.0.14. Il 27 ottobre la CISA ha inserito la vulnerabilità nel catalogo Known Exploited Vulnerabilities, in presenza di evidenze di sfruttamento attivo. Il lavoro dei produttori è stato relativamente rapido, ma la distribuzione delle correzioni ai sistemi effettivamente in esercizio ha richiesto interventi distinti.
La modalità di distribuzione delle applicazioni può rendere questo processo più complesso. In .NET, ad esempio, le applicazioni pubblicate in modalità self-contained incorporano il runtime necessario alla loro esecuzione. L'aggiornamento del runtime installato sul server non modifica automaticamente la copia inclusa nell'applicazione, che deve essere ricompilata e distribuita nuovamente. Un problema analogo riguarda i container e gli eseguibili che incorporano direttamente versioni specifiche delle dipendenze.
Senza un inventario affidabile delle componenti e delle relative versioni, un'organizzazione può quindi considerare completato un aggiornamento pur mantenendo in esercizio applicazioni vulnerabili. Il problema non è esclusivamente tecnologico: riguarda la conoscenza del patrimonio software, l'organizzazione delle attività di manutenzione e la disponibilità di procedure ripetibili di compilazione, verifica e distribuzione.
Il caso delle versioni fuori supporto
La situazione diventa più critica quando una vulnerabilità interessa una versione che ha già raggiunto la fine del supporto. .NET 6 costituisce un esempio significativo. Microsoft ha terminato il supporto il 12 novembre 2024, con l'ultima versione ufficiale 6.0.36. Secondo l'analisi pubblicata da HeroDevs, la vulnerabilità Brotli interessa anche questa linea, per la quale Microsoft non ha distribuito una correzione ufficiale. Le versioni di manutenzione successive proposte dal fornitore appartengono a un servizio commerciale di supporto esteso e non al normale ciclo di aggiornamento Microsoft.
Per le organizzazioni rimaste su .NET 6, la soluzione ordinaria consiste nella migrazione a una versione supportata. In alternativa, possono essere valutati servizi di manutenzione estesa o misure temporanee di mitigazione, tenendo conto delle condizioni effettive di esposizione. In assenza di un percorso di aggiornamento, tuttavia, una vulnerabilità può rimanere irrisolta per un periodo indeterminato.
La questione non riguarda esclusivamente software particolarmente datato. Il 10 novembre 2026 terminerà il supporto di .NET 8 e .NET 9, nonostante entrambe le versioni siano ancora ampiamente utilizzate. La durata del supporto deve quindi essere considerata già nella pianificazione dello sviluppo e non soltanto quando emerge una vulnerabilità critica.
Nella pubblica amministrazione e nelle piccole organizzazioni è frequente incontrare applicazioni mantenute in produzione per molti anni, talvolta senza aggiornamenti significativi perché il loro funzionamento viene considerato soddisfacente. La continuità operativa, tuttavia, non equivale alla sicurezza. Un'applicazione può continuare a svolgere correttamente le proprie funzioni anche quando il framework, il runtime o le librerie da cui dipende non ricevono più correzioni.
Il problema della manutenzione assume così una dimensione strutturale: non riguarda soltanto la rapidità con cui viene applicata una singola patch, ma la capacità dell'organizzazione di mantenere l'intero sistema entro un ciclo di vita tecnologico sostenibile.
Linguaggi, memoria e dipendenze: quali fattori incidono sulla sicurezza?
Il confronto tra linguaggi di programmazione viene spesso affrontato attraverso classifiche che cercano di individuare la piattaforma più sicura. Questo approccio presenta limiti evidenti, perché il numero di vulnerabilità pubblicate dipende anche dalla diffusione di una tecnologia, dall'intensità delle attività di ricerca e dalla trasparenza dei processi di divulgazione. Un ecosistema molto analizzato può presentare un numero maggiore di vulnerabilità note senza essere necessariamente meno sicuro.
Esistono tuttavia caratteristiche architetturali che incidono sulla probabilità di introdurre determinate categorie di difetti. Una delle più rilevanti è la sicurezza della memoria. Storicamente, una quota elevata delle vulnerabilità gravi di Android è stata associata a errori nella gestione della memoria, soprattutto in componenti implementati in C e C++. Google ha progressivamente adottato Rust per lo sviluppo di nuovo codice e nel 2025 ha registrato una riduzione delle vulnerabilità di questa categoria sotto il 20% del totale, rispetto a valori storici prossimi al 70%.
Il risultato non permette di attribuire ogni miglioramento esclusivamente a Rust, ma fornisce un'evidenza importante a favore delle strategie che prevengono determinate classi di errori già attraverso le proprietà del linguaggio. PHP2Shell e Node2Shell riguardano proprio vulnerabilità di corruzione della memoria in componenti implementati in C. Ridurre l'utilizzo di codice non sicuro nella gestione della memoria può quindi diminuire strutturalmente una parte della superficie di rischio.
La scelta di un linguaggio memory-safe non garantisce però che l'intero sistema presenti le stesse caratteristiche. PHP e Node.js utilizzano motori realizzati principalmente in C e C++, mentre Java e .NET eseguono normalmente codice gestito ma integrano runtime e librerie native. Rust e Go consentono di realizzare gran parte del software senza ricorrere necessariamente a componenti C o C++, pur permettendo l'integrazione con codice nativo quando richiesta.
| Piattaforma | Gestione della memoria | Componenti nativi | Dipendenze |
|---|---|---|---|
| Rust | Sicurezza della memoria nel codice safe |
Generalmente limitati, ma possibili | Ecosistema ampio di librerie esterne |
| Go | Gestione sicura della memoria | Generalmente limitati, ma possibili | Libreria standard ricca |
| .NET / C# | Codice gestito, salvo uso di funzionalità unsafe |
Runtime e librerie native | Libreria standard ricca |
| Java | Codice gestito | JVM e librerie native | Ecosistema ampio |
| Node.js | Codice JavaScript gestito | Motore e moduli C/C++ | Ecosistema molto ampio |
| PHP | Codice PHP gestito | Motore ed estensioni in C | Variabile, particolarmente ampio nei CMS |
Confronto qualitativo delle caratteristiche architetturali. La tabella non rappresenta una classifica della sicurezza.
La tabella descrive differenze architetturali e non costituisce una graduatoria di sicurezza. Quest'ultima dipende anche dalla qualità delle implementazioni, dalla configurazione, dall'esposizione dei servizi e dalla capacità di mantenere aggiornate le dipendenze.
Il numero di pacchetti utilizzati non rappresenta, da solo, una misura affidabile del rischio. Una libreria di terze parti mantenuta correttamente può essere più sicura di una funzione sviluppata internamente. Al contrario, l'utilizzo di numerose dipendenze prive di manutenzione può complicare gli aggiornamenti e introdurre vulnerabilità difficili da identificare. La questione principale non è quindi eliminare indiscriminatamente le librerie esterne, ma conoscerne il ruolo, valutarne l'affidabilità e controllarne il ciclo di vita.
Anche il modello di distribuzione del runtime incide sulla sicurezza operativa. Nei servizi completamente gestiti una parte degli aggiornamenti viene effettuata dal fornitore, mentre nei sistemi self-hosted la responsabilità ricade sull'organizzazione. Le applicazioni distribuite in container o con runtime incorporati richiedono inoltre procedure specifiche per assicurare che la correzione raggiunga effettivamente tutti gli ambienti.
La scelta tecnologica può contribuire a prevenire determinate vulnerabilità, ma non sostituisce una manutenzione adeguata. Un'applicazione sviluppata in Rust e abbandonata per anni non è necessariamente più sicura di un'applicazione PHP sottoposta regolarmente a verifiche e aggiornamenti.
Ripensare la manutenzione del software
L'accelerazione della scoperta delle vulnerabilità impone di considerare la manutenzione una componente strutturale della sicurezza, piuttosto che un'attività successiva allo sviluppo. L'obiettivo non può essere soltanto ridurre il numero di difetti introdotti, ma deve comprendere la capacità di identificarne rapidamente l'impatto, limitare le condizioni di sfruttamento e applicare le correzioni senza compromettere la continuità del servizio.
Il primo requisito è disporre di una conoscenza affidabile dei componenti effettivamente utilizzati in produzione. Un inventario delle dipendenze, eventualmente supportato da una Software Bill of Materials, permette di individuare le applicazioni interessate quando viene pubblicata una nuova vulnerabilità. Per essere utile, però, deve descrivere le versioni realmente distribuite e non soltanto quelle presenti nel repository di sviluppo. La differenza diventa rilevante soprattutto in presenza di container, runtime incorporati e applicazioni che non vengono aggiornate contestualmente alle librerie di sistema.
Su questa base devono essere organizzati processi di aggiornamento verificabili e sufficientemente rapidi. Strumenti come Dependabot e Renovate possono automatizzare l'individuazione delle nuove versioni, ma il loro valore dipende dalla presenza di pipeline capaci di compilare, testare e distribuire le applicazioni. L'automazione non dovrebbe tradursi nell'applicazione indiscriminata delle modifiche, bensì nella riduzione del lavoro manuale necessario per produrre e distribuire una correzione già verificata.
La velocità di aggiornamento non è tuttavia l'unico elemento rilevante. La riduzione della superficie di attacco, attraverso la disabilitazione delle funzionalità inutilizzate e l'eliminazione dei servizi non necessari, può limitare l'esposizione anche in presenza di componenti vulnerabili. Node2Shell mostra l'importanza di questa distinzione: la presenza del decoder Brotli non comportava automaticamente la possibilità di sfruttarlo, che dipendeva dall'effettivo trattamento di dati controllabili dall'attaccante.
Occorre inoltre considerare le conseguenze di una compromissione. Privilegi minimi, isolamento dei servizi, segmentazione delle reti e protezione delle credenziali possono impedire che l'esecuzione di codice in un singolo processo consenta il controllo di altri sistemi. Queste misure non eliminano la vulnerabilità iniziale, ma riducono il possibile impatto dell'attacco e il rischio di movimenti laterali all'interno dell'infrastruttura.
Le protezioni temporanee possono avere un ruolo durante il periodo necessario per distribuire una patch, purché siano valutate rispetto al funzionamento della vulnerabilità. Un WAF può bloccare richieste riconoscibili, ma non garantisce di intercettare contenuti che vengono decompressi o elaborati soltanto all'interno dell'applicazione. Nel caso di Node2Shell, Datadog ha evidenziato proprio questo limite, indicando l'aggiornamento del decoder come intervento risolutivo. Eventuali blocchi del traffico Brotli possono rappresentare mitigazioni specifiche, ma non equivalgono alla correzione del componente.
Infine, l'intelligenza artificiale può essere impiegata per migliorare lo stesso processo difensivo. L'analisi continua del codice, il controllo delle dipendenze e il supporto alla verifica delle patch sono attività nelle quali i modelli possono ridurre significativamente il lavoro richiesto. La loro integrazione nei processi di sviluppo deve però prevedere controlli sulla qualità dei risultati, dal momento che una vulnerabilità segnalata non è necessariamente sfruttabile e una correzione suggerita non è automaticamente corretta.
In questo scenario anche la sicurezza attraverso l'oscurità mantiene un ruolo, ma limitato e complementare. Evitare l'esposizione di configurazioni, versioni non necessarie, repository e informazioni implementative può aumentare il costo di un attacco. Non può tuttavia compensare l'utilizzo di componenti vulnerabili o l'assenza di un processo affidabile di manutenzione.
Conclusioni
L'intelligenza artificiale sta modificando il rapporto tra scoperta e correzione delle vulnerabilità. La disponibilità di strumenti capaci di analizzare grandi quantità di codice e di assistere il reverse engineering riduce una parte dei costi che storicamente limitavano la ricerca di difetti. Questo cambiamento interessa sia il software aperto sia quello proprietario, sebbene con modalità differenti.
L'accessibilità del sorgente può facilitare l'analisi di un progetto open source, ma consente anche verifiche indipendenti e contributi alla correzione che non dipendono esclusivamente dal produttore. Il software proprietario può mantenere una barriera informativa, soprattutto nelle applicazioni server-side, ma questa protezione perde efficacia quando l'attacco riguarda componenti condivisi o vulnerabilità individuabili attraverso il comportamento del sistema.
I casi PHP2Shell e Node2Shell mostrano inoltre che il rischio non dipende soltanto dalla pubblicazione delle informazioni. I tentativi di sfruttamento possono precedere la divulgazione ufficiale, mentre le correzioni possono raggiungere gli ambienti di produzione con ritardi significativi. Nei sistemi fuori supporto, l'assenza di un percorso ordinario di aggiornamento può rendere questo problema permanente.
Ne consegue che la capacità di mantenere aggiornato il software assume un peso crescente rispetto alla sola riservatezza dell'implementazione. La sicurezza dipende dalla conoscenza delle componenti utilizzate, dalla riduzione della superficie di attacco, dall'isolamento dei sistemi e dalla possibilità di distribuire rapidamente le correzioni. La scelta del linguaggio e l'adozione di tecnologie memory-safe possono ridurre alcune categorie di vulnerabilità, ma non eliminano la necessità di una manutenzione continua.
Non è quindi l'open source a essere diventato insostenibile. A essere messo in discussione è un modello di gestione nel quale l'aggiornamento del software può essere rinviato indefinitamente finché l'applicazione continua a funzionare. L'intelligenza artificiale sta riducendo il tempo necessario per individuare e sfruttare alcuni difetti; i processi di manutenzione devono evolvere di conseguenza.
La distinzione determinante non è tra codice aperto e codice chiuso, ma tra sistemi per i quali esiste una capacità effettiva di controllo e aggiornamento e sistemi che rimangono in esercizio senza una gestione adeguata delle proprie dipendenze. In questo senso, l'IA non ha ucciso l'open source: ha ridotto drasticamente il tempo che possiamo permetterci di dedicare agli aggiornamenti.