Outils SCA open source en 2026 : Trivy, Grype et OSV-Scanner testés, et OpenCVE pour surveiller les nouvelles CVE

Que vérifie un outil SCA ?

Un outil SCA, pour Software Composition Analysis ou analyse de composition logicielle, dresse la liste des paquets open source de votre projet, y compris ceux que vos dépendances tirent elles-mêmes, et confronte chaque version exacte aux bases d'avis de sécurité, comme celle de GitHub et OSV. Il remonte les vulnérabilités connues, la version corrigée quand elle existe et, pour certains outils, la licence de chaque paquet.

La liste est plus longue que ce que montre le manifeste. Le 5 novembre 2026, le dépôt de notre propre site déclarait 39 paquets dans son package.json, 17 dépendances et 22 dépendances de développement, et son pnpm-lock.yaml en listait 965. C'est le lockfile qui est installé, donc un scanner qui ne lit que le manifeste passe à côté des 926 autres.

Le SCA ne lit pas le code écrit par votre équipe, c'est le travail du SAST, et les deux répondent à des questions différentes. Le SAST cherche une faille dans votre code, le SCA cherche une faille publiée dans un paquet que vous livrez. Aucun des deux ne voit un paquet malveillant qui n'a pas encore d'avis de sécurité, et c'est par là que passe le slopsquatting, l'attaque sur les noms de paquets inventés par les modèles d'IA.

Quels outils SCA open source sont maintenus en 2026 ?

Trivy, Grype, OSV-Scanner, Dependency-Check, Dependency-Track et pip-audit ont tous publié une version en 2026 et aucun n'est archivé, d'après GitHub au 5 novembre 2026. Les six sont sous licence Apache-2.0. Ils diffèrent par ce qu'ils lisent et par l'origine de leurs données, et Dependency-Track est une plateforme qui conserve les résultats, pas un scanner qu'on lance en CI.

OSV-Scanner est l'interface de Google vers OSV.dev, une base au format ouvert qui rassemble la GitHub Advisory Database, les bases de vulnérabilités de PyPI et de Go, RustSec et d'autres. Trivy scanne les dépôts, les images de conteneurs et le code d'infrastructure avec un seul binaire. Grype scanne les images, les systèmes de fichiers et les SBOM, et lit les listes de paquets que construit Syft, l'autre outil d'Anchore. Dependency-Check et Dependency-Track sont des projets Flagship de l'OWASP. pip-audit est maintenu sous l'égide de la Python Packaging Authority.

Deux outils souvent rangés dans le SCA mettent les dépendances à jour sans les scanner au même sens. Dependabot, dont la bibliothèque centrale est sous licence MIT, ouvre des pull requests de mise à jour, et Renovate, sous AGPL-3.0, fait de même pour un large éventail de langages et de plateformes. Ils gardent les versions à jour, et aucun des deux ne garde la trace de ce que vous avez livré.

Qu'a trouvé chaque outil dans un même dépôt ?

Lors d'un test mené par CybeDefend le 5 novembre 2026, cinq outils SCA ont scanné un même dépôt aux dépendances obsolètes dans quatre écosystèmes, et ont relevé ensemble 109 vulnérabilités distinctes dans 21 paquets. OSV-Scanner en a trouvé 109, Trivy 105, Grype 104. npm audit a trouvé les mêmes 43 vulnérabilités npm que les autres, et pip-audit les mêmes 21 dans les quatre paquets Python épinglés.

Nous avons monté un petit dépôt qui ressemble au backend d'une boutique en ligne, avec un service par écosystème et des versions de 2020 et 2021 figées exprès :

• une API Node.js avec express 4.17.1, lodash 4.17.20 et axios 0.21.1, et un lockfile de 53 paquets résolu le jour même ;
• un worker Python dont le requirements.txt épingle requests 2.25.0, urllib3 1.26.4, PyYAML 5.3.1 et Jinja2 2.11.2 ;
• un service de facturation Java dont le pom.xml déclare log4j-core 2.14.1 et commons-text 1.9 ;
• une passerelle Go sur une version de novembre 2021 de golang.org/x/net et sur golang.org/x/text 0.3.7, dont le code appelle le parseur HTML du premier et une seule fonction de largeur du second.

Chaque outil a tourné avec ses réglages par défaut. Nous avons fusionné les résultats entre identifiants CVE, GHSA, Go et PyPA, à partir des alias de chaque outil et de ceux d'OSV, pour qu'une vulnérabilité signalée sous deux noms ne compte qu'une fois.

Les durées de Trivy et de Grype sont celles d'un deuxième passage. Au premier, chacun a passé l'essentiel de son temps à télécharger une base de vulnérabilités, 132 Mio pour Trivy, et a mis 19,2 s et 101,7 s. OSV-Scanner interroge osv.dev en ligne par défaut.

