Choisir un SCA sans se faire avoir

Par Joris VeyPublié le 6 octobre 2026mis à jour le 19 octobre 2026SCAApprofondi11 min de lecture

Vous savez maintenant comment un SCA reconstruit l'arbre des dépendances et trie les alertes. Reste à choisir l'outil. Une démonstration peut se limiter à un projet bien propre, quatre alertes rouges et une jolie courbe qui descend.
Voici comment voir ce qu'il y a derrière.

Cet article prolonge SCA : de l'inventaire à la priorité, mais se lit seul.

Les outils SCA, en une minute chacun

Ces outils n'ont pas le même rôle. Trois rôles se complètent : trouver (scanner), suivre (gestion de SBOM), proposer une correction (mise à jour). Un même outil peut en remplir plusieurs. Sélection non exhaustive, sans classement. Fiches vérifiées le 8 octobre 2026 ; chaque nom renvoie à sa source officielle. Les capacités dépendent de la version, de l'offre et des écosystèmes pris en charge.

Outil	Rôle	S'appuie sur, ou cherche	À savoir
OWASP Dependency-CheckLibre, Apache 2.0.	Scanner de dépendances de l'OWASP.	Les flux de la NVD, avec une identification par CPE. Utilise aussi des services tiers pour certains écosystèmes.	S'intègre à Maven, Gradle, Ant, Jenkins, GitHub Actions et Azure DevOps.
OWASP Dependency-TrackLibre, Apache 2.0.	Plateforme d'analyse de composants fondée sur le SBOM, pour suivre les risques d'une chaîne d'approvisionnement.	Des SBOM au format CycloneDX, comparés aux bases de vulnérabilités publiques.	Propose un déploiement par conteneurs Docker.
TrivyLibre, Apache 2.0, maintenu par Aqua Security.	Scanner polyvalent pour images de conteneurs, systèmes de fichiers, dépôts Git, machines virtuelles et Kubernetes.	Des vulnérabilités, des erreurs de configuration, des secrets, des licences, et génère des SBOM.	Les contrôles disponibles dépendent de la cible analysée.
OSV-ScannerLibre, Apache 2.0, développé par Google.	Scanner qui s'appuie sur la base ouverte OSV.dev.	Des fichiers de verrouillage et des images de conteneurs, selon les écosystèmes pris en charge.	L'analyse d'appels couvre certains langages et modes d'analyse seulement.
DependabotService de GitHub.	Intégré à GitHub : alertes sur les dépendances vulnérables, propositions de correction, mises à jour de versions.	Le graphe de dépendances du dépôt et la base de vulnérabilités de GitHub.	Une fois les mises à jour activées, ouvre des pull requests.
Snyk Open SourceProduit commercial.	Produit commercial d'analyse des dépendances, de l'éditeur à la chaîne d'intégration continue.	Sa propre base de vulnérabilités, alimentée par ses équipes de recherche.	Annonce un score de risque qui combine plusieurs facteurs, et des propositions de correction par pull request.

Juger un SCA sur votre projet

À couverture comparable, un rapport hiérarchisé facilite le tri ; vérifiez aussi les failles manquées. Pour juger sur votre projet, cinq questions, la preuve à exiger, et l'essai à faire soi-même :

Préparez le même instantané de code, les mêmes fichiers de verrouillage et le même artefact livré. Notez les versions des outils, leur configuration, les exclusions, la date des bases et les limites de temps. Séparez production, développement et tests. Conservez les rapports bruts, les durées, les erreurs et les parties non analysées : une analyse incomplète ne vaut pas un résultat sans faille.

