Le « Census III of Free and Open Source Software: Application Libraries » est un immense rapport faisant le point sur la manière dont le logiciel libre est utilisé. Une publication d’autant plus importante qu’elle représente un travail de fourmi et ne survient qu’une fois toutes les quelques années. Les deux premiers rapports ont ainsi été publiés en 2020 et 2015. Depuis 2020, ils sont produits en partenariat avec le Lab for Innovation Science de l’université d’Harvard.

Le rapport constate que les logiciels libres sont devenus omniprésents. Sur les dizaines de millions de projets existants, beaucoup sont remontés jusque dans des logiciels utilisés en production et quotidiennement. Toutefois, le développement très décentralisé et distribué du logiciel libre ne permet pas de rendre compte facilement de son état de santé, sa valeur économique ou même sa sécurité. « Ce manque de compréhension est un problème critique », juge la fondation, mis en lumière par les affaires Heartbleed, Log4Shell et XZ Utils. Le fameux dessin de xkcd sur les dépendances revient régulièrement sur le devant de la scène depuis.

Les habitudes de développement, passées au crible dans le rapport, font ressortir un certain nombre de problèmes. La fondation veut faire évoluer les pratiques en braquant les projecteurs sur certains, considérés comme critiques, surtout face à la « forte dépendance à l'égard des logiciels libres […] dans les secteurs public et privé ». Car, si l’utilisation massive des logiciels libres est en soi positive, une grande partie de la responsabilité dans leur gestion est laissée aux individus et entreprises, note le rapport. La Commission européenne a d’ailleurs été précurseur en organisant « des programmes de primes aux bogues, des hackathons et des conférences » depuis 2014.

Une longue liste de constats

Plus de 12 millions d’observations ont été menées sur les bibliothèques libres utilisées dans plus de 10 000 entreprises. Il en ressort huit constats principaux, dont une augmentation continue des bibliothèques pour les produits cloud. La bibliothèque python boto3, par exemple, a fait soudainement irruption à la cinquième place des composants non npm les plus utilisés. L’API google-cloud-go est classée dans les huit premières. Aucune des deux n’apparaissait dans le Top 500 lors de la précédente édition du rapport.

Deuxième constat, la transition de Python 2 vers Python 3 continue, mais la dépendance à l’ancienne version reste forte. La bibliothèque six, qui établit une couche de compatibilité entre les deux moutures, est très utilisée, apparaissant en bonne place dans tous les classements. « Cela montre qu'en 2023, la transition de Python 2 à Python 3 pose encore des problèmes, bien que ce dernier ait été officiellement publié en 2008 », note la fondation. Elle ajoute que même si Python 2 n’est plus soutenu par ses développeurs, il compte encore 23 à 29 % d’utilisateurs, en dépit de ses failles de sécurité.

Maven, en tant que gestionnaire de paquets non-npm, continue d’être très utilisé, même si sa prévalence a diminué, de 245 des 500 paquets les plus téléchargés (toujours non-npm) à 204 entre les Census II et III. Parallèlement, le nombre de paquets NuGet a augmenté dans ce même classement (de 53 à 81), comme celui des paquets PyPi (de 82 à 101).

L’explosion du Rust

Sans surprise, le nouveau rapport constate une envolée dans l’utilisation du langage Rust, poussée par les perspectives d’une meilleure sécurité du code en mémoire. Quand les performances ne sont pas critiques et qu’il n’y a pas nécessité d’accéder au système, les solutions ne manquent pas : Go, Java, C#, JavaScript, Python ou encore Ruby. Dans le cas contraire, les alternatives sont beaucoup moins nombreuses, expliquant le succès de Rust.

Pour autant, son succès reste difficile à mesurer dans le cadre du rapport, « car le code Rust se trouve souvent dans des paquets de niveau système ». Dans les composants, sa présence est passée de 0,02 à 0,12 % en quatre ans. La fondation y voit une « augmentation drastique » (500 %) ainsi qu’un « progrès significatif vers l'utilisation de langages plus sûrs pour la mémoire dans les logiciels libres ».

Schéma normalisé de dénomination : le grand absent

Les auteurs du rapport disent avoir cherché à se préparer pour ce troisième recensement, en tenant compte des obstacles rencontrés dans les précédentes publications, dont « l'absence d'un schéma de dénomination normalisé pour les composants logiciels ». Malheureusement, les conventions de nommage pour les composants sont toujours « uniques, individualisées et incohérentes ». « L'effort nécessaire pour démêler et fusionner ces ensembles de données a considérablement ralenti l'avancement du projet », ajoute la fondation. Le problème a d’ailleurs grandi, le Census III s’appuyant sur un plus grand nombre de données que les deux premiers.

