SovereigntyGap.
SovereigntyGap.sovereignty-gap.eu

Famille 6 · ~11 min de lecture

La fragilité du supply chain

Cas qui démontrent que des fragments critiques de l'infrastructure numérique mondiale reposent sur quelques bénévoles non rémunérés — ouvert ne signifie pas sûr ; auditable ne signifie pas audité.

Thèses illustrées 08 · 09 · 11

Des fragments critiques de l’infrastructure numérique mondiale reposent sur quelques bénévoles non rémunérés, parfois épuisés, parfois infiltrés, parfois disparus. Ouvert ne signifie pas sûr ; auditable ne signifie pas audité. Les cas qui suivent montrent que l’arithmétique du bénévolat critique rattrape régulièrement l’infrastructure mondiale, et qu’aucun investissement structurel n’a comblé ce vide.

Cette famille documente aussi, avant même l’arrivée des agents d’audit IA, l’asymétrie défensive sur laquelle repose la thèse 9 du manifeste : l’auditabilité théorique de l’open source n’a jamais produit l’audit réel à la mesure de ses usages. XZ Utils est passé inaperçu deux à trois ans dans du code public ; Heartbleed est resté caché deux ans dans OpenSSL ; Log4Shell a vécu quatre ans avant divulgation. La famille 7 documente l’amplification IA de cette asymétrie ; la présente famille en documente la prémisse — la transparence du libre cesse d’être en elle-même un acquis défensif si elle n’est pas adossée à des moyens d’audit réels.

XZ Utils — Backdoor étatique dans une bibliothèque maintenue par un seul bénévole#

Date du fait principal : découverte le 29 mars 2024 ; tentative d’infiltration sur 2-3 ans Statut : confirmé, attaque déjouée in extremis Thèses du manifeste illustrées : 7, 8, 9, 11

Le fait#

Le 29 mars 2024, Andres Freund, ingénieur de Microsoft, découvre par hasard une porte dérobée extrêmement sophistiquée dans XZ Utils, une bibliothèque de compression maintenue depuis des années par un bénévole en burnout, Lasse Collin. Un attaquant — opérant sous le pseudonyme Jia Tan, et probablement adossé à un acteur étatique vu le niveau de patience et de sophistication — avait passé près de trois ans à gagner la confiance du mainteneur original avant d’obtenir les droits de commit, puis d’introduire un backdoor dans les versions 5.6.0 et 5.6.1.

Le backdoor était conçu pour s’activer dans sshd, le démon SSH, et permettre une exécution de code à distance déclenchée par une signature cryptographique connue de l’attaquant. Il était spécialement conçu pour être quasi indétectable par les méthodes d’audit habituelles.

L’analyse des dépendances inverses a révélé que la bibliothèque XZ est utilisée par une portion considérable de l’écosystème Linux — du même ordre de grandeur que la glibc, la bibliothèque C standard. Si la porte dérobée n’avait pas été détectée à temps, elle aurait probablement été le plus grave compromis de chaîne d’approvisionnement depuis SolarWinds, affectant des millions de serveurs Linux à travers le monde.

Le contexte humain#

Lasse Collin, le mainteneur original de XZ Utils, avait publiquement exprimé sa fatigue et son surmenage sur les listes de diffusion du projet. Plusieurs personnes — dont Jia Tan — étaient venues lui « offrir leur aide » pour reprendre une partie de la maintenance. C’est précisément cette vulnérabilité humaine que l’attaquant a exploitée : l’épuisement du mainteneur unique est devenu le vecteur d’une attaque sophistiquée potentiellement étatique.

Ce qu’il démontre#

