Moviento 0deps : Dépendances locales et sécurité
Les développeurs de logiciels installent des centaines de bibliothèques externes dans la plupart des projets. Les frameworks modernes reposent sur des milliers de dépendances transitives. Cela signifie que votre application exécute du code écrit par des centaines d'inconnus.
Cet écosystème accélère le développement. Il crée également des risques massifs pour la chaîne d'approvisionnement.
Le mouvement 0deps pose une question simple : Et si votre application n'exécutait que le code que vous contrôlez réellement ?
Chaque dépendance ajoute une nouvelle surface d'attaque. Une dépendance peut :
- Introduire des failles de sécurité.
- Devenir une cible pour des attaques de la chaîne d'approvisionnement.
- Être abandonnée par son créateur.
- Modifier son API publique.
- Rompre la rétrocompatibilité.
Dans le modèle 0deps, vous déplacez toutes les dépendances nécessaires directement dans le dépôt de votre projet. Vous cessez de télécharger des paquets de manière dynamique lors de la phase de build. Tout ce qui est nécessaire pour exécuter l'application reste dans le dépôt dès l'instant où vous le clonez.
Cette approche offre :
- Des builds reproductibles.
- Une dépendance moindre vis-à-vis des registres de paquets externes.
- Des audits de sécurité centralisés.
- Des résultats prévisibles.
L'objectif n'est pas de rendre le code statique. Les implémentations et les algorithmes doivent évoluer pour corriger les bugs et rester sécurisés. L'objectif est de maintenir la stabilité du contrat public.
Chaque bibliothèque expose une interface spécifique. Par exemple :
- authenticate()
- createSession()
- verifyPasskey()
Ces fonctions forment un contrat. Le contrat reste le même, même si vous réécrivez le code sous-jacent. Vous pouvez remplacer des bibliothèques ou changer de protocoles sans casser le reste de votre application.
Lorsqu'une vulnérabilité apparaît, vous êtes généralement confronté à deux problèmes :
- Corriger le bug.
- Vérifier si la mise à jour casse votre application.
Dans une architecture 0deps, le second problème disparaît. Vous mettez à jour l'implémentation derrière l'interface. L'API publique reste identique. Votre application continue de fonctionner sans modification de code.
En isolant le code externe derrière des adaptateurs internes, vous réduisez le risque à long terme. Si une bibliothèque disparaît demain, vous n'aurez qu'à mettre à jour l'adaptateur.
Le 0deps ne s'oppose pas à l'open source. Il change la manière dont vous le consommez. Les bibliothèques deviennent des composants intégrés plutôt que des liens externes dynamiques.
Cela crée des logiciels prévisibles, résilients et faciles à maintenir. Les implémentations évoluent. Le contrat demeure.