Movimento 0deps: Dipendenze locali e contratti immutabili
Gli sviluppatori software spesso installano centinaia di librerie esterne. I framework moderni si affidano a migliaia di dipendenze transitive. Ciò significa che la tua applicazione esegue codice scritto da sconosciuti.
Questo crea un rischio per la supply chain del software.
Ogni dipendenza aumenta la tua superficie di attacco. Può:
- Introdurre vulnerabilità di sicurezza.
- Diventare un bersaglio per attacchi alla supply chain.
- Essere abbandonata dai manutentori.
- Cambiare la propria API pubblica.
- Rompere la retrocompatibilità.
Il movimento 0deps pone una domanda semplice: cosa succederebbe se la tua applicazione si affidasse solo a codice che controlli direttamente?
Nel modello 0deps, incorpori le dipendenze necessarie direttamente nel repository del tuo progetto. Smetti di scaricarle dinamicamente durante le build. Tutto ciò che è necessario per eseguire l'applicazione rimane nel repository fin dall'inizio.
Questo approccio garantisce:
- Build riproducibili.
- Minore dipendenza dai registry esterni.
- Audit di sicurezza centralizzati.
- Maggiore prevedibilità.
Il principio fondamentale non è mantenere il codice statico. Le implementazioni e gli algoritmi devono evolversi per correggere bug e migliorare la sicurezza. Ciò che rimane stabile è il contratto pubblico.
Ogni libreria espone un'interfaccia progettata con cura. Alcuni esempi includono:
- authenticate()
- createSession()
- verifyPasskey()
Queste funzioni definiscono un contratto. Il contratto non cambia mai. Puoi riscrivere il codice sottostante o sostituire interamente la libreria. Il resto della tua applicazione non noterà alcun cambiamento.
Quando appare una vulnerabilità, di solito ci si trova di fronte a due problemi:
- Correggere la falla.
- Verificare se l'aggiornamento rompe l'applicazione.
In un'architettura 0deps, il secondo problema scompare. Aggiorni l'implementazione interna mentre l'API pubblica rimane la stessa. La tua applicazione continua a funzionare senza modifiche al codice.
Isoli le integrazioni esterne utilizzando un adapter interno: Application -> Public Interface -> Adapter -> Implementation
Se una libreria dovesse scomparire domani, dovrai cambiare solo l'adapter. Nessun'altra parte della tua applicazione si romperà.
0deps non rende il software perfetto. Riduce i rischi della supply chain. Previene problemi come pacchetti malevoli, compromissioni dei registry e dependency confusion.
I progetti durano decenni. Librerie e framework cambiano. Con 0deps, la tua applicazione continuerà a utilizzare gli stessi contratti stabili, indipendentemente da come evolve l'ecosistema.