Trois différences expliquent les écarts :

• Un requirements.txt sans lockfile liste quatre paquets, et rien en dessous. OSV-Scanner a résolu ce dont requests dépend lui-même et a trouvé trois avis de plus dans idna et certifi. Trivy, Grype et pip-audit ont lu les quatre lignes épinglées et se sont arrêtés là.
• Côté Java, log4j-core a besoin de log4j-api, et commons-text de commons-lang3. Trivy et OSV-Scanner ont résolu les deux et trouvé un avis dans chacun ; Grype n'a lu que les deux paquets déclarés.
• En Go, Trivy n'a pas listé CVE-2023-44487, la faille HTTP/2 Rapid Reset, sur golang.org/x/net, là où Grype et OSV-Scanner l'ont fait.

Sur npm, les quatre outils sont d'accord sur les 43, et 13 d'entre elles se trouvent dans six paquets non déclarés qu'express tire avec lui : qs, body-parser, path-to-regexp, cookie, send et serve-static. Log4Shell, CVE-2021-44228, a été trouvée par Trivy, Grype et OSV-Scanner, et le JSON de Grype portait en plus son score EPSS de 0,99999 et son entrée au catalogue CISA Known Exploited Vulnerabilities. Les niveaux de gravité ne concordent pas toujours : pour les mêmes résultats, Trivy en classe quatre en critique et Grype cinq.

Trivy, Grype ou OSV-Scanner : lequel choisir ?

Prenez OSV-Scanner pour des services Go et pour des projets Maven ou Python sans lockfile, là où il a résolu ce que les autres ont manqué. Prenez Trivy pour un seul binaire qui couvre dépendances, images de conteneurs, IaC et licences. Prenez Grype si vous produisez déjà des SBOM avec Syft ou si vous voulez les données EPSS et KEV à côté de chaque résultat.

Les trois sont d'accord quand l'entrée est un lockfile, comme le montrent nos résultats npm, donc le choix dépend de ce que vous scannez d'autre et de ce que vous faites de la sortie :

• Trivy convient à une équipe qui veut un seul scanner en CI pour plusieurs couches. La même commande scanne un dépôt, une image ou un dossier Terraform, et --scanners license ajoute les licences. Sa base se télécharge une fois puis reste en cache, d'où la seconde de notre deuxième passage.
• Grype convient à une équipe qui construit déjà des SBOM. Vous scannez le SBOM une fois au build, puis de nouveau plus tard sans rien reconstruire, et vous triez avec les données EPSS et KEV que porte son JSON.
• OSV-Scanner convient à une équipe qui tient à la précision. Il a résolu les dépendances transitives de Maven et, dans notre test, celles de Python, son analyse d'appels Go est active par défaut, et sa commande fix propose des montées de version pour les projets npm et Maven.

npm audit et pip-audit restent utiles comme premier contrôle d'un développeur avant un commit, puisqu'ils n'exigent rien à installer, mais chacun ne couvre qu'un écosystème.

Un outil SCA dit-il si une vulnérabilité est atteignable ?

Seul OSV-Scanner l'a fait dans notre test, et seulement pour Go. Son analyse d'appels, active par défaut, a marqué 12 des 31 vulnérabilités Go comme appelées par notre code et 18 comme non appelées ; une seule n'a pas pu être analysée. Son tableau par défaut affichait 13 vulnérabilités sur 31 pour la passerelle Go, et rien du tout pour golang.org/x/text.

Les appels correspondaient à ce que fait notre code. La passerelle utilise le parseur HTML de x/net, donc les avis sur le parseur et le rendu apparaissaient comme appelés, alors que les avis HTTP/2 du même module, un chemin de code que la passerelle ne touche jamais, ne l'étaient pas. Les trois avis de x/text portent sur des fonctions que la passerelle n'appelle pas. OSV-Scanner s'appuie pour cela sur govulncheck, la bibliothèque de Go elle-même, et --all-vulns fait réapparaître les résultats masqués. Son analyse d'appels en Rust est marquée expérimentale et exécute les scripts de build de vos dépendances.

Pour npm, Python et Java, aucun outil open source de notre test n'est allé aussi loin, et chaque résultat pèse autant, que votre code appelle la fonction vulnérable ou non. C'est le manque que comble la reachability, et c'est le même problème de tri que nous décrivons dans pourquoi un scanner remonte 1 200 vulnérabilités quand 12 seulement sont réelles. Le SCA de CybeDefend travaille à ce niveau : il marque chaque paquet comme utilisé, potentiellement utilisé ou inutilisé, pour que ceux que votre code appelle vraiment passent en premier. Le SCA de CybeDefend montre ce tri.

OWASP Dependency-Check vaut-il encore la peine ?

