Un code source public rend-il un logiciel plus facile à pirater ?

Vérification

Vous hésitez à installer une application dont le code source est public. L’intuition semble imparable : si n’importe qui peut lire le code, les attaquants le lisent aussi. Les délais de correction des failles racontent autre chose, et ils désignent un point faible ailleurs.

Ce que disent les délais de correction

Un seul jeu de données compare les deux modèles avec la même méthode : celui de l’équipe Project Zero de Google, qui laisse 90 jours à l’éditeur pour corriger. Ses mesures publiées en 2022 portent sur 346 failles signalées entre janvier 2019 et décembre 2021, corrigées en 61 jours de moyenne générale. Nous croisons ces moyennes avec le modèle de développement de chaque produit.

La lecture tient en une ligne : le noyau Linux referme un signalement en 25 jours, Oracle en 109.

Nous en tirons un calcul que la source ne fait pas. En pondérant chaque moyenne par le nombre de failles suivies, les quatre éditeurs au code fermé du panel corrigent en 76 jours sur 190 signalements, contre 31 jours pour les deux projets ouverts sur 35 signalements : un rapport de 2,5. Google est écarté du calcul, son portefeuille mêlant les deux modèles. L’échantillon reste petit et déséquilibré : Oracle n’y pèse que 7 failles. Nous rapportons l’écart, pas une loi générale.

Le point faible tient à qui entretient la brique

Mars 2024 a fourni le cas d’école. La chronologie de référence de l’affaire xz Utils montre qu’un contributeur inconnu a envoyé son premier correctif le 29 octobre 2021, a été présenté comme co-mainteneur le 29 juin 2022, puis a glissé une porte dérobée dans la version 5.6.0 publiée le 24 février 2024. L’ingénieur Andres Freund l’a repérée le 28 mars, 33 jours plus tard (CVE-2024-3094). L’opération a prospéré sur un projet critique tenu par un mainteneur unique, pressé publiquement entre avril et juin 2022 par des comptes créés pour l’occasion.

Log4Shell avait montré l’autre versant. L’alerte du CERT-FR, publiée le 10 décembre 2021 par l’ANSSI, part de la faille CVE-2021-44228 dans la bibliothèque Java log4j, en recense cinq au total et recommande d’aller jusqu’à la version 2.17.1 pour Java 8. Le code ouvert a permis de comprendre et de publier le correctif en quelques jours. Il a aussi fallu quatre versions successives pour refermer proprement le dossier.

Le recensement Census III, publié le 4 décembre 2024 par l’OpenSSF et la Fondation Linux, s’appuie sur plus de 12 millions d’observations de bibliothèques libres en production dans plus de dix mille entreprises. Deux constats en ressortent : les composants libres les plus utilisés reposent souvent sur une poignée de contributeurs, et les versions anciennes persistent. Financer directement cet entretien est possible, comme l’a fait Munich avec libexpat.

Ce que ça change pour vous, concrètement

Ce code libre est déjà chez vous. L’audit OSSRA 2026 de Black Duck, mené sur 947 bases de code, y trouve de l’open source dans 98 % des cas, au moins une vulnérabilité dans 87 % et des composants vieux d’au moins quatre ans dans 92 %. Le chiffre qui compte n’est donc pas le nombre de failles connues : c’est la part de logiciels qui ne reçoivent plus de mise à jour.

Trois gestes en découlent. Installer les mises à jour sans les repousser : l’écart mesuré plus haut ne vaut que si le correctif arrive jusqu’à votre machine. Regarder la date de dernière publication d’une application et le nombre de personnes qui la maintiennent. Suivre les alertes du CERT-FR quand un composant très répandu est touché. Le raisonnement vaut aussi pour les modèles d’IA ouverts que l’on fait tourner chez soi.

L’ouverture du code n’est ni un bouclier ni une porte laissée entrouverte. Elle rend l’audit possible : encore faut-il que quelqu’un soit payé pour le faire.

Article créé en collaboration avec l’IA.