Évaluation des vulnérabilités : VulnScout ou Dependency-Track ?

Les systèmes logiciels complexes peuvent contenir des centaines, voire des milliers de vulnérabilités. Dans de tels contextes, il est crucial d’en avoir conscience, de les surveiller et de les évaluer dans les produits. En Europe, le Cyber Resilience Act (https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act) les rend obligatoires pour les produits incluant des éléments numériques. Des exigences similaires existent dans d’autres régions et secteurs via différentes réglementations et normes. Dans cet article, nous comparons deux outils : VulnScout de Savoir-faire Linux et Dependency-Track de l’OWASP.

La distinction clé ne réside pas simplement dans le fait que VulnScout est plus léger à exécuter. VulnScout est avant tout une plateforme d’évaluation des vulnérabilités native au build, centrée sur les artefacts, particulièrement adaptée aux workflows Embedded Linux et aux produits basés sur Yocto. Dependency-Track, quant à lui, est plutôt une plateforme centralisée, fonctionnant en continu, dédiée à l’inventaire et à la gouvernance de la chaîne logistique logicielle. Ce sont des modèles opérationnels différents, qui résolvent des problèmes distincts.

Avant publication, une note sur la version est importante. Dependency-Track 5.0 est devenu disponible le 9 juin 2026, quelques jours seulement avant la rédaction de cet article. Toutes les captures d’écran ci-dessous proviennent de Dependency-Track 4.14, la version utilisée lors des tests pratiques. Cependant, la comparaison écrite a été vérifiée par rapport à la version 5.0 de Dependency-Track. Cet article mentionne explicitement lorsque une nouvelle fonctionnalité est pertinente pour la comparaison.

Philosophies de conception

Les deux outils suivent des modèles opposés. Dependency-Track s’exécute comme un serveur partagé dans l’infrastructure d’une entreprise, où de nombreux utilisateurs travaillent au même endroit et où de nombreux projets sont suivis à partir d’une seule instance, avec un état d’évaluation stocké dans une base de données centrale. VulnScout, en revanche, s’exécute localement, par projet, sur la machine d’un développeur.

Cette philosophie de conception permet d’exporter l’évaluation sous forme de fichiers OpenVEX ou JSON et de les commiter aux côtés du code source. De plus, l’évaluation des vulnérabilités est versionnée dans le dépôt lui-même. Elle évolue avec le code, suit les branches et les versions, et peut être révisée, partagée et reproduite via le même workflow Git que le reste du projet.

On observe cette différence dès la configuration . Avec VulnScout, il suffit de cloner le dépôt, d’exécuter ./vulnscout --serve, et de démarrer en quelques secondes. Dependency-Track, en revanche, nécessite une pile de services en cours d’exécution. Lors de nos tests, le premier cycle complet de synchronisation et d’analyse a pris environ 1h30 avant que la plateforme ne soit pleinement utilisable pour l’analyse. Ce temps dépend de la version, des ressources de l’hôte et des conditions réseau.

En raison de cela, le style de déploiement influence souvent le choix. Pour les petits ou moyens projets avec des vérifications occasionnelles, VulnScout est souvent suffisant. Pour les projets open source, l’utilisation locale aide les contributeurs à reproduire l’intégralité du workflow. En revanche, si votre entreprise suit de nombreux produits fermés de grande taille, Dependency-Track est généralement plus adapté.

Comparaison des fonctionnalités

Formats d’entrée SBOM acceptés

