Quand une personne maintient une brique critique : le risque silencieux de l’Open Source

Introduction : « sudo » comme électrochoc

Un simple fait suffit à déclencher la réflexion : sudo, commande incontournable sur Linux/Unix, est maintenu depuis plus de 30 ans par Todd C. Miller, qui a récemment exprimé le besoin de sponsoring pour continuer la maintenance et le développement.

C’est un signal très fort, car dans la réalité, une partie énorme du numérique mondial repose sur des projets extrêmement critiques, mais maintenus par :

• une seule personne,
• ou une petite poignée de mainteneurs,
• souvent sans ressources comparables à l’importance du logiciel.

C’est ce qu’on appelle parfois le bus factor : si une personne clé s’arrête, combien de temps le projet tient ?

1. État de l’art : comment mesurer la criticité d’un projet open source ?

Avant de lister des exemples, il faut comprendre un point : « critique » ne veut pas dire « connu du grand public ».
Un projet peut être invisible, mais être une dépendance partout.

1.1 La Criticality Score (OpenSSF)

La Linux Foundation / OpenSSF propose une approche appelée Criticality Score : elle estime l’importance d’un projet en s’appuyant sur des signaux (activité, nombre d’utilisateurs, dépendances, etc.).

Objectif : aider à repérer les projets dont la chute aurait un impact massif.

1.2 Les baselines de sécurité (OpenSSF OSPS Baseline)

OpenSSF propose aussi une baseline de sécurité (contrôles minimaux : gestion des releases, MFA, vuln disclosure, CI, etc.).

Le sujet est simple : la sécurité d’un projet dépend aussi de sa capacité humaine à maintenir ces pratiques.

2. Exemples concrets (Linux, DevOps, Python) maintenus par une personne ou une petite communauté

Exemple 1 : sudo (Linux / sécurité / privilèges)

• Pourquoi c’est critique ?
  Gestion d’élévation de privilèges : utilisé quotidiennement sur serveurs, postes, scripts d’administration.
• Signal récent : le mainteneur historique demande du sponsoring pour soutenir la maintenance.
• Risque si ça ralentit : moins de correctifs, backlog sécurité, pression sur distributions, forks non coordonnés.

Exemple 2 : curl (réseau / DevOps / CI/CD)

• Pourquoi c’est critique ?
  Transferts HTTP(S) / API : présent dans scripts, images Docker, pipelines CI, systèmes embarqués, etc.
• Gouvernance : le projet se décrit comme poussé par Daniel Stenberg, « driving force », modèle type BDFL.
• Signal récent (qualité de contributions) : le projet a été impacté par une vague de rapports « AI slop », au point de revoir l’organisation de certains processus.
• Risque : surcharge mainteneur = fatigue + tri des issues au lieu d’amélioration sécurité/qualité.

Exemple 3 : zlib (compression partout)

• Pourquoi c’est critique ?
  Compression DEFLATE : dépendances transverses (OS, libs, formats…).
• Maintenance : zlib indique être écrit par Gailly/Adler et le site est maintenu par Mark Adler ; les releases existent mais la maintenance reste concentrée.
• Risque : la chaîne logicielle mondiale hérite des ralentissements (patchs, CVE, compat…).

Exemple 4 : BusyBox (embedded Linux / systèmes minimaux)

• Pourquoi c’est critique ?
  « couteau suisse » d’embedded Linux : routeurs, IoT, systèmes minimaux.
• Maintien : BusyBox indique explicitement être maintenu par Denys Vlasenko.
• Risque : vulnérabilités et retards touchent tout l’écosystème embarqué (souvent déjà difficile à patcher).

Exemple 5 : ripgrep (Linux/Dev productivity) et fzf (CLI productivity)

• Pourquoi c’est critique ?
  outils « petits » mais omniprésents dans workflows développeurs, SRE, DevOps.
• Références : repos principaux (ripgrep par BurntSushi, fzf par junegunn).
• Risque : moins “infrastructure mondiale”, mais impact massif sur productivité, scripts, environnements standards, distributions.

Remarque importante : certains projets démarrent « solo » puis s’ouvrent. L’idée n’est pas de dire « il n’y a qu’une personne », mais de montrer que la charge réelle repose souvent sur très peu de mainteneurs.

3. Que peut-il se passer si un projet critique « tombe » ou ralentit ?

Scénario 1 : Ralentissement progressif (le plus fréquent)

• PR et issues s’accumulent
• releases plus rares
• correctifs sécurité plus lents
  
  Conséquence : les distributions “backportent” plus, mais la dette technique augmente.

Scénario 2 : Fork communautaire

La communauté reprend :

• il faut reconstruire gouvernance + CI + confiance
• risque de fragmentation (plusieurs forks, compat brisée)

Scénario 3 : Reprise par une entreprise ou une fondation

Ça peut stabiliser (financement, process), mais peut aussi :

• créer des divergences d’objectifs
• ajouter de la bureaucratie
• changer la direction du projet

Scénario 4 : Compromission (supply chain)

Un projet peu maintenu peut être une cible :
Si la chaîne de publication, les droits, ou la CI sont fragiles, un attaquant peut viser la distribution des releases.

4. Pourquoi le modèle actuel est fragile ?

Parce qu’on a un paradoxe :

Plus un projet devient indispensable, plus il devient invisible donc moins il reçoit naturellement du soutien.

Et pourtant, ces projets supportent :

• les demandes entreprises,
• les exigences sécurité,
• la pression des CVE,
• la qualité de contribution (parfois faible),
• la doc, la compat, les releases…

5. Que faire concrètement : pistes de réflexion

Pour les entreprises / DSI / RSSI

• financer les projets critiques (sponsoring direct ou via fondations)
• contribuer au maintien (tests, CI, docs, tri issues), pas uniquement au “feature”
• auditer les dépendances critiques (inventaire + criticité + plan de continuité)
• exiger MFA, SBOM, process de release (quand c’est applicable)

Pour les ingénieurs / DevOps / SRE

• contribuer : doc, reproductions de bugs, tests
• éviter la “pollution” d’issues (rapports faibles, non vérifiés)
• sponsoriser (même petit) les outils utilisés quotidiennement

Pour les formateurs et étudiants

Transformer ce sujet en pédagogie :

• TP : “cartographier les dépendances d’un projet” (pip/npm/apt + scoring)
• TP : “améliorer la doc / tests” d’un outil réel (PR simple mais utile)
• module : “supply chain security” et bonnes pratiques OpenSSF

Conclusion :

L’histoire récente autour de sudo nous rappelle quelque chose de fondamental :
le numérique mondial dépend aussi… de l’énergie humaine de quelques mainteneurs.

Soutenir l’open source critique, ce n’est pas seulement “être sympa”.
C’est une stratégie de résilience, de sécurité et de souveraineté numérique.