Ce que coûte vraiment une dépendance
Elle est gratuite au moment où on l'ajoute. Le prix est payé plus tard, par quelqu'un d'autre, et il n'est pas libellé en euros.
Ajouter une dépendance prend trente secondes et ne coûte rien. C’est exactement ce qui rend la décision impossible à instruire : il n’y a pas de moment où quelqu’un doit la justifier.
Trois incidents suffisent à décrire ce qu’on achète réellement.
Mars 2016 : onze lignes
Le 22 mars 2016, l’auteur d’un paquet npm nommé left-pad le retire du registre à la suite
d’un différend. Le paquet fait onze lignes de JavaScript. Il ajoute des espaces devant une
chaîne de caractères.
Des milliers de projets cessent de se construire dans l’heure, dont Babel, Webpack et React, c’est-à-dire l’outillage de base d’une grande partie du web. npm restaure manuellement la version deux heures plus tard, puis change sa politique : un paquet publié depuis plus de vingt-quatre heures et dont dépend un autre projet ne peut plus être retiré.
Ce que l’incident montre n’est pas la fragilité de onze lignes. C’est que personne, dans aucune de ces organisations, ne savait qu’elles en dépendaient.
Décembre 2021 : la bibliothèque que tout le monde utilise
Log4Shell, référencée CVE-2021-44228, touche une bibliothèque de journalisation Java présente à peu près partout. Une bibliothèque de journalisation. Le composant le plus ennuyeux et le plus invisible d’une application.
La difficulté de la remédiation n’a pas été de corriger le code : le correctif est sorti vite. Elle a été de répondre à la question « où l’avons-nous ». Une dépendance transitive de dépendance transitive n’apparaît sur aucune liste que quelqu’un tient à jour.
Mars 2024 : la patience
La porte dérobée découverte dans XZ Utils, CVE-2024-3094, n’est pas un accident technique. Elle est l’aboutissement d’une campagne d’ingénierie sociale menée sur plusieurs années : contribuer réellement, devenir utile, gagner la confiance du mainteneur épuisé, obtenir les droits, puis introduire le code.
Elle a été découverte par hasard, par un ingénieur qui trouvait qu’une commande mettait un demi-seconde de trop à répondre.
Ce troisième cas est le plus instructif, parce qu’il déplace la question. Le risque n’est pas seulement dans le code de la dépendance. Il est dans qui a le droit de le modifier, et dans l’état de fatigue de cette personne.
Ce qu’on achète réellement
| Ce qu’on croit acheter | Ce qu’on achète aussi |
|---|---|
| une fonctionnalité | la disponibilité future du registre |
| du temps gagné | la santé et la motivation d’un mainteneur qu’on ne paie pas |
| du code testé | tous les choix de sécurité de ce mainteneur |
| une brique | l’arbre entier de ses propres dépendances |
Aucun de ces quatre postes n’apparaît dans la décision, parce que la décision n’a pas lieu.
L’objection, et elle est bonne
« Réécrire soi-même est bien pire. » Oui. Une organisation qui réimplémente sa cryptographie produit des failles plus graves que toutes celles citées ci-dessus. L’argument n’est pas de tout écrire soi-même : c’est de compter.
Une dépendance qui remplace six mois de travail est un excellent achat, même avec ses risques. Une dépendance qui remplace onze lignes triviales est un mauvais achat, parce qu’elle apporte tout le risque pour presque aucune valeur. La différence n’est pas philosophique, elle est arithmétique, et personne ne fait le calcul.
Trois questions, avant d’ajouter
- Combien de temps me faudrait-il pour l’écrire ? Si la réponse est moins d’une journée, la dépendance coûte plus cher qu’elle ne rapporte.
- Qui la maintient, et est-ce que je le rémunère ? Si la réponse est une personne seule et non, ce n’est pas un fournisseur. C’est un bénévole dont l’organisation dépend.
- Combien de dépendances arrivent avec elle ? Le nombre est presque toujours plus grand que l’estimation, et c’est le seul chiffre qui compte vraiment.
La bonne pratique n’est pas de refuser les dépendances. C’est d’arrêter de faire semblant qu’elles sont gratuites.