Connexion
Abonnez-vous

La fondation Linux pointe les plus gros problèmes dans l’utilisation du logiciel libre

Une poignée d'élus

La fondation Linux pointe les plus gros problèmes dans l’utilisation du logiciel libre

Long Ma pour Unsplash

La Linux Foundation a publié un rapport conséquent sur l’état de l’utilisation du logiciel libre dans les applications en production. Une prévalence importante, des développeurs loyaux, mais des pratiques de sécurité qui pourraient être améliorées.

Le 05 décembre 2024 à 11h39

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.

Commentaires (11)

votre avatar
Maven, en tant que gestionnaire de paquets non-npm.
Ca me fait bizarre cette formulation. C'est même la première fois que je la vois. On a l'impression que npm est le seul gestionnaire de paquet et qu'il faille donc préciser quand ce n'est pas un paquet npm. Pourtant, il existe de très nombreux gestionnaires de paquets, npm est loin d'être le seul.

Est-ce parce que dans le TOP500 se sont les paquets issus de npm qui prédomine ?

Parce que rappelons que les gestionnaires de paquets sont souvent liés à un langage :
- npm pour javascript/typescript
- nuget pour .Net (C#, VB.Net, F#)
- maven pour Java
- cargo pour Rust
- etc.

Après, un gestionnaire de paquets n'est pas forcément cloisonné à un langage particulier (nuget permet d'installer des paquets JS par exemple), mais souvent la plupart des paquets sont axés autour d'un langage fédérateur.

Et je n'ai jamais vu npm utilisé pour autre chose que du Javascript (ce qui ne veut pas pour autant dire que cela n'existe pas).
votre avatar
Je me répond. Cette formulation provient du rapport en question.
The prevalence of small packages in the JavaScript npm package system caused the dependency calculations to crowd out non-JavaScript packages. To try to re-capture these crowded-out packages, we created two separate sets of results - one for npm-hosted packages only, and one for non-npm-hosted packages.
votre avatar
Pensée aux outils gnu trop souvent oubliés. Aujourd'hui les serveurs x86 sont presque tous des linux, avec windows server désormais réduit aux AD et à outlook (et encore, maintenant c'est essentiellement du azure). Les serveurs linux utilisent quasiment exclusivement des distrib qui embarquent la glibc et les utilitaires gnu.

À la limite je verserai une larme pour freebsd mais pas pour les unix un peu trop propriétaires type solaris/hpux et encore moins pour les windows servers qui ont toujours été sous-optimisés (pas de cli, gpu obligatoire), en plus d'être une plaie à administrer (:byebye: IIS, le service dns, le service pop/smtp, la gestion des logs...).
votre avatar
+1 mais par contre solaris ou aix a administrer c'est cool même si proprio.
Ca va faire longtemps que je n'en ais plus sous la main.
votre avatar
pas de cli dans Windows Server ? T'as pas du essayer d'en utiliser un du coup. Le coup du GPU pareil, ça marche sans.
votre avatar
Oui enfin c'est relativement récent
votre avatar
Chacun ses habitudes. Ici Windows prédomine toujours, et l'administration en cli est totalement possible, même carrément fortement suggérée. Ou administration centralisée. Et aucun GPU obligatoire (gros fan de Windows server core).

Après, c'est pas toujours facile, car beaucoup d'outils sont très orientés Unix, donc les faire marcher sous Windows parfois c'est galère (genre avec les chemins de fichier ou la gestion des droits).
votre avatar
Ah la gestion des logs sous WS, le truc à rendre fou... Et qui installe encore IIS ? Je veux dire c'est vraiment le pire choix en terme de serveur Web...
votre avatar
Et oui on ne s'en rappelle plus mais au début des années 2000, IIS avait quand même une certaine part de marché (pas au dessus d'apache, faut pas déconner non plus) mais il était très courant de trouver des tutos qui couvraient les 2 services voire qui ne couvrait que IIS.
votre avatar
oui, y'a bientot 25 ans :D
votre avatar
bah quoi, il y a 40a le seul serveur web disponible était httpd au CERN.... Je l'ai utilisé briévement en 90 :reflechis:

La fondation Linux pointe les plus gros problèmes dans l’utilisation du logiciel libre

  • Une longue liste de constats

  • L’explosion du Rust

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

  • Une poignée de contributeurs

  • Code hérité : le constat prévisible

Fermer