"Non ce la facciamo più": l'allarme dietro curl, software usato su 30 miliardi di dispositivi

Dietro uno dei software più diffusi al mondo c’è una realtà molto meno “patinata” di quanto si possa immaginare. curl, il progetto open source creato da Daniel Stenberg nel 1996, gira oggi dentro smartphone, smart TV, automobili, router, piattaforme cloud, sistemi embedded industriali e servizi enterprise. Secondo le stime citate dallo stesso autore, le installazioni superano i 30 miliardi. Un numero enorme per un software scritto in linguaggio C (che è anche una libreria integrabile in qualunque progetto di terze parti) utile per gestire trasferimenti HTTP, HTTPS, FTP, MQTT, SMB, IMAP, LDAP e molti altri protocolli su praticamente qualsiasi piattaforma.

Stenberg ha pubblicato un intervento molto personale, che ci ha colpito e che vogliamo analizzare, spiegando quanto sia aumentata la pressione operativa e psicologica attorno alla sicurezza del suo progetto. Il testo offre uno spaccato interessante non soltanto sulla manutenzione di curl, ma anche sullo stato attuale della sicurezza nell’open source.

La crescita delle analisi automatiche basate su AI, l’aumento delle segnalazioni di vulnerabilità e la dipendenza globale da componenti mantenuti da team ridottissimi stanno creando un carico difficile da sostenere perfino per progetti maturi e storicamente solidi.

curl: un componente invisibile ma presente ovunque

Chi lavora nell’infrastruttura Internet conosce bene la portata di libcurl: la libreria rappresenta il cuore del progetto e fornisce API utilizzate da migliaia di applicazioni differenti. Non si tratta solo del comando curl disponibile da terminale: molti software incorporano direttamente la libreria per gestire connessioni TLS, download, upload, autenticazione HTTP, redirect, proxy SOCKS5 e HTTP/2.

Una parte enorme delle comunicazioni di rete passa indirettamente attraverso codice sviluppato e revisionato da un gruppo relativamente piccolo di manutentori: curl non ha mai avuto la struttura organizzativa di fondazioni come Apache Software Foundation o Linux Foundation. Il progetto resta indipendente e non appartiene a una singola azienda.

Stenberg evidenzia un aspetto spesso trascurato: il fatto che curl sia oggi considerato uno dei software più controllati, testati e verificati al mondo non è frutto del caso. È il risultato di decenni di miglioramenti continui, con test costanti, fuzzing automatizzato – una tecnica che invia dati casuali o malformati al programma per individuare bug e vulnerabilità – revisioni del codice, analisi statica del software per rilevare errori senza eseguire il programma, gestione estremamente prudente delle regressioni e un processo di divulgazione delle vulnerabilità ormai molto maturo.

L’effetto dell’AI sulle segnalazioni di vulnerabilità

Uno dei passaggi più interessanti dell’intervento di Stenberg dal titolo “The pressure” riguarda il cambiamento radicale nella qualità e nella quantità dei report di sicurezza ricevuti dal team. Il fondatore del progetto curl aveva già criticato la massa di segnalazioni generate in modo superficiale tramite modelli linguistici: molte segnalazioni risultavano inconsistenti, duplicate o prive di reali prove tecniche. Tanto che Stenberg ha dovuto orientarsi su una misura draconiana: chiudere il programma Bug Bounty di curl.

Secondo quanto raccontato nel post, il volume delle segnalazioni è adesso diventato circa 4 o 5 volte superiore rispetto al 2024 e circa il doppio rispetto al 2025. Non solo: i report sono più dettagliati, tecnicamente accurati e spesso accompagnati da analisi approfondite.

L’uso di strumenti AI per auditing statico, symbolic execution e code review automatizzata sta iniziando a produrre risultati concreti.

Alcuni motori moderni combinano LLM (Large Language Model), tecniche fuzzing coverage-guided (generano automaticamente input casuali per esplorare più parti possibili del codice e analisi semantica del codice C per identificare pattern difficili da rilevare con i tradizionali analizzatori statici) e analisi semantica del codice C per individuare schemi e vulnerabilità difficili da rilevare con i tradizionali strumenti di analisi statica del codice.

Il riferimento fatto da Stenberg ad Anthropic Mythos, sistema che ha di recente individuato un solo problema a bassa severità nella prima scansione di curl, mostra quanto ormai la sicurezza del progetto sia esaminata quasi continuamente.

