Les bibliothèques tierces sont essentielles pour accélérer le cycle de développement des logiciels. Au lieu de coder à partir de zéro, les développeurs intègrent souvent des bibliothèques open-source à des fins diverses, que ce soit pour des raisons de rentabilité, de manque de ressources ou de flexibilité. Des référentiels tels que Maven Central et PyPI, ainsi que des outils de gestion des dépendances, simplifient ce processus et stimulent la productivité. Toutefois, une telle dépendance entraîne également des risques potentiels pour la sécurité.
La gestion des dépendances open-source d'un projet peut poser des problèmes, notamment les dépendances imbriquées (une ou plusieurs dépendances à l'intérieur d'une dépendance) et une expertise limitée en matière de gestion des dépendances. L'intégration de bibliothèques externes élargit la surface d'attaque et augmente les risques de sécurité. La découverte d'une vulnérabilité dans une bibliothèque peut compromettre tous les logiciels qui dépendent de ce composant. Il est donc essentiel d'utiliser des outils d'analyse des dépendances pour identifier et traiter les vulnérabilités connues provenant de dépendances tierces.
Réutilisation des Software et adoption de la dépendance
Les écosystèmes de distribution devenant plus accessibles, les développeurs optent pour la réutilisation des logiciels existants afin d'accélérer le développement de logiciels complexes. Toutefois, cette commodité peut entraîner des problèmes de sécurité inattendus si elle n'est pas gérée avec soin. Ces logiciels existants sont principalement distribués via l'internet sous la forme de paquets - des archives contenant des versions connues sous le nom de bibliothèques, ainsi que des métadonnées spécifiant la version, l'auteur, la licence, les références et d'autres informations pertinentes. Les logiciels d'emballage rationalisent les processus de distribution et de contrôle des versions.
Les développeurs partagent souvent leur code publiquement sous des licences open-source, ce qui permet la révision du code, la collaboration de la communauté et une intégration facile. Tout développeur peut réutiliser, modifier ou contribuer à la base de code. Les projets varient considérablement en termes de qualité, de maintenance et d'assistance. Les auteurs publient ces paquets pour les rendre plus facilement accessibles, mais l'assistance et la responsabilité dépendent de la licence.
Une fois qu'un paquet est référencé dans un autre projet, il devient une dépendance de projet, représentant une référence de paquet externe. Les dépendances créent des relations à sens unique entre les logiciels, où l'un dépend de l'autre pour fonctionner correctement. Les développeurs intègrent les dépendances dans leurs applications, les résolvent au moment de la construction et récupèrent les dépendances nécessaires.
La chaîne d'approvisionnement fait référence à tous les fournisseurs externes impliqués dans le processus, en particulier ceux qui fournissent des dépendances logicielles. Ces dernières années, la gestion de la chaîne d'approvisionnement a gagné en importance dans le développement de logiciels, les entreprises établissant des politiques englobant les exigences des fournisseurs, les documents juridiques et les contrats afin de garantir la conformité avant d'accepter un fournisseur.
Gestion de la dépendance
La gestion des dépendances peut rapidement devenir insurmontable et conduire à ce que l'on appelle "l'enfer des dépendances". Les applications modernes peuvent avoir des centaines, voire des milliers de dépendances directes, ce qui complique le suivi des vulnérabilités. Voici quelques scénarios dans lesquels la gestion d'un grand nombre de dépendances devient un véritable défi.
- Absence de révision du code : Malgré la transparence des logiciels libres, il arrive que des équipes omettent de revoir le code, ce qui donne un faux sentiment de sécurité.
- Confiance implicite : Les développeurs intègrent souvent des dépendances sans vérifier minutieusement les auteurs, en se fiant uniquement à l'inclusion dans le référentiel.
- Utilisation extensive des dépendances : Les développeurs s'appuient souvent sur des paquets, même s'ils n'ont besoin que d'une fraction de leurs fonctionnalités, ce qui entraîne un gonflement des dépendances.
- Les ruptures : La mise à jour des paquets peut s'avérer complexe et introduire des ruptures, ce qui entraîne des hésitations et des paquets obsolètes.
- Questions de responsabilité : Les normes de maintenance et d'assistance des logiciels libres sont inférieures à celles exigées pour les logiciels commerciaux, ce qui entraîne des litiges et des attentes irréalistes de la part des développeurs de projets, avec pour conséquence potentielle des paquets non sécurisés.
L'augmentation des attaques ciblant les dépendances tierces a suscité des inquiétudes quant à la sécurité des logiciels. Des incidents très médiatisés comme la vulnérabilité Log4Shell en 2021 ou la porte dérobée XZ Utils récemment en mars 2024, affectant des milliers de paquets Maven, ont souligné l'impact généralisé de ces vulnérabilités. La même année, la découverte d'un logiciel malveillant dans un paquetage NPM populaire, ua-parser-jswas, a mis en évidence les risques associés à l'utilisation de bibliothèques tierces dans les piles d'applications.
Une autre attaque notable en janvier 2024 est MavenGate, une nouvelle méthode d'attaque de la chaîne d'approvisionnement des logiciels, qui détourne les dépendances via des bibliothèques abandonnées. Une exploitation réussie de ces lacunes pourrait permettre à des acteurs malveillants de trouver des artefacts vulnérables dans les dépendances et d'injecter du code malveillant dans l'application, ou pire, de compromettre le processus de construction par le biais d'un plugin malveillant.
Avec l'augmentation de l'utilisation des bibliothèques open-source, il devient primordial de comprendre et d'atténuer ces risques. C'est pourquoi il convient d'étudier plus avant la prévalence, les types et la persistance des vulnérabilités dans les bibliothèques open-source, ainsi que leur relation avec les attributs et les validations du projet.
Sécuriser les dépendances avec OPSWAT SBOM
En réaction aux attaques contre la chaîne d'approvisionnement, les États-Unis d'Amérique ont approuvé en mai 2021 le "décret sur l'amélioration de la cybersécurité de la nation", qui définit les mesures à prendre pour améliorer les politiques relatives à la chaîne d'approvisionnement. L'une des principales exigences est de fournir un SBOM pour chaque produit.
OPSWAT Software Bill of Materials (SBOM) évolue en permanence pour répondre aux besoins croissants de développement de logiciels dans un environnement sécurisé. L'une des principales caractéristiques du SBOM d'OPSWAT est l'analyse des dépendances. Cette fonctionnalité est conçue pour améliorer la visibilité de votre base de code en identifiant les vulnérabilités dans les dépendances sur lesquelles vos projets s'appuient.
Analyse des dépendances des paquets
OPSWAT SBOM détecte automatiquement les vulnérabilités de sécurité dans les dépendances logicielles pendant le développement et les tests. Par exemple, SBOM permet aux équipes de savoir si l'application utilise une bibliothèque open-source connue pour être vulnérable. Les équipes peuvent alors prendre des mesures pour protéger l'application.
Vérifier la dépendance avec Python
Container Numérisation d'images
OPSWAT SBOM examine chaque couche d'une image de conteneur pour identifier les vulnérabilités ou les menaces, y compris les paquets du système d'exploitation (OS) et les bibliothèques logicielles dépendantes utilisées par l'application. Cette approche proactive permet de détecter et de résoudre les problèmes potentiels avant qu'ils ne se transforment en problèmes majeurs.
Vérifier la dépendance avec Alpine
Les développeurs et les équipes de sécurité ont tout intérêt à comprendre les types courants, la prévalence et la persistance des vulnérabilités liées aux dépendances, ce qui leur permet d'en évaluer la gravité et d'envisager des stratégies de remédiation.
SBOM analyse les dépendances de votre projet à la recherche de vulnérabilités connues. En cas de détection, SBOM fournit des informations détaillées, notamment les niveaux de gravité, les descriptions des vulnérabilités et les correctifs disponibles.
Un rapport détaillé peut être exporté pour que les équipes puissent en assurer le suivi :
- Nombre total de dépendances analysées
- Nombre total de vulnérabilités détectées dans toutes les dépendances
- Une série de versions numérisées
- CVE connus
- Nombre total de vulnérabilités de gravité critique, élevée, moyenne et faible
OPSWAT Le SBOM recommande aux équipes chargées de la sécurité de mettre à jour tous les paquets vulnérables avec les dernières versions corrigées des vulnérabilités. Cela permet aux équipes de remédier à la vulnérabilité des responsables des paquets ou de supprimer les paquets de l'arbre de dépendance. Cette approche proactive permet aux équipes de traiter les risques de sécurité potentiels avant qu'ils ne deviennent un problème, améliorant ainsi de manière significative la sécurité et l'intégrité de leurs projets logiciels. En outre, OPSWAT SBOM aide les organisations à rester conformes et sûres dans la chaîne d'approvisionnement des logiciels. Il est fortement recommandé aux équipes de
Cartographier les dépendances
Utiliser des outils pour identifier les dépendances existant dans l'environnement et leurs relations.
Éliminer les dépendances inutiles
Supprimer les dépendances inutiles ou non essentielles pour réduire la surface d'attaque.
Utiliser des référentiels établis
Veiller à ce que les dépendances soient obtenues auprès de sources fiables.
Analyser toutes les dépendances
Avant d'utiliser des dépendances dans un logiciel, analysez-les pour détecter les problèmes de sécurité ou de qualité.
Réflexions finales
En tirant parti d'outils d'analyse des dépendances tels que OPSWAT SBOM, vous pouvez identifier et traiter de manière proactive les vulnérabilités dans les dépendances de votre projet, en atténuant les risques de sécurité potentiels avant qu'ils ne puissent être exploités. Profitez de la puissance de l'analyse des dépendances et des SBOM pour créer des applications logicielles sûres, conformes et résilientes.