XZ Utils est probablement le cas le plus important documenté à ce jour pour le débat sur la sécurité de l’open source. Il prouve concrètement que :

  1. Le bénévolat critique est une vulnérabilité structurelle. Une bibliothèque utilisée par des dizaines de milliers de paquets reposait sur un seul bénévole épuisé, sans soutien institutionnel ni financement.
  2. L’auditabilité théorique ne garantit pas l’audit réel. Le code de XZ Utils était public depuis le début. Personne ne l’auditait suffisamment pour détecter l’infiltration sur deux ans. La découverte est due à un hasard — un ralentissement de SSH lors d’un benchmark de PostgreSQL. C’est précisément la thèse 9 du manifeste, dans sa version antérieure à l’IA : la transparence du libre n’est un acquis défensif qu’à condition que des moyens d’audit réels lui soient adossés. XZ établit ce constat sans qu’aucun agent d’IA n’entre en jeu — seule l’arithmétique des yeux humains disponibles compte, et elle ne suffit pas.
  3. L’investissement public structuré est nécessaire. Aucun mécanisme ne finançait Lasse Collin pour son travail critique. Si une fraction infime de la valeur économique adossée à XZ avait été redistribuée à sa maintenance, le mainteneur n’aurait pas été en burnout, et la porte d’entrée n’aurait pas existé.
  4. Le risque géopolitique est réel. La sophistication de l’attaque suggère un acteur étatique. Pour un projet européen utilisant XZ, cela signifie qu’un acteur hostile peut, en investissant de la patience et du temps, prendre le contrôle de composants critiques du SI.

Sources#

IngressNightmare et la retraite d’Ingress-NGINX — Le bénévolat à l’échelle planétaire#

Date des faits : vulnérabilités révélées en mars 2025 ; retraite officielle du projet annoncée le 11 novembre 2025 ; fin des patches en mars 2026 Statut : confirmé, projet en fin de vie Thèses du manifeste illustrées : 8, 9, 11, 12

Le fait#

En mars 2025, la société de sécurité Wiz révèle une série de vulnérabilités critiques baptisées IngressNightmare (CVE-2025-1974, score CVSS de 9,8 sur 10) dans Ingress-NGINX, le contrôleur d’accès le plus utilisé pour exposer les applications Kubernetes vers le monde extérieur. Selon Wiz, environ 43 % des environnements cloud étaient vulnérables, et plus de 6 500 clusters — dont des entreprises du Fortune 500 — exposaient publiquement leur composant vulnérable, permettant à un attaquant non authentifié de prendre le contrôle complet du cluster en lisant tous les secrets stockés.

Le détail glaçant n’est pas la vulnérabilité elle-même, mais ce qu’elle a révélé sur l’état du projet. Ingress-NGINX, déployé selon les estimations Datadog dans environ 50 % des environnements cloud-native, utilisé dans d’innombrables plateformes managées et infrastructures critiques, était en réalité maintenu par une à deux personnes, sur leur temps libre et sans rémunération.

Le 11 novembre 2025, le Special Interest Group Network de Kubernetes et le Security Response Committee ont annoncé officiellement la retraite du projet : la maintenance « best-effort » se poursuivra jusqu’en mars 2026, après quoi il n’y aura plus aucune nouvelle version, aucun correctif de bug, et aucun patch de sécurité. La justification est limpide : la surface d’attaque du projet est devenue trop large pour ses ressources humaines disponibles, et les efforts pour recruter des mainteneurs supplémentaires ont échoué. Un projet de remplacement nommé InGate avait été lancé ; il a lui aussi été abandonné faute de bras.

Le 29 janvier 2026, les Kubernetes Steering and Security Response Committees ont publié un second communiqué conjoint plus alarmiste, exhortant les organisations à entamer immédiatement leur migration et qualifiant le risque de « catastrophique » si les utilisateurs ignorent l’avertissement. Le 2 février 2026, quatre nouvelles vulnérabilités haute sévérité (CVE-2026-1580, CVE-2026-24512, CVE-2026-24513, CVE-2026-24514) ont été divulguées, confirmant que le projet continue d’exposer ses utilisateurs à des risques en attendant la fin de support.

Ce qu’il démontre#

Là où XZ Utils pouvait encore être classé comme un cas extrême — une attaque sophistiquée potentiellement étatique contre une bibliothèque obscure maintenue par un seul bénévole — IngressNightmare interdit cette consolation. Il n’y a même plus d’attaque sophistiquée : c’est la simple arithmétique du bénévolat critique qui rattrape une infrastructure mondiale.