Anche un miglioramento nella qualità dei report, tuttavia, può trasformarsi in un problema operativo: ogni segnalazione richiede triage, riproduzione, verifica, analisi dell’impatto, eventuale assegnazione di CVE, sviluppo della patch, test di regressione e coordinamento con distro Linux e vendor coinvolti.

Il peso umano dietro la manutenzione dell’open source

La parte più forte del post di Stenberg non riguarda il codice: ha a che fare con il “fattore umano“.

Stenberg racconta di lavorare full-time su curl dal 2019, spesso con settimane da circa 50 ore. Descrive il progetto come qualcosa di profondamente personale, quasi inseparabile dalla propria vita professionale e privata: dopo quasi 30 anni, curl continua a occupare il centro delle sue giornate.

Qui emerge uno dei problemi storici dell’open source infrastrutturale: il mondo digitale moderno dipende da componenti critici mantenuti da gruppi molto piccoli, a volte da singole persone. L’incidente di Log4Shell nel 2021 (l’abbiamo inserito tra le 8 vulnerabilità informatiche più devastanti della storia) aveva già mostrato quanto possa essere fragile questa struttura. Anche XZ Utils, con il tentativo di inserimento di una backdoor scoperto nel 2024, ha evidenziato i rischi collegati al sovraccarico dei manutentori e alla scarsità di risorse.

Stenberg arriva persino a osservare, con una certa amarezza, che alcuni progetti open source hanno ottenuto più finanziamenti solo dopo aver subìto incidenti catastrofici. Una frase dura che però ci riporta con i piedi per terra: spesso l’industria investe seriamente nella sicurezza solo dopo una crisi vera.

Fuzzing, auditing e verifiche continue non bastano mai

curl utilizza da anni tecniche di hardening molto aggressive. Il progetto utilizza OSS-Fuzz di Google, una piattaforma che esegue test automatici su larga scala per individuare vulnerabilità e anomalie nel codice, insieme a strumenti di analisi come AddressSanitizer, che rileva errori nella gestione della memoria, e UndefinedBehaviorSanitizer, che identifica comportamenti non previsti o non sicuri del software. A ciò si aggiunge una pipeline di continuous integration (CI) multipiattaforma, che verifica automaticamente il corretto funzionamento del codice su diversi sistemi operativi e configurazioni.

Diverse componenti sono inoltre sottoposte quasi continuamente a fuzzing coverage-guided, la tecnica della quale abbiamo già parlato prima e che poggia sulla generazione di input “random” al fine di esplorare il maggior numero possibile di percorsi del codice e scoprire eventuali problemi nascosti.

Eppure nessuno nel team sostiene che il codice di curl sia “sicuro per definizione“. Anzi, il messaggio del post di Stenberg va proprio nella direzione opposta: più un software diventa critico, più aumenta la probabilità che ricercatori, aziende di sicurezza e strumenti automatizzati lo esaminino in profondità.

In pratica il successo stesso di curl genera pressione crescente: più dispositivi dipendono dalla libreria, maggiore è l’incentivo economico e tecnico per cercare vulnerabilità. Vale sia per i ricercatori in buona fede sia per gli attori ostili.

Una questione che riguarda tutta l’industria software

La riflessione di Stenberg va oltre curl. Il modello economico dell’open source infrastrutturale mostra limiti sempre più evidenti.

Molte aziende generano ricavi enormi grazie a componenti mantenuti gratuitamente da comunità ridotte, salvo poi pretendere livelli di affidabilità quasi equivalenti ai software enterprise commerciali.

C’è quindi un problema di finanziamenti per i progetti open source migliori e più utilizzati ma anche un tema di sostenibilità concreta: quando un progetto riceve oltre una segnalazione di sicurezza al giorno, con report lunghi e complessi da analizzare, la gestione tecnica inizia ad assomigliare a quella di un SOC (Security Operations Center) distribuito. Solo che spesso manca il personale necessario per gestire queste attività.

Stenberg scrive apertamente di star valutando una riduzione delle ore di lavoro per evitare burnout, proteggendo sé stesso e gli altri manutentori. Una frase che dovrebbe far riflettere parecchio chi considera l’open source una risorsa gratuita e inesauribile. La sicurezza del software dipende anche dalla capacità di preservare le persone che lo mantengono: ed è proprio l’aspetto più importante dell’intera trattazione.