Le rapport appuie sur l’ampleur du problème, auxquels sont confrontés depuis longtemps des gouvernements et administrations, dont le NIST (National Institute for Standards and Technology) aux États-Unis et la Commission européenne. Cette carence « menace de paralyser les efforts déployés par l'industrie et les pouvoirs publics pour mieux se protéger contre les incidents liés aux logiciels », avertit la fondation.

Comment résoudre cette difficulté ? Plusieurs approches sont tentées. Les CPE (Common Platform Enumeration) sont aujourd’hui souvent utilisés et fonctionnent, dans les grandes lignes, comme les CVE pour la sécurité. La fondation observe cependant qu’ils ne sont pas une solution à long terme, surtout parce qu’ils nécessitent une autorité centrale de dénomination, qui sera forcément dépassée par une généralisation à tous les composants.

Autre possibilité, les purl, ou packages URL. Il s’agit d’une convention de nommage unique, se présentant sous la forme pkg:type/namespace/name@version?qualifiers#subpath. Type renvoie au type ou protocole du paquet, namespace à tout élément pouvant servir à identifier (groupid Maven, propriétaire d’image Docker…), name au nom du paquet, etc. Très précis, ils ne sont cependant pas utilisés systématiquement. Ils ne sont pas non plus exigés lors des signalements de failles de sécurité. Il n’y a donc pas de correspondance fiable avec les composants dans les bulletins CVE.

Le rapport mentionne, comme l’avait fait l’OpenSSF (Open Source Security Foundation) il y a un an, l’utilisation du DNS. « Le DNS est le seul système de dénomination qui a été dimensionné pour couvrir l'espace technologique mondial », ajoute la fondation Linux.

Quelle que soit la solution retenue, elle devrait être choisie rapidement, recommande le rapport. « Tant qu'il n'y en aura pas, les stratégies de sécurité des logiciels, de transparence, etc. n'auront qu'un effet limité. Les organisations resteront dans l'incapacité catégorique de communiquer entre elles à grande échelle, en particulier à l'échelle mondiale », ajoute-t-il au sujet d’une convention de dénomination des composants.

Une poignée de contributeurs

Cet autre constat est un élément central dans le nouveau recensement. Ainsi, sur les 50 premiers projets du classement non-npm, 17 % ne comptent qu’un seul développeur pour plus de 80 % des modifications. 64 % n’en comptent qu’un ou deux. Dans plus de 80 % des cas, on ne trouve qu’entre un et quatre développeurs. « Ces résultats vont à l'encontre de l'idée reçue selon laquelle des milliers ou des millions de développeurs sont responsables du développement et de la maintenance des projets de logiciels libres », pointe la fondation. Une observation faisant le distinguo entre contributions et modifications effectives.

La fondation note également que l’on retrouve souvent les mêmes noms dans de nombreux projets majeurs. Sans que les contributions soient remises en cause, cet état de fait peut « modifier les décisions politiques et les considérations sur la meilleure façon d’impliquer, de soutenir et de former la communauté ».

En outre, ces deux points braquent une lumière crue sur la sécurité des comptes associés. Selon la fondation, un grand nombre (sans plus de précision) des 500 premiers logiciels des listes (figurant en annexes) sont hébergés sur des comptes individuels. Or, pour « des raisons juridiques, administratives et de sécurité, les comptes individuels de développeurs sont moins bien protégés que les comptes organisationnels dans la majorité des cas ».

La fondation observe ainsi que l’authentification multifactorielle (MFA) n’est pas systématiquement utilisée. Ces comptes n’ont pas non plus le même niveau de granularité dans les contrôles. Résultat : « il est beaucoup plus facile d'apporter des modifications au code ». En outre, si la personne derrière le compte individuel fait une longue pause ou arrête de développer, la reprise et la gestion du code peuvent être complexes.

Autant d’éléments qui peuvent faciliter l’introduction de portes dérobées dans le code. Plus rare, la reprise d’un dépôt peut se faire par une personne malintentionnée. C’est ce qui s’est passé pour XZ Utils, un repreneur du projet ayant profité de son statut pour introduire des modifications devant aboutir à un code malveillant.

Code hérité : le constat prévisible

Enfin, dernier constat du rapport, le code hérité n’est pas moins présent dans le logiciel libre qu’ailleurs. La fondation pointe plusieurs exemples, comme minimist et yargs, pour pointer des remplacements technologiques souvent trop lents, même quand l’ancien code n’est plus entretenu.

Il ne s’agit pas toujours de mauvaise volonté ou d’une simple envie de rester dans ses habitudes. Le problème serait beaucoup plus simple si les nouveaux projets proposaient au moins toutes les fonctions des anciens, mais ce n’est jamais garanti. En outre, les API changent, réclamant d’importantes modifications pour les logiciels qui les utilisent.

Sans solution magique, la fondation recommande simplement de mieux prendre en compte le vieillissement technologique : plus une technologie est ancienne, moins elle est entretenue et plus son utilisation devient risquée.