Kubernetes est le standard de fait de l’orchestration de conteneurs mondiale, donné par Google à la CNCF en 2015 et adopté par plus de la moitié du Fortune 100. Ingress-NGINX en est l’une des portes d’entrée les plus communes — la pièce qui décide quel trafic externe atteint quel service interne. Et c’est cette pièce centrale du dispositif qui se révèle avoir été tenue par deux bénévoles épuisés, et qu’on met aujourd’hui à la retraite faute de trouver quiconque pour reprendre le flambeau.

Cette retraite illustre directement la thèse 12 : les fournisseurs cloud européens qui ont vendu du Kubernetes managé pendant des années ont consommé Ingress-NGINX comme un service gratuit, sans investir dans sa maintenance. Le résultat est l’effondrement programmé d’un composant qu’ils utilisaient massivement pour leurs clients.

Sources#

Heartbleed — Le précédent de 2014#

Date du fait : avril 2014 (divulgation publique de la CVE-2014-0160) Statut : historique, corrigé Thèses du manifeste illustrées : 7, 8, 9

Le fait#

En avril 2014, une vulnérabilité critique nommée Heartbleed est révélée dans OpenSSL, la bibliothèque cryptographique utilisée pour sécuriser environ deux tiers du trafic HTTPS mondial. Le bug, présent depuis 2012, permettait de lire 64 Ko de mémoire arbitraire d’un serveur à chaque requête, exposant potentiellement des clés privées, mots de passe, sessions utilisateurs.

Au moment de la découverte, le projet OpenSSL était maintenu par environ deux développeurs principaux bénévoles (« les deux Steve », Steve Marquess et Stephen Henson), assistés de quelques contributeurs occasionnels, malgré une utilisation par la quasi-totalité des serveurs web mondiaux. Le budget annuel total du projet était de l’ordre de 2 000 dollars de dons. La rémunération de mainteneurs à plein temps n’est venue qu’après la divulgation, à la suite de la création de la Core Infrastructure Initiative.

Ce qu’il démontre#

Heartbleed est le cas-école qui a fondé toute la conversation contemporaine sur la sécurité de la chaîne d’approvisionnement open source. Il a directement déclenché la création de la Core Infrastructure Initiative (Linux Foundation, 24 avril 2014) — qui a permis le financement de deux développeurs OpenSSL à plein temps — puis du Sovereign Tech Fund allemand (2022). Mais 10 ans après Heartbleed, les cas XZ Utils et IngressNightmare montrent que le problème structurel n’a pas été résolu — il a juste été déplacé vers d’autres briques tout aussi critiques et tout aussi sous-maintenues.

Sources#

  • OpenSSL, communiqué officiel (avril 2014).
  • Mozilla, ICANN, communiqués techniques.
  • Core Infrastructure Initiative, Linux Foundation.

Log4Shell — Le précédent de 2021#

Date du fait : décembre 2021 (CVE-2021-44228) Statut : historique, en remédiation continue Thèses du manifeste illustrées : 7, 8, 9

Le fait#

En décembre 2021, une vulnérabilité critique nommée Log4Shell est révélée dans Apache Log4j, la bibliothèque de journalisation Java la plus utilisée au monde. La faille permettait à un attaquant non authentifié d’exécuter du code à distance sur n’importe quel serveur Java loggant une chaîne sous contrôle de l’utilisateur. Score CVSS : 10/10. La vulnérabilité affectait potentiellement des centaines de millions d’applications Java en production, dans tous les secteurs : finance, défense, santé, industrie.

Au moment de la découverte, Log4j — un projet Apache — était maintenu par une petite équipe de bénévoles, dont l’un des leads, Volkan Yazıcı, avait publié des messages publics évoquant les difficultés du travail bénévole sur un projet d’une telle criticité. Aucun mécanisme de financement structuré n’existait pour la maintenance.

Ce qu’il démontre#