Question	Preuve à demander	Essai sur votre dépôt
D'où viennent vos données de vulnérabilités ?	Les bases utilisées (NVD, OSV, base de GitHub, bulletins des distributions), leur fraîcheur, et la source de chaque alerte.	Comparer les couples composant/version et avis, en rapprochant les alias CVE et GHSA. Examiner chaque écart avec le bulletin source, y compris les cas vulnérables connus que les deux outils ratent.
Comment trouvez-vous les dépendances indirectes ?	Lecture des fichiers de verrouillage, de ce qui est livré, des images de conteneur et des copies embarquées.	Un projet de test avec une version vulnérable, en direct, en indirect et embarquée dans une archive, puis une version corrigée. Adapter les cas à vos écosystèmes.
Que dites-vous sur l'atteignabilité ?	Les langages couverts, le chemin d'appel montré, et ce que l'outil dit quand il ne sait pas.	Tester trois cas : fonction vulnérable appelée, non appelée et analyse impossible. Exiger la preuve et le périmètre de chaque verdict, sans confondre « inconnu » et « non atteignable ».
Comment priorisez-vous ?	Exploitation connue (KEV), probabilité d'exploitation (EPSS), exposition et contexte métier. VEX documente l'impact sur un produit ; les acceptations de risque restent des décisions distinctes.	Changer de version ou de configuration et vérifier la réévaluation de l'exception et de sa justification, sans masquer un risque nouvellement applicable.
Allez-vous jusqu'à la correction ?	La mise à jour proposée, la vérification qu'elle ne casse rien, le suivi jusqu'à la mise en service.	Mesurer, sur un cas réel, le temps entre l'alerte et la version en service.

Un essai en cinq jours, avec une décision à la fin

Le bon projet d'essai n'est ni un « hello world » ni tout votre patrimoine. Prenez un service représentatif, son image livrée et une petite collection de cas dont vous connaissez le résultat attendu. Voici un canevas à adapter à votre équipe, pas un délai garanti.

Jour 1, fixer le contrat. Listez les écosystèmes indispensables, les artefacts à analyser, le temps maximal acceptable en CI et les données autorisées à sortir. Choisissez avant l'essai les défauts éliminatoires, par exemple une analyse incomplète affichée comme propre.
Jour 2, établir l'inventaire. Comparez ce que chaque outil a réellement identifié au contenu attendu. Une dépendance absente de l'inventaire ne peut pas donner une bonne alerte. Consignez aussi les composants sans version fiable et les formats non pris en charge.
Jour 3, expliquer les écarts. Faites analyser le même périmètre par deux candidats. Pour chaque différence, distinguez identification, avis, plage de versions, filtrage et déduplication. Gardez une catégorie « non résolu » : le vote de deux scanners ne remplace pas une preuve.
Jour 4, corriger vraiment. Confiez une alerte à un développeur qui n'a pas assisté à la démonstration. Peut-il retrouver la dépendance parente à mettre à jour, comprendre le correctif, lancer les tests et faire vérifier l'artefact corrigé ? Chronométrez le travail humain aussi.
Jour 5, rejouer et décider. Relancez après une mise à jour et un changement de contexte. Exportez puis réimportez inventaire et décisions. Rendez une page : besoins satisfaits, angles morts, coût d'exploitation, propriétaire de chaque limite et choix motivé.

Mesurez séparément le premier scan et les suivants : téléchargement des bases et caches peuvent changer fortement la durée. Une médiane sur plusieurs exécutions comparables est plus utile que la meilleure durée de la démonstration.

Six cas qui départagent les outils

Ces cas sont des recettes d'essai, pas des résultats obtenus par Tamis. Pour chacun, gardez l'entrée, le résultat attendu, sa justification et la sortie réelle.

Cas	Ce qu'il révèle	Preuve attendue
La dépendance cachée	Votre paquet A dépend de B, dont la version est vulnérable.	B identifié avec sa version, le chemin depuis A et une piste de mise à jour. L'outil ne doit pas inventer une version à partir d'une simple plage.
La copie embarquée	Une bibliothèque est dans une archive livrée, sans figurer dans le manifeste racine.	La copie et son emplacement sont trouvés, ou la limite d'analyse est explicite. Testez aussi une archive Java assemblée avec ses dépendances si vous en livrez.
Le correctif rétroporté	La distribution a corrigé un paquet sans adopter la dernière version amont.	Le verdict utilise le bulletin et la version du paquet de cette distribution. « Numéro ancien » ne suffit pas à prouver « vulnérable ».
Le paquet de test	Une dépendance vulnérable sert aux tests mais ne figure pas dans l'artefact de production.	Les deux périmètres restent distincts. L'absence en production n'efface pas le risque éventuel pour les postes de développement ou la CI.
Le chemin inconnu	La fonction est appelée, non appelée, ou hors des capacités de l'analyse.	Trois verdicts justifiés. Ni l'absence de données sur la fonction ni un langage non pris en charge ne deviennent une preuve de non-atteignabilité.
La base indisponible	Le scanner ne peut pas charger les avis, ou son budget de temps est épuisé.	Échec ou couverture dégradée visible, fraîcheur du cache si utilisé et comportement CI explicite. Zéro résultat ne devient pas « aucune vulnérabilité ».

