Le dipendenze open source sono ovunque nel tuo progetto. Il tuo progetto ha 47 dipendenze dirette. Quelle 47 dipendenze hanno 847 dipendenze transitive, cioè pacchetti che non hai scelto tu direttamente ma che arrivano insieme agli altri. Ognuna di queste è mantenuta da qualcuno che non conosci, che potrebbe smettere domani, e il cui codice finisce direttamente nel tuo processo di build e nel software che metti in produzione. npm install è gratis. Tutto il resto no.
C'è un paradosso nell'open source: lo usiamo perché è gratuito, affidabile e comunitario. Ma gratuito non significa senza costi, affidabile non significa per sempre, e comunitario non significa che qualcuno si prende la responsabilità quando qualcosa va storto.
Il costo che non vedi
Manutenzione continua
Ogni dipendenza nel tuo progetto è codice che qualcun altro ha scritto e che tu devi mantenere aggiornato. Non perché vuoi le ultime feature — perché ogni versione non aggiornata è un potenziale problema di sicurezza.
Un progetto Laravel o React reale può facilmente arrivare a centinaia di dipendenze tra dirette e transitive. Anche un sito molto semplice può superare diverse centinaia di pacchetti installati. Pensi che stia esagerando il conteggio? Questo piccolo sito web ha un totale di 788 dipendenze tra dirette e transitive! Molte rilasciano aggiornamenti frequenti, alcune introducono breaking changes, e nel tempo possono emergere vulnerabilità.
Il tempo che il tuo team spende ad aggiornare dipendenze, verificare compatibilità, risolvere conflitti di versione e testare che nulla si sia rotto è tempo che non spende sulle feature. Ed è un costo ricorrente: non finisce mai.
Vulnerabilità nella supply chain
Nel 2024, l'attacco a xz/liblzma ha dimostrato che un singolo maintainer compromesso può inserire una backdoor in una libreria usata da milioni di sistemi. Non è un caso isolato, ma un esempio concreto di quanto la supply chain open source possa essere un punto delicato.
Il tuo progetto dipende da centinaia di pacchetti. Tu verifichi quelli che installi direttamente. Ma verifichi anche le loro dipendenze? E le dipendenze delle dipendenze? Un attaccante non deve compromettere il pacchetto più popolare — basta una libreria di utility sepolta tre livelli sotto che nessuno guarda.
npm audit e composer audit trovano le vulnerabilità note. Quelle che non sono state ancora scoperte — o che sono state inserite intenzionalmente — passano inosservate.
Il rischio di abbandono
L'open source dipende dalla volontà di individui. Maintainer che lavorano gratis nel tempo libero, che possono stancarsi, cambiare lavoro, o semplicemente perdere interesse. Quando un pacchetto viene abbandonato, hai tre opzioni: forkarlo e mantenerlo tu (costo enorme), migrare a un'alternativa (costo significativo), o restare su una versione non mantenuta (rischio crescente). Nessuna è gratuita. E se la dipendenza critica la conosce solo una persona nel team, hai anche un bel problema di bus factor.
E non parliamo di pacchetti oscuri. Librerie molto popolari sono state abbandonate, oppure hanno cambiato maintainer nel tempo senza che la maggior parte degli utilizzatori se ne accorgesse. Il tuo package-lock.json potrebbe contenere rischi di cui non sospetti l’esistenza.
Meno è meglio: il principio della dipendenza minima
La soluzione è usare l'open source con consapevolezza, non rinunciarci.
Chiediti: mi serve davvero?
Prima di aggiungere una dipendenza, la domanda è: posso fare la stessa cosa con il linguaggio o il framework che ho già? Un pacchetto per formattare le date? Forse le API native del linguaggio bastano. Un pacchetto per validare le email? Spesso poche righe di codice ben scritte possono coprire il tuo caso d’uso senza introdurre un’ulteriore dipendenza. Un pacchetto per fare il left-pad di una stringa? Quella è una riga di codice.
Ogni dipendenza che non aggiungi è una dipendenza che non devi manutenere, aggiornare, e monitorare. Il codice più sicuro e più affidabile è quello che non esiste.
Valuta la salute del pacchetto
Se decidi che una dipendenza serve, guardane prima lo stato reale. Conta quanti maintainer ha, perché se ne dipende uno solo il rischio di abbandono è alto. Guarda quando è stato aggiornato l’ultima volta: se l’ultimo commit è di un anno fa, vale la pena fermarsi un attimo. Controlla se esiste una policy di sicurezza e chiediti quante dipendenze transitive porta con sé, perché ogni pacchetto aggiuntivo aumenta il tuo livello di esposizione.
Blocca le versioni
Non fidarti di ^ e ~ nel tuo file di dipendenze. Un minor update "compatibile" può introdurre bug o cambiamenti di comportamento. Usa lockfile (sempre), e aggiorna manualmente con test dopo ogni update.
Monitora automaticamente
Attiva Dependabot su GitHub. Non per aggiornare automaticamente — per essere informato quando escono aggiornamenti e vulnerabilità. L'aggiornamento lo fai tu, consapevolmente, dopo aver testato.
Il costo per il business
Per chi gestisce budget e roadmap, le dipendenze open source sono un costo operativo nascosto. C’è innanzitutto il tempo del team: aggiornare pacchetti, risolvere conflitti, gestire deprecation. In un progetto maturo questa attività può consumare una parte rilevante della capacità di sviluppo, anche se spesso non compare in nessun ticket visibile.
Poi c’è il rischio di incidenti. Una vulnerabilità critica in una dipendenza può costringere a un aggiornamento d’emergenza: il team lascia tutto quello che sta facendo, testa la compatibilità, deploya, e brucia un pomeriggio o una giornata intera. Quel tempo perso peggiora ancora di più le stime di sviluppo già fragili.
Infine esiste un lock-in invisibile, cioè una dipendenza crescente da scelte fatte da altri. Più dipendenze hai, più il progetto è legato a decisioni di terzi. Quando un pacchetto cambia API, depreca feature o cambia licenza, devi adattarti ai loro tempi e alle loro scelte.
La regola pratica
Per ogni dipendenza nel tuo progetto, dovresti poter rispondere a questa domanda: "Se domani questo pacchetto sparisse, quanto ci costerebbe?"
Se la risposta è “nulla, lo riscrivo in un’ora”, allora va bene averlo: ti sta davvero facendo risparmiare tempo. Se la risposta è “settimane di lavoro”, allora hai un rischio che dovresti gestire in modo attivo, con un fork interno, un piano di migrazione o almeno con una consapevolezza chiara di cosa perderesti. Se la risposta è “non lo so”, è il momento di scoprirlo prima che te lo faccia scoprire un problema in produzione.
Simone Giusti
Consulente software strategico