Log4Shell a montré que même une fondation établie comme l’Apache Software Foundation ne garantit pas le financement de la maintenance des projets qu’elle héberge. La fondation gère la propriété intellectuelle et la gouvernance, mais les mainteneurs restent largement bénévoles. Le coût mondial de remédiation de Log4Shell a été estimé à plusieurs milliards de dollars — somme qui, redistribuée préventivement vers la maintenance, aurait financé des dizaines de mainteneurs à temps plein pendant des décennies.

Sources#

  • Apache Log4j, advisory officiel (décembre 2021).
  • CISA, CVE-2021-44228.
  • Volkan Yazıcı, billet de blog public, Open Source can’t afford this anymore.

Copy Fail (CVE-2026-31431) — Bug logique de neuf ans dans le crypto kernel Linux#

Date du fait : disclosure 29 avril 2026 ; bug introduit en 2017 ; rapport initial 23 mars 2026 ; patch upstream 1ᵉʳ avril 2026 Statut : confirmé, exploitable à 100 %, ajouté à la liste KEV de la CISA Thèses du manifeste illustrées : 8, 9, 11

Le fait#

Le 29 avril 2026, Theori divulgue Copy Fail (CVE-2026-31431), une faille logique dans le module algif_aead du sous-système cryptographique du kernel Linux. Le défaut résulte de la composition de trois changements raisonnables introduits sur quatorze ans (authencesn 2011, AF_ALG AEAD 2015, optimisation in-place 2017). Un script Python de 732 octets suffit à un utilisateur local non privilégié pour obtenir les droits root sur Ubuntu, Amazon Linux, RHEL, SUSE, Debian, Fedora et Arch Linux — toute distribution embarquant un kernel publié entre 2017 et avril 2026. CVSS 7.8. La CISA ajoute la CVE à son catalogue Known Exploited Vulnerabilities.

Ce qu’il démontre#

Copy Fail prolonge directement la lignée XZ Utils / Heartbleed / Log4Shell / IngressNightmare, mais déplace le constat sur trois points.

  1. Le périmètre est le plus regardé qui soit. Là où Heartbleed concernait OpenSSL maintenu par deux bénévoles et où XZ Utils concernait une bibliothèque secondaire tenue par un seul mainteneur en burnout, Copy Fail touche le sous-système crypto du kernel Linux — l’une des couches les plus auditées au monde, scrutée par des équipes red team commerciales, par des chercheurs universitaires et par des agences de sécurité étatiques. Le bénévolat critique n’est pas l’explication ici. C’est l’arithmétique humaine elle-même qui ne suffit pas pour les bugs de composition entre fichiers, conventions et auteurs distincts.

  2. Neuf ans de fenêtre. Le défaut a été introduit en 2017 et n’a été détecté qu’en mars 2026. Sur cette période, des centaines de milliers de déploiements de production — des hyperscalers américains aux infrastructures critiques européennes — ont exposé un chemin d’élévation de privilèges fiable à 100 % qu’aucun audit humain ne voyait. C’est exactement la prémisse de la thèse 9 du manifeste : l’auditabilité théorique de l’open source ne produit pas l’audit réel à la mesure de ses usages.

  3. Le déclencheur de la découverte n’est pas humain. Contrairement aux quatre cas précédents de cette famille — XZ Utils découvert par hasard lors d’un benchmark, Heartbleed par le travail de Codenomicon et Google, IngressNightmare par une recherche dirigée Wiz, Log4Shell par une communication coordonnée — Copy Fail a été identifié par un outil d’analyse assisté par IA (Xint Code de Theori). C’est précisément l’inversion qu’analyse la famille 7 du présent dossier : la transparence du code, qui constituait un avantage défensif quand seuls des humains lisaient le code, devient à l’ère de l’IA un terrain où la vitesse de découverte est multipliée — pour l’attaque comme pour la défense, selon qui dispose des outils.

Pour la dimension IA défensive et la mécanique offensive de l’audit automatisé, voir famille 7 — Le tournant IA.

Sources#

→ Engagements opérationnels associés#

Les briques critiques sous-maintenues n’ont, dans les faits, qu’une seule remédiation : qu’elles soient effectivement maintenues — c’est-à-dire que leur entretien soit financé à hauteur de l’usage qui en est fait.

Catalogue complet des engagements →

Lire le manifeste →