Le cas du rétroportage est notamment documenté dans la sélection des sources de Trivy : pour les paquets système, la provenance du correctif compte autant que le numéro amont.

120 alertes contre 80 : qui gagne ?

Exemple fictif, sans lien avec les outils cités. Deux scanners analysent le même artefact. A affiche 120 lignes, B en affiche 80. À ce stade, aucun ne gagne : une ligne peut être un alias d'avis, un second emplacement ou un doublon.

Après rapprochement, A et B signalent respectivement 75 et 70 couples composant/version et avis distincts. Ce total ne mesure toujours pas le rappel. Vous examinez alors un lot de dix cas vulnérables connus : A en retrouve neuf, B six. B paraît plus calme parce qu'il rate davantage de cas dans ce lot. Sur cinq cas corrigés, A produit deux alertes erronées, B aucune : A demande donc aussi plus de tri.

Le résultat utile est « 9 cas sur 10 retrouvés, 2 alertes erronées sur 5 cas corrigés », accompagné des cas et des limites. Ces petits nombres servent à trouver les désaccords, pas à proclamer un taux de précision valable sur tous vos projets. Ajoutez le temps nécessaire pour comprendre puis corriger une alerte : c'est une partie du coût que les tableaux commerciaux montrent rarement.

Choisir le dispositif, pas seulement le scanner

Votre problème est de bloquer les nouvelles dépendances vulnérables ? Commencez par la couverture de vos formats, un résultat CI compréhensible et une mise à jour que l'équipe peut réellement intégrer. Une pull request ouverte n'est pas encore un correctif livré.

Votre problème est de savoir quels produits livrés sont touchés par un nouvel avis ? Vérifiez la conservation des SBOM par version, leur réévaluation, la fraîcheur des sources et l'attribution à une équipe. Refaire le scan de la branche principale ne suffit pas à décrire une ancienne version encore en service.

Votre problème est le manque de temps pour trier ? Faites mesurer le temps de décision sur de vraies alertes, avec leurs chemins, sources et exceptions. Une seconde base peut ajouter des détections utiles, mais aussi des avis en double et de la maintenance. N'ajoutez un outil que si son apport observé justifie ce travail.

Pour le coût, additionnez abonnement éventuel, calcul et stockage, entretien des intégrations, tri et mises à jour. Demandez l'unité facturée et ce qui se passe quand vous ajoutez des dépôts, des contributeurs ou des scans. Un prix par siège ne dit pas à lui seul combien coûtera le dispositif.

Avant de signer

Exigez un essai sur votre projet, la provenance des alertes et un export exploitable : CycloneDX ou SPDX pour le SBOM, un format VEX identifié pour les déclarations d'impact, et un export des décisions de tri avec leur auteur, leur justification et leur échéance. Vérifiez la réimportation dans votre outil cible, puis le coût total, les données transmises, leur conservation et le fonctionnement sans accès réseau si vous en avez besoin. Consignez les limites constatées avant de choisir.

Pour conclure

Une démonstration propre ne dit pas comment l'outil se comportera sur votre projet. Comparez d'abord les inventaires, puis les cas dont vous connaissez la réponse, puis le temps de décision sur de vraies alertes. Retenez l'outil qui dit d'où vient chaque alerte, montre ce qu'il n'a pas pu analyser et garde vos décisions, preuve à l'appui.

Les mots de cet article · 4 mots

CVE: Le numéro unique attribué à une faille connue, comme CVE-2021-44228.
SBOM: La liste des composants d'un logiciel, avec leurs versions.
CycloneDX, SPDX: Les deux formats standard de SBOM.
VEX: Une déclaration datée sur l'impact d'une vulnérabilité pour un produit identifié : affecté, non affecté, corrigé ou en cours d'investigation. Voir la spécification OpenVEX.

Pour revoir les bases : Le SCA expliqué simplement. Et pour le code que l'équipe écrit : Choisir un SAST sans se faire avoir.

Pour commencer : SCA : de l'inventaire à la priorité