123% de CVE signalées en plus par jour en 2026 par rapport à l'an dernier.

Dépendances

Qu'est-ce qu'un graphe de dépendances ?

Un graphe de dépendances cartographie tous les paquets dont dépend votre logiciel et le paquet qui a amené chacun d'eux. Une liste vous dit ce que contient votre logiciel. Le graphe vous dit pourquoi cela s'y trouve et ce que cela touche d'autre : c'est la question qui se pose lorsqu'une vulnérabilité tombe.

Mis à jour le

The same dependencies as a tree and as a graph As a tree, express leads to body-parser and send, and debug appears twice, once under each. As a graph, debug is a single node with an edge from body-parser and an edge from send, forming a diamond. Tree shared packages repeat express body-parser send debug debug Graph one node, two parents express body-parser send debug

Nœuds, arêtes et chemins

Dans un graphe de dépendances, chaque paquet est un nœud, et chaque relation « dépend de » est une arête d'un paquet vers un autre. Votre projet se trouve en haut. Ses dépendances directes sont à une arête, et ses dépendances transitives sont tout ce qui se trouve plus bas. Le trajet de votre projet vers un paquet est son chemin de dépendance, et un paquet peut en avoir plusieurs.

Graphe, arbre ou liste

Les mêmes dépendances peuvent être présentées de trois façons, et chacune répond à une question différente.

Vue Ce qu'elle montre Ce qu'elle perd
Liste à plat Chaque paquet une seule fois, avec sa version La raison de la présence de chaque paquet
Arbre Chaque chemin depuis votre projet, tel que l'affichent les gestionnaires de paquets Les paquets partagés se répètent : l'arbre surestime donc la taille
Graphe Chaque paquet une seule fois, avec une arête depuis chaque parent Plus difficile à lire à l'œil nu sans visualiseur

Les paquets partagés sont la raison pour laquelle les graphes comptent. Lorsque deux de vos dépendances ont besoin du même paquet, celui-ci forme un diamant : un nœud avec deux parents. Pour y corriger une vulnérabilité, il faut connaître les deux chemins, car chacun des parents peut épingler l'ancienne version.

À quoi sert un graphe de dépendances

  • Trouver le chemin de correction. Un paquet transitif vulnérable se corrige en mettant à niveau ou en forçant la version d'un élément de son chemin. Le graphe montre quelle dépendance directe faire évoluer.
  • Mesurer le rayon d'impact. Lorsqu'un avis de sécurité tombe, le graphe montre lesquels de vos dépendances directes, services et produits mènent au paquet concerné.
  • Examiner les licences. Une licence copyleft enfouie dans le graphe s'applique autant qu'une licence au sommet, et le chemin indique quelle dépendance l'a introduite.
  • Planifier les mises à niveau. Une mise à niveau majeure d'un paquet modifie tout ce qui se trouve en dessous. Le graphe montre quelle part de votre arbre bouge.
  • Repérer les concentrations de risque. Un petit paquet non maintenu par lequel passent de nombreux chemins est un point de défaillance unique.

Comment obtenir un graphe de dépendances

Depuis votre gestionnaire de paquets. Tous les gestionnaires de paquets affichent l'arbre résolu, et la plupart peuvent expliquer pourquoi un paquet donné est là. Dépendances transitives liste les commandes pour npm, pnpm, Python, Go, Rust, Maven et Gradle.

Depuis GitHub. Le graphe de dépendances, sous l'onglet Insights d'un dépôt, est un résumé des manifestes et des lockfiles du dépôt, ainsi que des dépendances soumises via l'API de soumission de dépendances. Pour les écosystèmes qui le permettent, GitHub montre le chemin transitif qui a amené chaque dépendance, et il peut exporter le graphe sous forme de SBOM.

Depuis une SBOM. CycloneDX enregistre le graphe dans une section dependencies, où chaque composant liste ce dont il dépend. SPDX utilise des relations DEPENDS_ON entre les paquets. Voici à quoi ressemble un graphe CycloneDX pour une partie d'une application Express :

