Date de publication : 26 mai 2026
Temps de lecture : 6 min
Détectez les dépendances transitives, retracez leur parcours jusqu'à votre projet et hiérarchisez-les selon leur exposition réelle.

Le code tiers domine la plupart des codes sources, et quatre incidents récents liés à la chaîne d'approvisionnement montrent comment un seul paquet compromis peut se propager à tous les projets qui en dépendent. L'IA amplifie ce problème : des études montrent que près de la moitié du code généré par l'IA contient des vulnérabilités.
Les scanners de dépendances traditionnels, y compris l'analyseur Gemnasium de GitLab, ont été conçus pour répondre à une seule question : lesquels de mes paquets déclarés présentent des CVE connus ? Lorsque les arbres de dépendances n'étaient pas aussi profonds et que les cycles de publication n'étaient pas aussi rapides, cette approche fonctionnait.
Aujourd'hui, les équipes de sécurité applicative doivent répondre à des questions plus complexes : comment un paquet vulnérable s'est-il retrouvé dans le projet ? Qu'est-ce qui l'accompagnait ? Et quelles dépendances votre code utilise-t-il réellement ? Avec GitLab 19.0, l'analyse des dépendances basée sur une nomenclature logicielle (SBOM) est désormais en disponibilité générale pour aider à répondre à ces questions. Cette fonctionnalité recense chaque dépendance directe et transitive de votre projet et vous indique quels paquets vulnérables votre application utilise réellement.
L'analyse des dépendances basée sur les SBOM est un outil d'analyse léger qui détecte les vulnérabilités dans les bibliothèques et paquets tiers de votre projet. Il répertorie les dépendances dans une SBOM et compare ces composants à la base de données des avis de sécurité de GitLab pour signaler les problèmes connus.
GitLab affiche les résultats directement dans l'environnement de travail des équipes. Les vulnérabilités introduites par une modification apparaissent dans la merge request, afin que les équipes de développement puissent les corriger avant la mise en production. Les résultats sont également affichés dans les tableaux de bord et les rapports de vulnérabilités, ce qui permet aux équipes de sécurité de consulter les résultats de tous les projets en un seul endroit.
Rapport d'analyse des dépendances affichant le software bill of materials
L'analyseur génère à la fois une SBOM au format CycloneDX et un rapport d'analyse des dépendances. Des résultats lisibles par machine que vous pouvez utiliser dans GitLab, pour les rapports de conformité ou dans des outils plus larges de gestion de la chaîne d'approvisionnement.
L'analyse des dépendances basée sur les SBOM introduit des fonctionnalités qui vont au-delà de notre analyseur basé sur Gemnasium :
Retracez les dépendances transitives jusqu'à leur source. L'analyseur retrace les dépendances transitives, quelle que soit leur niveau d'imbrication. Lorsque l'analyseur signale un paquet vulnérable, il vous montre la chaîne qui l'a introduit dans votre projet. Si la bibliothèque-a dépend de la bibliothèque-b, qui dépend elle-même de la bibliothèque-c vulnérable, vous pouvez retracer ce chemin et savoir où intervenir.
Concentrez-vous sur les vulnérabilités que votre code utilise réellement. Toutes les dépendances incluses dans les fichiers manifestes et de build ne s'exécutent pas dans votre application. Pour les projets Java, JavaScript/TypeScript et Python, l'analyseur vérifie si votre code importe ou requiert directement des paquets vulnérables, en distinguant les dépendances accessibles de celles qui sont incluses de manière transitive mais jamais référencées par votre application. GitLab affiche le statut d'accessibilité pour chaque résultat, afin que les équipes puissent déprioritiser les vulnérabilités dans les paquets que leur code n'importe jamais et concentrer leurs efforts de correction là où l'exposition est plausible.
Recherchez en permanence de nouvelles vulnérabilités. Lancez l'analyseur lorsque de nouveaux avis de sécurité sont publiés, et pour chaque merge request et exécution de pipeline. C'est particulièrement important pour les projets dont le développement actif a ralenti mais dont le code est toujours en production.
Cette version prend en charge plus de 24 écosystèmes de paquets, et d'autres sont prévus dans les prochaines versions. L'ajout de la prise en charge de nouveaux langages et formats de fichiers est désormais plus simple, car l'analyseur analyse directement les fichiers de verrouillage et les graphes de dépendances, plutôt que de reproduire la chaîne d'outils de build de chaque gestionnaire de paquets.
Lorsqu'un fichier de verrouillage ou un graphe de dépendances pris en charge n'est pas disponible, l'analyseur se replie sur l'analyse des fichiers manifestes tels que pom.xml, requirements.txt et les fichiers de build Gradle. Cela expose les dépendances directes mais pas les dépendances transitives, de sorte que la couverture est moins complète qu'une analyse basée sur un fichier de verrouillage. Les fichiers de verrouillage restent l'approche recommandée, mais l'analyse des manifestes offre aux équipes un point de départ pour les projets qui n'en disposent pas.
À mesure que le nombre de projets augmente, la configuration manuelle des analyseurs dans chaque projet devient une charge opérationnelle significative. Des projets sont ignorés, les configurations dérivent et les audits révèlent des lacunes dont personne ne soupçonnait l'existence.
GitLab 19.0 intègre un profil de configuration de sécurité dédié à l'analyse des dépendances. Les équipes de sécurité et de plateforme configurent l'analyse une seule fois et l'appliquent à des centaines de projets, au lieu de modifier chaque pipeline manuellement.
Vous pouvez imposer ces normes de sécurité à l'aide de politiques d'exécution de scan et de politiques d'exécution de pipeline. Elles permettent aux équipes d'appliquer l'analyse des dépendances à plusieurs projets sans toucher à un seul fichier .gitlab-ci.yml. En définissant l'exigence une seule fois au niveau du groupe ou de l'instance, la politique s'applique automatiquement partout.
L'analyse des dépendances basée sur les SBOM est disponible pour les clients GitLab Ultimate. La fonctionnalité est active sur GitLab.com et déployée progressivement pour les clients GitLab Dedicated et GitLab Self-Managed selon notre cadence de publication standard.
Les équipes qui migrent depuis le scanner de dépendances Gemnasium peuvent exécuter les deux analyseurs en parallèle pendant la transition. Le guide de migration vous guide tout au long du processus, notamment pour comparer les résultats entre les deux.
Pour démarrer de zéro, suivez les instructions étape par étape de notre tutoriel de configuration. Notre documentation technique couvre la configuration, les langages pris en charge et les options avancées.
N'hésitez pas à nous faire part de vos demandes et suggestions concernant l'analyse des dépendances dans notre epic dédié à cet effet.
Cet article de blog vous a plu ? Vous avez des questions ou des retours à nous faire ? Donnez votre avis en créant un nouveau sujet sur le forum de la communauté GitLab.
Faites-nous part de vos commentaires