98 % des logiciels commerciaux embarquent du code open source

Le chiffre

1 180 composants par application, 581 vulnérabilités connues. Le logiciel que vous payez n’est pas écrit par l’entreprise qui vous le vend. Enfin, pas entièrement. L’édition 2026 du rapport OSSRA a passé au crible 947 bases de code commerciales : 98 % contiennent de l’open source, ces briques gratuites écrites ailleurs et importées telles quelles.

Le rapport OSSRA 2026 de Black Duck compile des audits menés entre novembre 2024 et octobre 2025 dans 17 secteurs d’activité. Ces audits ont lieu au moment où une société en rachète une autre : on ouvre le capot pour savoir ce qu’on achète. Le communiqué du 25 février 2026 donne le reste du bilan : 87 % des bases de code contiennent au moins une vulnérabilité connue, 78 % une vulnérabilité classée à haut risque.

Concrètement, un éditeur assemble plus qu’il n’écrit

Un logiciel vendu au catalogue se construit comme un meuble : l’éditeur produit sa pièce maîtresse et visse autour des composants tout faits, récupérés dans des dépôts publics. Chiffrement, compression, lecture de fichiers, connexion réseau : ces fonctions existent déjà, en libre accès, souvent maintenues par une poignée de développeurs bénévoles. Personne ne les réécrit. Le pourcentage de 98 % ne dit donc pas que le gratuit grignote le payant : il dit que le payant est bâti dessus.

Mille cent quatre-vingts briques dans un seul produit, pour 84 499 fichiers en moyenne par base de code. La liste des dépendances est devenue plus longue que la liste des fonctionnalités.

Le graphique met les quatre grands indicateurs de l’audit sur la même échelle. L’écart entre la première barre et les trois suivantes mesure exactement le problème : l’adoption est totale, le suivi ne l’est pas.

Ce que nous calculons : une faille pour deux briques

Le rapport publie deux moyennes sans jamais les rapporter l’une à l’autre : 1 180 composants open source par application, et 581 vulnérabilités connues par base de code. Nous calculons le rapport des deux : 581 ÷ 1 180 = 0,49 vulnérabilité par composant importé, soit une faille connue pour deux briques. En reconstituant les moyennes de l’an dernier à partir des évolutions publiées (581 ÷ 2,07 = 281 vulnérabilités ; 1 180 ÷ 1,30 = 908 composants), le même rapport valait 0,31. La densité de failles par brique a donc progressé de moitié en un an.

Le détail de l’audit tient en sept lignes, dont la dernière est de nous.

Deux limites à garder en tête. Une vulnérabilité connue n’est pas une porte ouverte : la faille peut concerner une fonction que le produit n’appelle jamais. Et l’échantillon penche vers les logiciels mis en vente, puisqu’il vient d’audits de rachat.

Reste la question du financement. Le recensement Census III de la Fondation Linux, publié en décembre 2024 avec l’OpenSSF et le laboratoire d’innovation de Harvard, sert précisément à identifier les briques que tout le monde utilise sans les payer. Quelques villes commencent à en tirer les conséquences : Munich a payé six mois de salaire au mainteneur d’une bibliothèque présente dans des millions d’appareils. À l’échelle des 1 180 composants d’une application moyenne, l’effort reste anecdotique.

Article créé en collaboration avec l’IA.