Dependency-Track a autrefois pris en charge l’import SPDX2, mais cette fonctionnalité a été retirée (https://github.com/DependencyTrack/dependency-track/discussions/1222). L’équipe discute désormais du support de SPDX3 (https://github.com/DependencyTrack/dependency-track/issues/1746). Pour l’instant, il n’accepte que les fichiers CycloneDX SBOM et CycloneDX VEX.

Il n’a jamais pris en charge le format OpenVEX (https://github.com/DependencyTrack/dependency-track/issues/4862#issuecomment-2820847602).

Cette limitation est importante pour les équipes utilisant des systèmes de build qui génèrent par défaut des SBOM au format SPDX. Yocto en est un exemple : il peut exporter des fichiers SPDX2 et SPDX3, selon la version. IDe plus, Yocto stocke les données de vulnérabilité dans des fichiers JSON personnalisés cve-check ou sbom-cve-check. VulnScout, en revanche, peut consommer directement : SPDX 2.3 (JSON et données tag-value), SPDX 3.0, Archives SPDX Yocto, Yocto cve-check or sbom-cve-check JSON, CycloneDX, OpenVEX, et Grype JSON natif. Dependency-Track,en revanche, nécessite toujours CycloneDX pour le téléchargement des SBOM.

Il existe des solutions de contournement pour Dependency-Track, mais chacune a ses compromis :

• Certains convertisseurs transforment SPDX en CycloneDX, mais ils suppriment souvent des métadonnées utiles.
• iris-GmbH maintient meta-cyclonedx pour exporter des fichiers CycloneDX depuis Yocto. Cependant, cette sortie contient moins de données que les fichiers SPDX natifs de Yocto. Par exemple, elle n’exporte pas la liste des fichiers compilés, utile pour filtrer de nombreuses CVEs du noyau Linux https://github.com/iris-GmbH/meta-cyclonedx/issues/53).

Dependency-track

En comparaison, VulnScout fonctionne avec un ensemble beaucoup plus large de formats. Il peut importer et exporter : SPDX2 (fichiers JSON uniques et archives Yocto Scarthgap), SPDX3, CycloneDX, et OpenVEX. Il peut également importer : Grype, Yocto cve-check, and Yocto VEX. Ainsi, les équipes peuvent connecter VulnScout aux artefacts de build avec peu de travail supplémentaire, y compris ceux produits par Yocto. Surtout, VulnScout ne force pas un projet Yocto à adapter ses sorties de build à l’outil d’évaluation : il comprend déjà les preuves que Yocto produit.

Intégration avec les systèmes de build (exemple Yocto)

La couche meta-vulnscout

est un différentiateur majeur pour les workflows Yocto. Elle transforme l’évaluation des vulnérabilités en une tâche BitBake native, plutôt qu’en un projet d’intégration de plateforme séparé. En pratique, elle fournit : des tâches dédiées pour l’évaluation interactive, L’analyse CI non interactive, La génération de rapports, L’export enrichi de SBOM ou VEX. Elle dérive également automatiquement des variantes à partir de la distribution, de la machine et de l’image Yocto. Pour les équipes Embedded Linux, c’est une proposition bien plus forte que la simple compatibilité des formats.

Rapports

VulnScout prend en charge les modèles de rapports par défaut et définis par l’utilisateur, avec un support pour les balises Jinja. Cela permet de générer des artefacts de rapport textuels complets liés au projet, aux paquets qu’il utilise et aux vulnérabilités associées. VulnScout prend également en charge le rendu des formats AsciiDoc en HTML et PDF pour plus de commodité. Cela rend la fonctionnalité de rapport plus proche d’un système de génération de livrables que d’une simple fonction d’export. Dependency-Track ne semble pas offrir le même modèle de modèle de document intégré.

VulnScout

VulnScout peut également exporter des données enrichies dans les formats SPDX2, CycloneDX, OpenVEX et autres formats pris en charge, y compris vos évaluations et métadonnées supplémentaires.

Cela met également en lumière une différence architecturale : VulnScout traite l’évaluation elle-même comme un artefact portable, et non seulement comme un état stocké dans une base de données d’application. Les équipes peuvent exporter des résultats d’évaluation basés sur OpenVEX, les conserver aux côtés des artefacts de build, les réimporter plus tard, les partager entre les instances ou les réutiliser après avoir réinitialisé une base de données CI. Cela convient particulièrement bien aux builds reproductibles, aux paquets de preuves et aux livraisons clients.

VulnScout

Enrichissement du SBOM et analyse continue

VulnScout peut détecter des problèmes au-delà de la première importation du SBOM, en utilisant des scanners open source pour détecter les vulnérabilités nouvellement divulguées. Vous pouvez exécuter Grype, OSV, et sbom-cve-check sur un projet complet ou sur une seule variante, ce qui permet aux équipes de continuer à examiner les anciens SBOM lorsqu’il est difficile d’en générer un nouveau. Chaque analyse est enregistrée dans l’onglet Scan, offrant une vue unique qui résume les résultats à travers les importations et les analyses.

Ce modèle d’exécution explicite est important. VulnScout peut combiner des preuves hétérogènes dans une seule évaluation : Inventaire des paquets depuis SPDX, Analyse des CVEs propre à Yocto, Décisions OpenVEX existantes, Résultats de Grype, Enrichissements ultérieurs, Exécutions ultérieures de scanners.

Il préserve ces sources de preuves au lieu de forcer chaque entrée à passer par un format d’ingestion unique. Cela rend le workflow plus facile à reproduire pour une version de build spécifique.

Dependency-Track utilise un modèle différent. Au lieu de déclencher manuellement des scanners, il ingère des BOM CycloneDX et vérifie en continu les composants par rapport à de nombreuses sources de renseignement (NVD, GitHub Advisories, OSV, OSS Index, Snyk, Trivy, etc.). De plus, il exécute des réanalyses périodiques automatiques.

VulnScout

Variantes et Versions

Les deux outils prennent en charge plusieurs instantanés SBOM pour un seul projet. VulnScout les appelle « Variantes », tandis que Dependency-Track les appelle « Versions »

Les modèles de données sous-jacents diffèrent :

• Dans VulnScout, plusieurs builds peuvent appartenir à un même domaine d’évaluation, de sorte que les résultats partagés peuvent être examinés ensemble.
• Dans Dependency-Track, les versions sont des projets séparés, ce qui signifie que la même CVE peut apparaître séparément dans plusieurs sous-projets sans que ce soit une erreur de comptage.

Dependency-Track 5 ajoute des projets de collection pour agréger les métriques à travers des sous-projets sélectionnés, mais ces sous-projets restent distincts avec des résultats séparés.

Dependency-track

VulnScout correspond plus directement aux familles de produits embarqués. Si la même CVE apparaît dans deux variantes d’un même projet, les graphiques du tableau de bord la comptent une seule fois au niveau du projet, et les utilisateurs peuvent isoler une seule variante avec le sélecteur de variantes. Le tableau des vulnérabilités montre également exactement quelles variantes sont affectées. Pour les produits Embedded Linux, cela correspond souvent mieux que de traiter chaque paire nom/version comme un projet séparé.

VulnScout

Évaluations

Le flux d’évaluation de base est similaire dans les deux outils : Ouvrir une vulnérabilité, Examiner ses détails, Choisir un statut, Ajouter une raison, Optionnellement ajouter un commentaire.

VulnScout offre un suivi plus fluide pour les investigations approfondies, Dependency-Track affiche un flux d’audit textuel où de nombreuses petites modifications apparaissent non groupées.

Dependency-track

VulnScout

VulnScout

VulnScout inclut également des estimations de temps dans l’interface d’évaluation. Les équipes peuvent exporter le temps suivi en CSV via la fonctionnalité de rapport.

Ceci est plus qu’une simple fonctionnalité de commodité. Cela relie le tri des vulnérabilités à la planification de leur correction en transformant le travail de révision en données exploitables pour : les estimations techniques, la planification de projet, les devis clients. Cela rend VulnScout utile non seulement pour décider si une CVE est importante, mais aussi pour estimer le coût de sa résolution.

La portée de l’évaluation est une autre différence : Dans VulnScout, des cases à cocher permettent d’appliquer une évaluation à des variantes sélectionnées. Dans Dependency-Track, les utilisateurs doivent souvent répéter la même évaluation sur plusieurs versions. VulnScout prend également en charge l’évaluation en masse, tandis que Dependency-Track nécessite souvent des modifications une par une pour les actions répétées.

VulnScout

Stratégies (Policies)

Les deux outils permettent aux utilisateurs de définir des règles pour les vulnérabilités à haut risque.

Dans VulnScout, cette fonctionnalité cible l’utilisation en CI. Vous exécutez VulnScout avec--match-condition et, si nécessaire, demandez un rapport pour les CVEs correspondantes. Si une vulnérabilité correspond, VulnScout quitte avec un code non nul. Ainsi, l’intégration CI est simple. Les expressions de règle peuvent être complexes. Cependant, pour l’instant, les conditions de correspondance restent une fonctionnalité backend et CLI, et non une fonctionnalité de tableau de bord.

$ ./vulnscout \
  --match-condition "((cvss >= 9.0 or (cvss >= 7.0 and epss >= 30%)) and (pending == true or affected == true))" \
  --report "match_condition.adoc"
# Vulnerability triggered fail condition: CVE-2016-0749
# Vulnerability triggered fail condition: CVE-2016-10642
# ...
# Report written: /scan/outputs/match_condition.adoc

En revanche, Dependency-Track utilise le Common Expression Language (CEL), qui prend en charge : les expressions booléennes complexes, les expressions régulières, les plages de versions, la traversée du graphe de dépendances, les tags de projet, les fonctions personnalisées.

Dependency-Track possède donc des fonctionnalités de gouvernance intégrées solides. Le point fort de VulnScout est différent : il peut évaluer les conditions de correspondance en ligne dans un workflow d’évaluation local ou piloté par CI et retourner immédiatement un code de sortie compatible CI.

Dependency-track

Prédiction  des exploits

Pour prioriser les risques d’exploitation, les équipes combinent généralement deux scores :

• CVSS (https://www.first.org/cvss/): gravité d’une vulnérabilité.
• EPSS (https://www.first.org/epss/): probabilité d’exploitation.

La combinaison de ces deux scores facilite la priorisation. Dependency-Track propose un graphique bidimensionnel clair avec le CVSS sur un axe et l’EPSS sur l’autre, de sorte que les problèmes à haute priorité apparaissent dans la zone en haut à droite. VulnScout ne propose pas encore ce graphique, bien que les utilisateurs puissent trier la liste des vulnérabilités par CVSS ou EPSS.

Dependency-track

Dependency-Track 5 va plus loin en ajoutant la surveillance des vulnérabilités exploitées connues (KEV). Il peut : récupérer les données KEV à partir de plusieurs sources (en commençant par CISA KEV, ENISA KEV et VulnCheck KEV), marquer les résultats concernés dans la vue d’audit, filtrer la liste pour ne garder que les KEV, déclencher des violations de stratégie sur les KEV, générer des alertes lorsque de nouvelles KEV apparaissent. C’est un ajout significatif pour la conformité au Cyber Resilience Act, qui exige que les produits surveillent les composants pour les vulnérabilités déjà exploitées. VulnScout ne suit pas actuellement l’état des KEV.

Intégration avec les CI

VulnScout s’intègre facilement dans les CI grâce à son CLI complet (https://vulnscout.readthedocs.io/en/latest/vulnscout-script.html#non-interactive-mode-ci-automation). Comme il démarre rapidement sous forme de conteneur, un pipeline peut exécuter l’intégralité de l’évaluation localement avec une configuration minimale. En pratique, VulnScout peut être la tâche CI : importer des preuves, enrichir les résultats, évaluer une condition de correspondance, produire des rapports, exporter des artefacts enrichis en un seul workflow.

Voici un exemple de workflow simple qui charge des fichiers SPDX et cve-check, génère des rapports et échoue si certaines CVEs correspondent à la condition d’échec :

./vulnscout --project demo --variant x86 \
  --add-spdx $(pwd)/example/spdx3/core-image-minimal-qemux86-64.rootfs.spdx.json \
  --add-cve-check $(pwd)/example/spdx3/core-image-minimal-qemux86-64.rootfs.json

./vulnscout \
  --match-condition "((cvss >= 9.0 or (cvss >= 7.0 and epss >= 30%)) and (pending == true or affected == true))" \
  --report "summary.adoc" \
  --report "vulnerabilities.csv" \
  --report "match_condition.adoc"

# The previous command will fail if a CVE matches the condition, thus failing the workflow.

Dependency-Track fonctionne différemment. Il s’agit généralement d’un service en cours d’exécution que la tâche CI appelle. Dans ce modèle, les pipelines publient un BOM CycloneDX vers une instance déployée, puis s’appuient sur la plateforme pour l’analyse, l’évaluation des stratégies, la gouvernance plus large du portefeuille. C’est un modèle CI/CD valide, mais il diffère de l’exécution de l’intégralité de l’évaluation dans une seule tâche autonome. Les options d’intégration courantes incluent :

• Le plugin officiel Jenkins (télécharge les BOM, affiche les vulnérabilités et signale les violations de stratégie).
• L’action officielle GitHub, recommandée par la documentation de Dependency-Track pour les workflows GitHub. Sa portée est cependant plus limitée, car elle se concentre principalement sur le téléchargement d’un BOM.
• Vous pouvez également utiliser des actions GitHub tierces qui font plus, mais la maintenance tierce ajoute un risque de sécurité.
• Enfin, vous pouvez effectuer des requêtes HTTP brutes et traiter les données de réponse, mais cela est plus complexe à implémenter.

Tableau récapitulatif

Déploiement et formats

Reports, analysis, and variants

Assessment, policies, and fit

Conclusion

Choisissez Dependency-Track lorsque vous avez besoin d’une plateforme multi-utilisateurs, fonctionnant en continu, pour l’inventaire et la gouvernance d’un large portefeuille logiciel. Choisissez VulnScout lorsque l’évaluation des vulnérabilités doit être proche du build, consommer des preuves natives Yocto, préserver les évaluations sous forme d’artefacts portables, et produire des rapports reproductibles et des résultats CI sans nécessiter un service central.

Références

• VulnScout: https://blog.savoirfairelinux.com/en-ca/2025/vulnscout-the-easy-to-use-tool-for-securing-embedded-systems-and-staying-compliant/
• Dependency-Track: https://dependencytrack.org/
• Yocto Project Documentation: https://docs.yoctoproject.org/
• meta-cyclonedx: https://github.com/iris-GmbH/meta-cyclonedx
• meta-vulnscout: https://github.com/savoirfairelinux/meta-vulnscout/
• GitHub Actions (book): https://doi.org/10.1007/978-1-4842-6464-5_1