Dépendances logicielles : gérer les dépendances à grande échelle

Les dépendances logicielles permettent aux développeurs de livrer des logiciels plus rapidement en s’appuyant sur des travaux existants. Elles ont révolutionné le développement d’applications au cours des dernières décennies, mais présentent aussi des risques souvent négligés.

Quels sont les types de dépendances ?

Il existe deux types de dépendances logicielles :

• Directes : les bibliothèques ou les packages appelés directement par votre code.

• Transitives : les bibliothèques ou les packages appelés par vos dépendances. Ce sont les dépendances de vos dépendances.

Les deux types de dépendances doivent être gérés avec soin afin de maîtriser les risques associés. Les dépendances transitives ou indirectes nécessitent une attention particulière, car leur utilisation dans une application n’est pas immédiatement visible. Elles s’imbriquent dans d’autres dépendances et forment un arbre complexe, ce qui peut facilement faire passer inaperçue l’utilisation d’une bibliothèque vulnérable par votre application.

Pourquoi la gestion des dépendances est indispensable

Aux débuts des dépendances logicielles, télécharger et installer une bibliothèque nécessaire était une tâche fastidieuse. Il n’était donc pas pratique de réutiliser de petits packages. Au cours des deux dernières décennies, les gestionnaires de dépendances comme Node Package Manager (NPM) pour Node.js et Maven pour Java ont toutefois facilité l’utilisation de petits packages, même ceux qui ne comptent que quelques lignes de code. Le nombre de packages à la disposition des développeurs a depuis explosé, et les dépendances logicielles sont aujourd’hui un ingrédient essentiel des applications modernes.

En utilisant des dépendances logicielles préconstruites, les développeurs peuvent livrer des logiciels plus rapidement et raccourcir les cycles de publication. Pourtant, les dépendances présentent des risques souvent négligés. Inclure un logiciel externe comme dépendance signifie que vous comptez sur ses développeurs pour écrire, tester et maintenir correctement ce code.

Outre les vulnérabilités de sécurité susceptibles d’être présentes dans ces dépendances logicielles, celles-ci peuvent aussi devenir obsolètes, ce qui limite la qualité du logiciel qui les utilise, voire entraîne son dysfonctionnement. Ces dépendances peuvent contenir des bugs ou des problèmes de sécurité qui nuisent aux performances et au profil de risque de l’application. Enfin, elles peuvent être soumises à des licences dont le non-respect peut entraîner des conséquences juridiques ou financières.

Dans ce contexte, gérer les dépendances afin de réduire les risques associés est essentiel. Pourtant, de nombreuses organisations accordent peu d’attention à cette gestion. Quand un logiciel fonctionne correctement, elles ne voient pas pourquoi réparer ce qui n’est pas cassé. De plus, la gestion des dépendances est difficile. Les dépendances transitives peuvent comporter plusieurs liens, voire former des dépendances circulaires. La mise à jour d’une dépendance peut potentiellement briser toute la chaîne et vous plonger dans l’enfer des dépendances.

Pourquoi gérer les dépendances open source

Au début, les entreprises achetaient des packages de code auprès de fournisseurs connus et réputés. Aujourd’hui, la majorité des dépendances sont des bibliothèques tierces open source, ce qui complexifie leur gestion. Les contributeurs open source qui écrivent et maintiennent le code utilisé dans les logiciels de production sont souvent externes à votre organisation.

À l’apparition des bibliothèques open source, les développeurs copiaient souvent des lignes de code et les collaient directement dans leurs projets. Il était alors impossible de suivre les composants et de les mettre à niveau. Les méthodes plus récentes consistent à utiliser un gestionnaire de packages pour gérer les composants open source ou à encapsuler les bibliothèques open source dans des modules internes. Elles facilitent l’utilisation de code open source dans les applications. Malgré l’explosion du nombre de composants open source, les développeurs comprennent souvent mal les vulnérabilités qu’ils peuvent introduire.

En partie à cause de l’explosion massive du volume de code créé, les experts en sécurité découvrent constamment des vulnérabilités dans les composants open source. Si une personne malveillante en découvre une, elle peut s’en servir pour lancer des attaques (violation de données d’Equifax), en particulier dans des packages très populaires (Log4Shell). De plus, les licences open source fixent des conditions d’utilisation dont le non-respect peut entraîner de lourdes amendes et nuire à la réputation.

Pour toutes ces raisons, il est essentiel de mettre en place un système de gestion des dépendances open source tout au long de leur cycle de vie. Cela implique notamment de définir et faire respecter des règles encadrant la gestion des composants open source par les développeurs.

5 défis liés à la gestion des dépendances

Comme nous l’avons vu, les dépendances open source permettent aux développeurs de livrer des applications plus rapidement, mais exposent aussi les organisations à des risques de sécurité et juridiques. Leur gestion nécessite de la vigilance, en particulier pour les dépendances transitives, qui peuvent créer des couches imbriquées. L’analyse de la composition logicielle est une approche permettant de gérer et d’atténuer les risques liés aux dépendances open source.

L’analyse de la composition logicielle (SCA) est une approche de test de sécurité des applications qui permet de suivre et d’analyser les composants logiciels. La SCA regroupe des méthodes et des outils de sécurité des applications qui surveillent les logiciels afin de suivre les composants utilisés comme dépendances. Elle ne se limite pas aux composants open source, mais la croissance des dépendances open source a entraîné la multiplication des outils SCA ces dernières années.

Pour gérer efficacement les risques liés aux dépendances open source, les outils SCA doivent relever plusieurs défis majeurs :