Dependency-Check 13.0.0 est maintenu et reste un projet Flagship de l'OWASP, mais dans notre test il s'est arrêté à sa première mise à jour de base sur « Invalid API Key » et n'a rien produit. Son README écrit que les utilisateurs sont « highly » encouragés à obtenir une clé d'API NVD, et que sans elle les mises à jour sont « extremely slow ». Prévoyez une clé et une base en cache avant de l'adopter.

Il reste un bon choix pour les builds Java et .NET, où il lit les JAR et les assemblies compilés, et ses plugins Maven et Gradle tournent dans le build. Deux choses pèsent sur lui en 2026. Il rapproche les paquets par identifiants CPE issus de la NVD, d'où l'importance de la clé, et OSS Index de Sonatype, une autre de ses sources, exige des identifiants depuis septembre 2025. Sans eux, précise le README, Dependency-Check « will automatically disable the OSS Index analyzer ».

Que ratent les outils SCA ?

Les outils SCA ratent trois choses : les paquets malveillants qui n'ont pas encore d'avis, les vulnérabilités dans du code copié sans gestionnaire de paquets, et tout ce qu'aucun lockfile ni manifeste ne décrit. Ils ne remontent que des problèmes connus, donc un paquet publié hier avec une porte dérobée passe pour sain tant que personne n'a déposé d'avis.

Les agents de code ajoutent un quatrième manque, celui du moment. Claude Code, Cursor ou Codex peuvent ajouter une dépendance au milieu d'une tâche, et le scan en CI tourne quand l'agent est déjà passé à autre chose, parfois une fois la pull request ouverte. Un agent qui lit les résultats du projet pendant qu'il travaille peut choisir la version corrigée dès le départ, ce que nous décrivons dans l'accès en direct des agents de code à tous les résultats de scan. VibeDefend transmet à l'agent les résultats sur les dépendances du projet par MCP pendant qu'il écrit, qu'il s'agisse de Claude Code, Cursor, Codex, Devin Desktop ou GitHub Copilot, pour qu'il passe à la version corrigée dans la même session. Le fonctionnement de VibeDefend montre la boucle.

Entre deux scans : surveiller les nouvelles CVE avec OpenCVE

Un scan SCA est un instantané. Il liste les vulnérabilités connues de vos dépendances le jour où il tourne, et une CVE publiée le lendemain matin sur un paquet que vous livrez reste invisible jusqu'au scan suivant, sauf si une plateforme comme Dependency-Track revérifie les SBOM que vous y avez stockés. Le SCA ne voit en outre que ce que vous construisez, et aucun lockfile ne liste l'appliance VPN ou le serveur de base de données que votre équipe fait tourner à côté du code.

Cette veille, c'est le métier d'OpenCVE. Vous vous abonnez aux éditeurs et aux produits qui vous concernent, Fortinet ou WordPress par exemple, et OpenCVE vous alerte par e-mail, Slack ou webhook dès qu'une CVE qui les touche est publiée ou mise à jour. Pas d'agent à déployer, rien à scanner. Il s'appuie notamment sur MITRE, NVD, CISA KEV, Red Hat et Vulnrichment, et met côte à côte le CVSS, l'EPSS et le KEV de chaque CVE, ce qui permet de distinguer une faille déjà exploitée par des attaquants d'une faille qui a seulement un score élevé. OpenCVE existe en service cloud avec une offre gratuite, ou en auto-hébergement avec son édition Community, dont le code est publié sur GitHub sous Business Source License.

OpenCVE n'est pas un scanner SCA, puisqu'il ne lit aucun lockfile et ne scanne aucun dépôt, et c'est justement pour cela que les deux se complètent : votre outil SCA vous dit quels paquets vous utilisez, et OpenCVE vous prévient le jour où une nouvelle CVE tombe sur l'un des produits que vous suivez.

Comment lancer le SCA en CI et garder une seule liste ?

Lancez le scanner à chaque pull request sur les lockfiles, produisez du SARIF pour la forge de code et un SBOM pour l'historique, et ne faites échouer le build que sur les vulnérabilités critiques ou hautes qui ont un correctif. Conservez le SBOM de chaque release, car un nouvel avis concerne souvent une version livrée il y a des mois.

Une configuration minimale avec les outils de notre test :

# À chaque pull request : lockfiles, SARIF pour le code scanning
osv-scanner scan source -r --format sarif --output-file osv.sarif .
trivy fs --scanners vuln --severity CRITICAL,HIGH --ignore-unfixed --exit-code 1 .

# À chaque release : garder le SBOM et le rescanner plus tard
trivy fs --format cyclonedx --output sbom.cdx.json .
grype sbom:sbom.cdx.json

