open source · catena di fornitura · manutentori
La libreria open source che regge il tuo stack potrebbe avere un solo manutentore
Quasi ogni applicazione che esegui dipende da librerie open source, e quelle librerie dipendono da altre, per diversi livelli. Ciò che è facile dimenticare è quanti di quei livelli siano mantenuti da uno o due volontari non retribuiti. Quando un progetto del genere è critico e privo di risorse, diventa un singolo punto di guasto - per l'affidabilità e, come mostra la storia recente, per la sicurezza.
L'immagine che xkcd ha azzeccato esattamente
Nel 2020, la vignetta xkcd 2347, intitolata «Dependency», disegnava l'infrastruttura digitale moderna come una precaria torre di blocchi, con l'intera struttura appoggiata su un piccolo pezzo etichettato come un progetto «che una persona a caso in Nebraska ha mantenuto senza riconoscimenti dal 2003». È diventata un classico istantaneo tra gli sviluppatori perché non è tanto una battuta quanto un diagramma accurato. L'albero delle dipendenze di un progetto tipico davvero si restringe, in alcuni punti, allo sforzo di una singola persona nel tempo libero.
Quando la torre ha davvero vacillato
Questi non sono rischi ipotetici. Alcuni incidenti ampiamente documentati rendono concreto lo schema:
- Heartbleed (2014). Una grave falla in OpenSSL, la libreria che protegge gran parte del traffico HTTPS del web, esponeva memoria che poteva far trapelare chiavi e password. All'epoca, OpenSSL era mantenuta da un gruppo minuscolo con finanziamenti minimi. Lo spavento ha spinto direttamente sforzi di finanziamento dell'industria per l'infrastruttura open source critica.
- Log4Shell (dicembre 2021). Una falla critica di esecuzione di codice remoto in Log4j, una libreria di logging incorporata in innumerevoli applicazioni Java, è stata classificata con la gravità massima. Log4j era mantenuta da un piccolo team di volontari, che ha poi trascorso un periodo estenuante a correggere un problema che colpiva un'enorme fetta del software aziendale.
- La backdoor di xz-utils (2024). È l'avvertimento più chiaro di tutti. Secondo i dati pubblici (CVE-2024-3094, classificato CVSS 10.0), un contributore che usava il nome «Jia Tan» ha trascorso circa due anni a costruire fiducia sul progetto di compressione xz, ottenendo i diritti di commit e poi di gestore dei rilasci, mentre lo storico manutentore solitario, Lasse Collin, era sotto pressione e, secondo quanto riferito, in burnout. Del codice malevolo è stato inserito in xz 5.6.0 e 5.6.1, che introduceva una backdoor nella libreria usata da SSH su alcune distribuzioni Linux. È stato individuato quasi per caso, prima di un'ampia diffusione, da un ingegnere che indagava sul perché gli accessi fossero leggermente lenti.
Perché un solo manutentore è un rischio strutturale
Un progetto con un unico manutentore concentra diversi rischi in un solo punto. Se il manutentore perde interesse, si ammala o semplicemente va in burnout, gli aggiornamenti e le correzioni di sicurezza si fermano - il problema dell'«abandonware». Se è sovraccarico, la pressione a cedere il controllo crea un'apertura per un malintenzionato, che è esattamente ciò che il caso xz-utils ha sfruttato. E poiché tanti progetti a valle importano la libreria in modo transitivo, un problema alla radice si propaga a tutto ciò che è costruito sopra, spesso senza che quei team a valle sappiano nemmeno che la dipendenza fosse lì.
La verità scomoda è che la sostenibilità dell'open source è un problema economico travestito da problema tecnico. Il codice è gratuito; l'attenzione umana che lo tiene sicuro non lo è, ed è frequentemente non retribuita.
Cosa possono davvero fare i team
Non puoi mantenere personalmente ogni dipendenza, ma puoi smettere di trattarle come infrastruttura gratuita che si mantiene da sola:
- Conosci il tuo albero delle dipendenze. Genera una distinta base del software (SBOM) per sapere davvero cosa distribuisci, comprese le dipendenze transitive che non hai mai scelto direttamente.
- Tieni d'occhio il bus factor. Per le librerie da cui dipendi di più, controlla quanti manutentori attivi ci sono. Una dipendenza critica con un solo contributore è un rischio da registrare, non da ignorare.
- Fissa e rivedi gli aggiornamenti. Fissa le versioni e rivedi le modifiche invece di scaricare alla cieca l'ultima release; la backdoor di xz è arrivata in una release dall'aspetto normale.
- Restituisci dove conta. Sponsorizzare, finanziare o contribuire tempo di manutenzione ai progetti da cui dipendi non è beneficenza - è ridurre il tuo stesso rischio. Fondi dell'industria e fondazioni esistono ora in parte per questo motivo.
Niente di tutto ciò elimina del tutto il rischio, ma trasforma una dipendenza invisibile in una gestita. I progetti che reggono il tuo stack meritano di essere conosciuti per nome.
FAQ
L'open source è meno sicuro del codice chiuso? Non intrinsecamente - il codice aperto può essere verificato da chiunque, il che è un vantaggio genuino. Il rischio di cui si parla qui riguarda le risorse e la manutenzione, non l'apertura in sé. Il software sottofinanziato, di qualsiasi tipo, è un rischio.
Cos'è il «bus factor»? È il numero di persone che dovrebbero essere investite da un autobus (o semplicemente andarsene) prima che un progetto sia nei guai seri. Un bus factor di uno significa che una singola persona è il progetto.
Cos'era la backdoor di xz-utils? Una backdoor piazzata deliberatamente (CVE-2024-3094) inserita da un contributore che si era guadagnato la fiducia di manutentore nel tempo, individuata nel 2024 prima di raggiungere la maggior parte dei sistemi in produzione. È l'esempio di riferimento di ingegneria sociale su un progetto con un unico manutentore.
Come trovo le dipendenze con un unico manutentore? Inizia con un SBOM del tuo progetto, poi guarda i repository delle tue librerie più critiche: l'attività recente dei commit e il numero di manutentori attivi dicono molto.