Les entreprises gèrent mal les dépendances open source de leurs applications
La gestion des dépendances de composants open source au cœur d’applications en production est souvent négligée, selon une récente étude. Cette tâche est toutefois cruciale contre les attaques à la supply chain logicielle. Il convient de garantir l'installation des versions de composants non vulnérables.
Fin 2020, l’opération de cyberespionnage surnommée Sunburst a fait les gros titres et souligné les risques inhérents à la supply chain logicielle. Cette attaque avait permis à des pirates de s'introduire dans les systèmes d’environ 18’000 organisations en exploitant un fichier de mise à jour corrompu de la solution Orion de Solarwinds. Quelques semaines plus tard, l'éditeur Codecov révélait que son outil DevOps utilisé par des dizaines de milliers d'entreprises contenait une porte dérobée depuis des mois. Ces deux incidents largement médiatisés ne sont pas du tout des cas isolés. Et le nombre d'attaques à la supply chain logicielle augmente de façon exponentielle (+650% en une année), indique un récent rapport de l’éditeur Sonatype.
128 dépendances open source en moyenne
La gestion des risques posés par cette multitude de bouts de code disparates est un défi immense. Les applications modernes sont en effet constituées de nombreuses briques logicielles développées de façon isolée mais interdépendantes. Selon les chiffres de Sonatype, une application moderne contient en moyenne 128 dépendances open source. Un projet open source publie en moyenne une dizaine de mises à jour par année. Mais pour certains projets, il peut s'agir de 8’000 publications annuelles. Les vulnérabilités ne sont pas rares, puisque près d’un tiers des projets les plus populaires en contiennent au moins une. Plus le projet open source est populaire, plus il recèle de failles identifiées. Mais cette différence reflète surtout le fait que les chercheurs en cybersécurité se focalisent davantage sur les projets populaires, nuancent les auteurs du rapport.
Tâche chronophage et ingrate
Alors que les architectes et ingénieurs logiciels prennent des décisions au niveau macro (choix des projets open source), les développeurs doivent ensuite prendre des décisions critiques au niveau micro, expliquent les auteurs du rapport. A ce niveau, il convient de déterminer au quotidien s'il faut ou non mettre à jour les dépendances existantes lorsque de nouvelles versions sont disponibles. Faire en sorte de garder à jour toutes les bibliothèques open source qu’ils utilisent est une tâche que les développeurs savent importante. Mais ils la jugent également chronophage et ingrate.
La dernière version n’est pas forcément la meilleure
La gestion des dépendances est ainsi souvent lacunaire. En se basant sur l’étude de 100’000 applications Java et 4 millions de migrations de composants, les chercheurs de Sonatype ont constaté que seul un quart des bibliothèques utilisées dans les applications en production sont activement gérées. En outre, les décisions de migration de composants ne sont la plupart du temps pas optimales. En cause? Bien souvent, les développeurs ne parviennent simplement pas à identifier la meilleure version de composant pour une mise à niveau. Et ceux qui se contentent d’installer la dernière version sans se poser de question ne sont pas dans le juste, prévient Sonatype. Car d'après son analyse, la meilleure mouture précède en moyenne de 2,7 versions la mise à jour la plus récente d’un composant. Il est ainsi fortement déconseillé de faire appel à des outils de mise à jour automatique.
Pour réduire les risques liés à des failles dans des dépendances open source, les auteurs de la recherche conseillent en particulier d’agir au niveau macro. Notamment en standardisant les critères de sélection de projets, afin d’implémenter uniquement ceux susceptibles de fournir un accès fiable aux nouvelles versions des composants.