"dependencies": [
  { "ref": "my-app", "dependsOn": ["express"] },
  { "ref": "express", "dependsOn": ["body-parser", "send"] },
  { "ref": "body-parser", "dependsOn": ["raw-body", "debug"] },
  { "ref": "send", "dependsOn": ["mime-types", "debug"] }
]

Ici, debug apparaît sous deux parents : c'est un diamant. De nombreuses SBOM omettent les relations et ne listent que les composants, ce qui conserve l'inventaire mais fait perdre tous les chemins.

Un graphe ne vaut que ce que vaut sa source

La plupart des graphes de dépendances sont construits à partir des manifestes et des lockfiles : ils montrent donc l'arbre prévu par le gestionnaire de paquets. Ils ne montrent pas les paquets restaurés depuis les caches CI, les outils de build installés par les étapes de configuration, ni le code récupéré par les scripts d'installation et les téléchargements, et ils ne peuvent pas dire si le build a installé exactement le lockfile. Voir pourquoi un lockfile n'est pas un enregistrement de ce qui a été livré.

Les graphes de dépendances dans CRACI

CRACI construit son graphe à partir du build lui-même. C'est un runner GitHub Actions qui enregistre chaque paquet récupéré par chaque job, à tous les niveaux de l'arbre et y compris les paquets restaurés depuis les caches CI, dans une SBOM qui indique sa propre complétude.

  • Une vue en graphe de la SBOM. La vue des dépendances montre les couches de dépendances de la SBOM dans les vues Pivot, Graph, Blob, Chord et Sunburst, avec des filtres de profondeur et de sévérité.
  • Des exports avec l'arbre complet. Les exports CycloneDX et SPDX incluent les dépendances transitives, chacune avec sa licence déclarée.
  • Les builds touchés dans le temps. Lorsqu'une nouvelle vulnérabilité tombe, l'historique des builds montre quels builds passés contenaient le paquet vulnérable, direct ou transitif.

Voir la génération de SBOM dans CRACI, ou réservez une démo pour explorer le graphe de l'un de vos propres builds.

Graphes de dépendances : questions fréquentes

Qu'est-ce qu'un graphe de dépendances ?

Un graphe de dépendances est une carte de tous les paquets dont dépend votre logiciel, avec une flèche allant de chaque paquet vers ceux dont il a besoin. Il montre non seulement ce que contient votre logiciel, mais aussi pourquoi : le chemin qui mène de votre code à chaque dépendance transitive.

Quelle est la différence entre un arbre et un graphe de dépendances ?

Un arbre montre chaque chemin séparément : un paquet requis par deux parents y apparaît donc deux fois. Un graphe montre chaque paquet une seule fois, avec une arête depuis chaque parent qui en a besoin. Les gestionnaires de paquets affichent des arbres parce qu'ils sont faciles à lire ; les outils qui analysent l'impact travaillent sur le graphe.

Une SBOM contient-elle un graphe de dépendances ?

Elle peut en contenir un. CycloneDX a une section dependencies dans laquelle chaque composant liste les composants dont il dépend, et SPDX exprime la même chose avec des relations DEPENDS_ON. De nombreuses SBOM omettent les relations et ne listent que les composants, ce qui fait perdre les chemins.

Comment voir le graphe de dépendances d'un dépôt GitHub ?

Ouvrez l'onglet Insights du dépôt et choisissez Dependency graph. GitHub le construit à partir des manifestes et des lockfiles du dépôt, ainsi que de tout ce qui est soumis via son API de soumission de dépendances, et, pour les écosystèmes qui le permettent, montre le chemin qui a amené chaque dépendance transitive.

Qu'est-ce qu'une dépendance en diamant ?

Deux de vos dépendances dépendent du même paquet : le graphe forme alors un diamant. Si elles ont besoin de versions incompatibles de ce paquet, le gestionnaire de paquets doit en installer deux copies ou échouer, et c'est l'une des raisons pour lesquelles un graphe est plus difficile à gérer qu'il n'y paraît.

Voyez le graphe de ce que votre build a récupéré

Exécutez un workflow GitHub Actions sur CRACI et explorez le graphe de dépendances de sa SBOM enregistrée, à tous les niveaux de l'arbre.

Réserver une démo