Dependency-Track prend le fichier CycloneDX et continue de surveiller les composants de chaque version de chaque application qu'il contient, ce qui répond à la question que pose l'auditeur : quelle release contenait la version vulnérable, et quand a-t-elle été corrigée. Pour une équipe qui prépare SOC 2 ou ISO 27001, cet historique compte plus que le scan lui-même.

Un deuxième scanner ajoute à la fois des résultats et des doublons. Notre test a produit 451 entrées dans cinq fichiers JSON aux cinq schémas différents pour 109 vulnérabilités distinctes, le même problème de fusion que nous avons rencontré avec six scanners de secrets open source sur un dépôt truffé de faux secrets. CybeDefend Open Source est conçu pour cette étape. Il lance les scanners que vous choisissez, n'importe quel outil qui écrit du SARIF, et range ce qu'ils trouvent dans une seule file dédoublonnée, gratuitement et sur vos serveurs. Il arrive bientôt, et la liste d'attente est ouverte.

Questions fréquentes

Quel est le meilleur outil SCA open source en 2026 ?

Dans notre test du 5 novembre 2026, OSV-Scanner 2.7.0 a trouvé les 109 vulnérabilités distinctes d'un dépôt aux dépendances npm, Python, Maven et Go obsolètes, Trivy 0.76.1 en a trouvé 105 et Grype 0.121.0 104. OSV-Scanner a résolu plus de dépendances transitives ; Trivy couvre plus de couches avec un seul binaire.

Trivy fait-il du SCA ?

Oui. Trivy cherche dans les lockfiles et les manifestes les vulnérabilités connues des paquets open source, ce qui est exactement l'analyse de composition logicielle, et il scanne aussi les images de conteneurs, le code d'infrastructure, les secrets et les licences. Il est sous Apache-2.0 et maintenu par Aqua Security. Dans notre test, il a trouvé 105 vulnérabilités sur 109 et résolu les dépendances transitives Maven.

Quelle différence entre Trivy et Grype ?

Ce sont deux scanners sous Apache-2.0 qui lisent dépôts, SBOM et images de conteneurs. Trivy scanne aussi l'IaC, les secrets et les licences, et il a résolu les dépendances transitives Maven dans notre test, pour 105 vulnérabilités trouvées. Grype, qui s'appuie sur les listes de paquets de Syft, en a trouvé 104, a manqué les paquets transitifs Maven, et ajoute à son JSON les scores EPSS et les entrées du catalogue CISA KEV.

Faut-il une clé d'API NVD pour OWASP Dependency-Check ?

Son README juge la clé vivement recommandée et prévient que sans elle les mises à jour sont extrêmement lentes. Dans notre test de la version 13.0.0, le 5 novembre 2026, la première mise à jour NVD s'est arrêtée sur « Invalid API Key » et aucun scan n'a pu tourner. Demandez une clé à la NVD et gardez la base en cache entre deux passages de CI.

Quelle différence entre SCA et SAST ?

Le SAST lit le code écrit par votre équipe et y cherche des motifs vulnérables, comme une injection. Le SCA lit vos manifestes et vos lockfiles et remonte les vulnérabilités publiées dans les paquets open source que vous utilisez, y compris ceux que vos dépendances tirent elles-mêmes. Un projet a besoin des deux : le lockfile de notre propre site liste 965 paquets pour 39 déclarés.

npm audit et pip-audit suffisent-ils ?

C'est un bon premier contrôle, puisqu'ils n'exigent rien à installer et qu'ils ont trouvé les mêmes vulnérabilités npm et Python que les gros outils sur les paquets qu'ils lisent. Chacun ne couvre qu'un écosystème, aucun n'écrit de SARIF, et pip-audit lancé sur un fichier requirements sans lockfile n'audite que les lignes qui y figurent.

Qu'est-ce que la reachability en SCA ?

La reachability dit si votre code appelle la fonction vulnérable d'une dépendance ou se contente d'importer le paquet. Dans notre test, l'analyse d'appels Go d'OSV-Scanner a marqué 18 des 31 vulnérabilités Go comme non appelées et les a retirées de son tableau par défaut. Pour npm, Python et Java, aucun des outils open source que nous avons lancés ne faisait cette distinction.

Un outil SCA vous alerte-t-il quand une nouvelle CVE est publiée ?

Pas entre deux scans. Un scanner remonte ce qui est connu le jour où il tourne, alors lancez-le en CI à chaque modification et à intervalle régulier, chaque jour par exemple, pour attraper les avis publiés depuis. Pour être prévenu le jour même où une CVE touche un produit que vous utilisez, ajoutez un service de veille CVE comme OpenCVE, qui alerte par e-mail, Slack ou webhook quand une CVE touchant un éditeur ou un produit que vous suivez est publiée ou mise à jour.