Votre scanner de dépendances ne voit pas le risque qui rendra votre code orphelin
Le vrai risque de la chaîne d'approvisionnement open source n'est ni la licence ni la qualité du code. C'est le jour où un mainteneur est écarté pour des raisons qui n'ont rien à voir avec le code, et où votre entreprise hérite de l'orphelin.
Votre scanner de dépendances fait bien ce qu'on lui demande. Il lit le numéro de version, vérifie la licence, croise les CVE connues avec une base de données, et produit un rapport bien rangé. Ce rapport a un angle mort de la taille d'une personne.
Le composant tout en bas de votre pile est corrigé par quelqu'un. Parfois par une équipe, souvent par une seule personne qui s'en occupe sur son temps libre. Rien dans votre nomenclature logicielle (SBOM) n'indique qui est cette personne, de quelle juridiction elle dépend, ni ce qu'il adviendrait du code si elle était écartée du projet entre deux versions.
Ce dernier scénario n'a rien d'hypothétique. En octobre 2024, le noyau Linux a retiré une onzaine de mainteneurs liés à des entreprises russes, supprimant leurs entrées du fichier MAINTAINERS du noyau. Le commit à l'origine de cette décision ne donnait qu'une justification laconique, ces entrées ayant été retirées en raison de diverses exigences de conformité, et Linus Torvalds a publiquement soutenu la mesure, pointant la législation sur les sanctions plutôt qu'un quelconque problème de code. Le déclencheur n'était ni la qualité du code, ni un incident de sécurité, ni un conflit de gouvernance. C'était une obligation légale que le projet ne pouvait pas refuser. Le mécanisme compte plus que le titre : la conformité a dépassé le code pour atteindre directement les personnes qui le maintenaient.
L'image inversée de ce risque, c'est la porte dérobée de xz-utils, découverte en mars 2024. Un mainteneur qui avait passé environ deux ans à gagner la confiance d'un projet bénévole à bout de souffle (CVE-2024-3094) a utilisé cette position pour glisser une porte dérobée dissimulée dans une bibliothèque de compression embarquée par la plupart des distributions Linux. Dans un cas, un mainteneur de confiance est retiré par la loi ; dans l'autre, on voit ce que vaut un siège de mainteneur pour qui veut en abuser. Les deux pointent vers le même fait que votre scanner ignore : le levier appartient à celui qui détient les droits de commit, pas à la syntaxe qu'il commite.
Que se passe-t-il réellement quand un mainteneur est écarté ?
Suivez l'enchaînement. Un mainteneur possède un module. Il relit les correctifs, trie les anomalies, valide les versions pour sa portion de l'arborescence. Retirez-le, et les correctifs continuent d'arriver, mais plus personne n'a l'autorité ni le contexte pour les fusionner. Le module ne casse pas le jour du retrait. Il pourrit lentement, un correctif de sécurité non relu à la fois.
Le projet ne supporte pas ce coût. C'est vous qui le supportez. Le projet est une initiative bénévole, sans contrat, sans engagement de service, sans obligation envers vous. Quand un composant se retrouve sans propriétaire, l'entreprise qui le déploie hérite d'un passif non corrigé et non trié qu'elle n'a pas choisi et dont elle ne peut pas facilement se décharger. La neutralité de la gouvernance importe peu quand le retrait résultait d'une obligation légale plutôt que d'un choix de politique interne.
Pourquoi un scanner ne voit-il pas ce risque ?
Les règles de participation à un projet fondateur sont fixées par sa direction, à sa discrétion. Ce n'est pas un reproche : tout projet a besoin de quelqu'un pour décider qui commite. Mais cela signifie que votre exposition à cette dépendance inclut silencieusement des décisions sur lesquelles vous n'avez ni voix ni visibilité : qui est admis, qui est écarté, et sur quels motifs. Une licence ne capture pas cela. Une SBOM ne le capture pas. Un scanner encore moins.
Retirez l'habillage et il reste deux expositions familières : le risque homme-clé et le risque de gouvernance discrétionnaire, logés sous une infrastructure que vous traitez comme un actif fixe. La direction financière a déjà un vocabulaire pour cela quand ce type de risque apparaît chez un fournisseur. Il est rarement appliqué à la bibliothèque open source trois couches plus bas, parce que cette bibliothèque a des allures de physique plutôt que de relation avec des personnes qu'on peut sommer de partir.
Deux pressions convergent. Les régimes de sanctions et de contrôle des exportations, y compris le cadre européen, atteignent désormais directement les listes de mainteneurs, et leur périmètre continue de s'élargir. Dans le même temps, les dépendances les plus critiques sont souvent les moins dotées en effectifs, portées par une poignée de bénévoles, comme l'ont montré aussi bien le quasi-accident de xz-utils que la précipitation autour de Log4Shell en décembre 2021. Moins d'humains de confiance, plus de chances que l'un d'eux soit écarté par une règle que le projet ne peut pas contester, et une fenêtre plus large pendant laquelle du code non maintenu reste sans correctif. Les équipes qui s'appuient sur des agents automatisés pour récupérer et mettre à jour leurs dépendances à grande vitesse doivent traiter cela comme une contrainte de conception, pas comme un cas marginal. C'est l'un des problèmes les plus aigus de la sécurisation des systèmes agentiques.
La bonne réponse n'est pas de paniquer à propos d'un projet nommément désigné, ni de croire que vous pouvez auto-héberger l'intégralité de votre graphe de dépendances. Elle consiste à ajouter, dans votre diligence technique, une question que la plupart des équipes ne posent jamais : quel événement légal ou discrétionnaire pourrait retirer du jour au lendemain les mainteneurs de ce composant, et quel est notre plan pour le code orphelin le lendemain matin ?
Cette question trie vos dépendances rapidement. La plupart sont saines : base de mainteneurs large, plusieurs organisations impliquées, un bus factor confortable. Quelques-unes ne le sont pas : un seul mainteneur, une seule juridiction, un point de défaillance unique qu'aucun outil automatisé ne signale parce que la défaillance vit dans les personnes et le droit, pas dans la syntaxe. Ces dernières méritent un plan de secours, qu'il s'agisse de financer un second mainteneur, de figer une version connue et fiable (vendoring), ou de construire la capacité interne nécessaire pour corriger vous-même le composant si besoin.
Votre pile technique n'est pas seulement du code que vous avez importé. C'est un ensemble de relations avec des personnes qui peuvent être écartées par des forces qui n'ont rien à voir avec vous. Auditez les personnes, pas seulement les paquets.
Questions fréquentes
Une SBOM protège-t-elle contre le risque lié aux mainteneurs ou aux sanctions ?
Non. Une nomenclature logicielle (SBOM) recense les composants et versions que vous embarquez, ainsi que leurs licences et vulnérabilités connues. Elle ne dit rien sur qui maintient chaque composant, combien de personnes peuvent relire un correctif de sécurité, ni si un événement légal ou de gouvernance pourrait écarter ces personnes. C'est précisément là que vit le risque de code orphelin : une SBOM est nécessaire, mais pas suffisante.
Qu'est-ce que le risque homme-clé dans une dépendance open source ?
C'est l'exposition créée quand un composant dépend d'une seule personne, ou d'un très petit nombre, pour relire et fusionner les changements. Si cette personne part, est écartée pour des raisons de conformité, ou cesse simplement de contribuer, les correctifs continuent d'être soumis mais ne sont plus fusionnés. Le code se dégrade silencieusement, et l'entreprise qui le déploie hérite du résultat non maintenu.
Comment évaluer le risque de gouvernance d'une dépendance open source ?
Regardez au-delà de la licence et du code, vers les personnes et les règles. Vérifiez le nombre de mainteneurs actifs et le bus factor, si les contributeurs sont répartis entre plusieurs organisations et juridictions, et qui détient le pouvoir d'admettre ou d'écarter des committers. Puis demandez-vous quel événement légal ou décision de direction unique pourrait retirer la maintenance du jour au lendemain, et consignez votre plan de secours pour les composants où la réponse est inconfortable.
À lire aussi
- Sur Ubuntu 26.04 LTS, le coreutils dont dépend votre build n'est plus du GNU
- La prime de souveraineté : pourquoi les entreprises paient plus cher une IA qu'aucun gouvernement étranger ne pourra couper
- Le Secret des Affaires se Perd des Années Avant la Démission. Demandez au Poulet Faccenda.
- Security & Trust
Rédigé par un persona éditorial IA du système éditorial propriétaire d'Abyshire et relu par notre équipe.