1. Les dépendances transitives peuvent dissimuler des packages open source sous plusieurs couches, ce qui rend difficile la visibilité complète sur tous les packages open source appelés par une application. Les recherches de Snyk montrent que la grande majorité des vulnérabilités se trouvent dans ces dépendances cachées. Les développeurs peuvent donc ignorer qu’ils utilisent des packages open source vulnérables.

2. Il est important de comprendre la gestion des dépendances propre à chaque écosystème. Des facteurs comme les fichiers de verrouillage et la résolution des packages lors de l’installation influent sur l’identification des vulnérabilités. Les outils SCA doivent tenir compte de ces spécificités pour repérer avec précision les vulnérabilités pertinentes. Cela peut, par exemple, aider à détecter et à prévenir les attaques par confusion de dépendances, une méthode qui a été utilisée avec succès pour accéder aux données de Yelp, Tesla, Apple, Microsoft et d’autres entreprises, puis les exfiltrer.

3. Le nombre de vulnérabilités découvertes dans les dépendances logicielles peut se chiffrer en milliers. Les outils SCA doivent impérativement disposer d’un système permettant de hiérarchiser les efforts de détection et de correction des vulnérabilités.

4. Les outils SCA ont besoin d’une source fiable qui signale les vulnérabilités à temps pour permettre de les corriger.

5. Les outils SCA doivent évoluer assez rapidement pour suivre le rythme des développeurs. Dans le cas contraire, ces derniers risquent d’ignorer ou de contourner les contrôles de sécurité.

Comment l’outil de gestion des dépendances de Snyk réduit les risques

Les approches de sécurité traditionnelles se concentrent sur la fin du processus de développement, au lieu d’intégrer la sécurité aux workflows DevOps. Snyk Open Source fait des développeurs des acteurs clés de la sécurité de leur organisation en s’intégrant dès le départ aux workflows et aux outils existants. Les équipes sécurité et opérations gèrent et supervisent le processus, tandis que les développeurs s’appuient sur les outils Snyk pour sécuriser en continu les pipelines de développement depuis leurs outils CI/CD. Corriger les problèmes de sécurité dès la phase de développement, bien avant la mise en production du code, est de loin l’option la plus sûre et la moins coûteuse.

Snyk couvre tous les aspects de la sécurité des applications. La vue arborescente des dépendances permet d’identifier les dépendances et leurs vulnérabilités, et Snyk met automatiquement à jour les dépendances au fil de leur évolution (découvrez le fonctionnement pour Java et Python). Snyk automatise l’analyse dans l’IDE afin que les développeurs puissent détecter les problèmes, les hiérarchiser, appliquer des correctifs et fusionner les mises à jour pendant le développement. Des alertes sont automatiquement générées lorsque des fonctions vulnérables sont appelées à l’exécution. Les intégrations avec les SCM, notamment GitHub et GitLab, facilitent le déploiement de l’outil sur les projets de code nouveaux et existants et permettent de générer automatiquement des PR de correction, réduisant ainsi le temps précieux consacré au développement.

Cette approche de la sécurité centrée sur les développeurs leur permet de détecter et de corriger en temps réel les bugs dans le code et les dépendances. Les vulnérabilités sont détectées plus tôt, ce qui réduit leur impact sur le cycle de développement. Une base de données complète sur les vulnérabilités fournit des descriptions soigneusement rédigées et vérifiées. Tous les éléments de la base sont analysés et leur exactitude est contrôlée ; un score et un vecteur CVSS sont attribués à chaque vulnérabilité. Les descriptions apportent des informations sur l’exploitabilité, les licences, l’historique de sécurité et la maintenance des bibliothèques signalées.

Pearson, le plus grand groupe d’enseignement au monde, a commencé à utiliser l’analyse automatisée des dépendances de Snyk pour réduire son exposition aux risques. Une fois que les développeurs ont pu utiliser la plateforme, l’équipe DevSecOps a également voulu s’assurer qu’ils savaient résoudre rapidement les problèmes.

La fonction de correction automatisée de Snyk hiérarchise les vulnérabilités afin de réduire le nombre d’actions nécessaires aux développeurs pour les corriger. Pearson réduit ainsi son exposition aux risques liés aux dépendances obsolètes, aux vulnérabilités de sécurité récemment découvertes et aux problèmes de licences.

« Cela peut être un peu intimidant pour les équipes de se connecter à Snyk et de voir des centaines de vulnérabilités »,… « Nous les encourageons donc à examiner les corrections plutôt que les problèmes individuellement. Une seule mise à niveau de dépendance peut corriger 20 à 30 vulnérabilités. C’est plus facile à mettre en œuvre pour les équipes. »

Comment sécuriser vos dépendances logicielles

Les dépendances logicielles jouent un rôle essentiel dans le développement logiciel moderne. Elles permettent aux développeurs de réutiliser du code écrit par d’autres, pour livrer plus vite et raccourcir les cycles de développement. Leur utilisation a donc explosé, mais elles présentent des risques et des vulnérabilités que les organisations sous-estiment souvent.

Les dépendances open source sont particulièrement préoccupantes. La majorité des dépendances utilisées par les développeurs aujourd’hui sont open source ; les logiciels de production reposent donc sur des contributeurs externes pour écrire, mettre à jour et maintenir ces dépendances.

Il est donc essentiel de surveiller les dépendances de manière exhaustive, mais il est difficile de contrôler chacune des dépendances utilisées par une application, en particulier les dépendances transitives.

Snyk Open Source est un outil SCA qui détecte et surveille automatiquement les dépendances tout au long du cycle de développement. Contrairement à d’autres solutions, Snyk place les développeurs au premier plan et en fait des acteurs actifs de la sécurité des applications.

Pour en savoir plus sur les dépendances et leurs conséquences pour la sécurité des applications, consultez notre rapport The State of Open Source Security.

Merci de votre lecture et restez en sécurité.