Les dépendances transitives, c’est-à-dire les dépendances de vos dépendances, puis leurs propres dépendances, et ainsi de suite, constituent la majorité des composants logiciels d’une application moderne. Une application de production peut avoir cinquante dépendances directes, mais ces cinquante dépendances peuvent avoir ensemble des milliers de dépendances transitives. La vulnérabilité d’une dépendance directe, sur laquelle se concentrent la plupart des équipes de sécurité, est le risque visible. La vulnérabilité d’une dépendance transitive de profondeur trois ou quatre, située à trois ou quatre niveaux des exigences directes de l’application, est le risque que la plupart des équipes de développement ne gèrent pas activement et que de nombreux outils d’SCA ne couvrent pas entièrement dans leur périmètre configuré.
Le problème de la profondeur d’exposition est le défi précis de gestion des risques. Une vulnérabilité dans une dépendance directe est gérable : la dépendance peut être identifiée, la version vulnérable déterminée et la mise à jour appliquée aux exigences directes de l’application. Une vulnérabilité dans une dépendance transitive de profondeur trois exige d’identifier que la dépendance transitive figure dans l’arbre, de déterminer lesquelles des dépendances directes ou indirectes de l’application l’incluent, de trouver pour cette dépendance transitive une voie de mise à jour acceptable pour toutes les dépendances intermédiaires entre l’application et le paquet vulnérable, et de vérifier que la mise à jour ne casse pas ces dépendances intermédiaires. C’est souvent difficile, et parfois impossible sans modifications importantes de l’arbre des dépendances.
Le cas Log4Shell en est l’illustration de référence. La vulnérabilité Log4j a touché des millions d’applications, dont la majorité n’avaient pas déclaré directement de dépendance à Log4j : elles l’utilisaient de manière transitive par l’intermédiaire de frameworks de journalisation, de serveurs d’applications et d’intergiciels qui incluaient Log4j comme dépendance transitive. De nombreuses organisations n’ont découvert qu’elles étaient touchées qu’à la publication de la CVE, en lançant une analyse complète de leurs dépendances transitives, non parce que leur gestion des dépendances directes était insuffisante, mais parce que les dépendances transitives situées à plusieurs niveaux de profondeur n’étaient pas surveillées en continu.
Pourquoi c’est important
Le risque lié aux dépendances transitives compte pour le TPRM, car les éditeurs de logiciels dont vous déployez les produits ont des arbres de dépendances transitives susceptibles de contenir des composants vulnérables qu’ils ne surveillent pas activement. Un fournisseur dont l’analyse SCA ne couvre que les dépendances directes peut produire des rapports SCA sans anomalie tout en exécutant des dépendances transitives vulnérables. Interroger le fournisseur sur la couverture des dépendances transitives est la question qui révèle si sa gestion des vulnérabilités s’étend à l’arbre complet des dépendances.
- SCA configurée pour les seules dépendances directes : profondeur transitive non entièrement couverte
- Découverte tardive des vulnérabilités transitives : elles sont trouvées grâce à des recherches externes plutôt que par la surveillance interne
- Complexité de la voie de mise à jour des dépendances transitives non évaluée
- Profondeur du SBOM : le SBOM couvre-t-il l’arbre transitif complet ou les seules dépendances directes
- Exposition de type Log4Shell : inclusion de dépendances transitives non surveillée en continu
À quoi ressemblent les bonnes pratiques
Les programmes matures de gestion du risque lié aux dépendances transitives mettent en œuvre une SCA avec une analyse en profondeur transitive complète, tiennent à jour des SBOM incluant l’arbre complet des dépendances transitives, surveillent les vulnérabilités nouvellement publiées dans l’ensemble de l’arbre des dépendances et pas seulement dans les dépendances directes, et font de la couverture des dépendances transitives une question d’évaluation des fournisseurs.
- Analyse SCA en profondeur transitive complète, non limitée aux dépendances directes
- SBOM transitif complet : toutes les dépendances à toutes les profondeurs
- Surveillance continue des vulnérabilités sur l’arbre complet des dépendances
- Évaluation de la faisabilité des mises à jour pour les vulnérabilités transitives
- Question sur la couverture transitive dans les évaluations de la sécurité logicielle des fournisseurs
Outils
SCA en profondeur complète : Snyk, Dependabot, OWASP Dependency-Check avec analyse transitive complète
Les outils d’SCA diffèrent dans leur couverture des dépendances transitives : certains n’analysent par défaut que les dépendances directes, d’autres analysent l’arbre complet des dépendances. Pour les praticiens TPRM, demander si les outils SCA d’un fournisseur analysent l’arbre complet des dépendances transitives, et jusqu’à quelle profondeur, constitue une question précise sur la couverture. Snyk et Dependabot proposent tous deux l’analyse transitive complète comme option configurable.
Exhaustivité des SBOM : Syft pour générer des SBOM transitifs complets ; Dependency-Track pour la gestion des SBOM transitifs
Les outils de génération de SBOM qui produisent l’arbre complet des dépendances transitives, et non les seules dépendances directes, fournissent l’inventaire complet des composants qu’exige l’évaluation du risque transitif. Syft peut générer des SBOM CycloneDX avec une couverture configurable de la profondeur transitive.
Enjeux de gouvernance
La difficulté de gouvernance du risque lié aux dépendances transitives tient à la complexité de la remédiation. Les vulnérabilités des dépendances transitives n’ont pas toujours de voie de mise à jour simple : mettre à jour une dépendance transitive peut obliger à attendre qu’une dépendance en amont publie une mise à jour, ou nécessiter de forcer l’arbre des dépendances d’une manière qui crée des risques de compatibilité. La solution de gouvernance consiste à hiérarchiser la remédiation des vulnérabilités transitives selon leur atteignabilité, c’est-à-dire selon que le chemin de code vulnérable est réellement exécuté par l’application.
- Configurer l’SCA pour une profondeur transitive complète, et non pour les seules dépendances directes
- Générer des SBOM transitifs complets, à tous les niveaux de dépendance
- Surveiller en continu la publication de vulnérabilités transitives
- Évaluer l’atteignabilité des vulnérabilités transitives : le code vulnérable est-il réellement appelé
- Inclure la couverture transitive dans l’évaluation du programme SCA du fournisseur
Si vous êtes une petite équipe
Lancez une analyse complète des dépendances transitives de votre application de production avec Snyk ou OWASP Dependency-Check en mode transitif. Comparez les résultats à votre dernier rapport SCA, qui ne couvrait que les dépendances directes. L’écart, c’est-à-dire les vulnérabilités trouvées dans des dépendances transitives absentes de l’analyse des dépendances directes, représente votre lacune actuelle d’exposition transitive. Pour chaque vulnérabilité critique de cet écart, évaluez si le chemin de code vulnérable est atteignable depuis votre application et hiérarchisez en conséquence.
- Lancer une analyse complète des dépendances transitives et la comparer à l’analyse limitée aux dépendances directes
- Identifier l’écart d’exposition transitive
- Évaluer l’atteignabilité des vulnérabilités transitives critiques
- Inclure la couverture transitive dans les questions d’évaluation des fournisseurs
Ce qu’il faut exiger
Demandez directement :
« Votre analyse SCA couvre-t-elle l’arbre complet de vos dépendances transitives, et pas seulement les dépendances directes, et votre SBOM inclut-il tous les composants transitifs ? Et comment avez-vous identifié la vulnérabilité Log4Shell et réagi, sachant que Log4j est généralement une dépendance transitive plutôt que directe ? »
Preuves attendues
- Confirmation d’une analyse SCA transitive complète
- SBOM transitif complet
- Chronologie de la réponse à Log4Shell comme étude de cas de vulnérabilité transitive
- Processus de surveillance des vulnérabilités transitives
Il convient d’interroger un fournisseur qui confirme sa gestion des vulnérabilités SCA sur la couverture en profondeur des dépendances transitives. L’SCA des dépendances directes est un point de départ. L’analyse transitive complète donne l’image complète. Log4Shell est le cas d’école qui permet de vérifier si cette distinction a été rendue opérationnelle.
Comment le prouver
- Dossiers des analyses SCA transitives complètes
- SBOM transitif complet
- Mise en œuvre de la surveillance des vulnérabilités transitives
- Processus d’évaluation de l’atteignabilité
À retenir
Dépendances directes : aucune vulnérabilité critique. Profondeur transitive quatre : vulnérabilité critique dans la chaîne de dépendances d’un framework de journalisation. Périmètre de l’SCA : dépendances directes. Profondeur quatre : hors périmètre. Log4Shell a atteint des millions d’applications par des dépendances transitives que leurs équipes n’avaient pas déclarées directement. L’analyse transitive complète trouve ce que l’analyse limitée aux dépendances directes manque. Les SBOM transitifs complets inventorient ce que l’analyse complète a trouvé. L’évaluation de l’atteignabilité hiérarchise ce que l’inventaire a identifié. La question « votre SCA couvre-t-elle l’arbre transitif complet ? » permet de vérifier si la couverture du programme correspond au modèle de menace.