Le dipendenze open source hanno un costo. Non lo vedi nell'invoice

Le dipendenze open source sono ovunque nel tuo progetto. Il tuo progetto ha 47 dipendenze dirette. Quelle 47 dipendenze hanno 847 dipendenze transitive. 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 non è smettere di usare l'open source. È usarlo con consapevolezza.

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, controlla:

• Quanti maintainer ha? Se è uno solo, il rischio di abbandono è alto.
• Quando è stato aggiornato l'ultima volta? Se l'ultimo commit è di un anno fa, stai attento.
• Ha una policy di sicurezza? Se non sai come segnalare una vulnerabilità, probabilmente non hanno un processo per gestirla.
• Quante dipendenze transitive porta? Un pacchetto che porta con sé molte altre dipendenze sta moltiplicando 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.

Tempo del team. Aggiornare dipendenze, risolvere conflitti, gestire deprecation — in un progetto maturo, questo può consumare una parte non trascurabile del tempo di sviluppo. Tempo che non appare in nessun ticket Jira ma che mangia la capacità del team.

Rischio di incidenti. Una vulnerabilità critica in una dipendenza può richiedere un aggiornamento d'emergenza. Il team lascia tutto quello che sta facendo, testa la compatibilità, deploya. Un pomeriggio bruciato, a volte un giorno intero. E quel tempo perso va ad aggravare le stime di sviluppo già precarie.

Lock-in invisibile. Più dipendenze hai, più il tuo progetto è legato a scelte di terzi. Quando un pacchetto cambia API, depreca feature, o cambia licenza, devi adattarti ai loro tempi e alle loro decisioni.

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" — va bene averlo, ti fa risparmiare tempo.

Se la risposta è "settimane di lavoro" — hai un rischio che dovresti gestire attivamente: fork interno, piano di migrazione, o almeno la consapevolezza di cosa perdi.

Se la risposta è "non lo so" — è il momento di scoprirlo. Prima che lo scopri nel modo peggiore.

Se vuoi fare un'analisi delle dipendenze del tuo progetto e capire dove si nascondono i rischi, parliamone. Un audit mirato costa poco e può evitare sorprese costose.