Les 13 meilleurs outils d'analyse de la composition logicielle (SCA) en 2026

À qui s'adresse cette page

Cette page s'adresse aux équipes qui choisissent un outil SCA, ou qui vérifient si le leur convient toujours. Nous développons CRACI : tenez-en compte. Chaque affirmation sur un autre produit provient de la documentation de son éditeur, et la plupart des produits disposent d'une page CRACI vs X plus détaillée.

Précisons-le d'emblée : CRACI n'est pas un scanner SCA au sens classique. C'est un enregistreur. Il exécute vos jobs GitHub Actions et enregistre ce qu'ils ont récupéré. Il est conçu pour compléter un outil SCA, pas pour le remplacer.

Ce que font les outils SCA

Presque tous les outils SCA suivent les mêmes étapes. Ils diffèrent par la qualité avec laquelle ils exécutent chacune. Pour les bases, voir qu'est-ce que l'analyse de la composition logicielle, comment fonctionne un scan SCA, SAST vs SCA et l'analyse d'atteignabilité.

1. Identifier les composants. Lire les manifestes et les lockfiles, analyser le code source ou prendre l'empreinte des binaires pour lister les dépendances directes et transitives.
2. Rapprocher les vulnérabilités. Confronter chaque composant et chaque version à des bases de données telles que la NVD, la GitHub Advisory Database et OSV.
3. Vérifier les licences par rapport à votre politique.
4. Prioriser. Classer les résultats selon la sévérité, les données d'exploitation telles qu'EPSS et, dans de nombreux outils, l'atteignabilité.
5. Corriger. Suggérer des mises à niveau ou ouvrir des pull requests.
6. Surveiller et rendre compte. Alerter sur les nouvelles vulnérabilités et exporter une SBOM.

La première étape décide de tout ce qui suit. Un composant que l'outil n'a jamais identifié ne peut être ni rapproché, ni priorisé, ni listé dans la SBOM : c'est pourquoi la première ligne des tableaux ci-dessous demande d'où vient la liste de composants de chaque outil. Pour les bases, voir ce qu'est l'analyse de la composition logicielle et ce qui la distingue du SAST.

Comment choisir

Quelques questions départagent ces outils plus vite que les listes de fonctionnalités :

• Avant le merge ou après la release ? Les outils SCA excellent sur les pull requests et dans l'IDE. Si la vraie difficulté est de savoir ce qui est entré dans une release livrée, il vous faut un enregistrement du build.
• Uniquement les dépendances, ou aussi votre propre code ? La plupart de ces produits incluent désormais le SAST. Certains ajoutent les secrets, l'IaC, les conteneurs ou le cloud.
• Quel volume d'alertes pouvez-vous absorber ? L'analyse d'atteignabilité, qui vérifie si votre code peut appeler la fonction vulnérable, est le terrain sur lequel plusieurs éditeurs se font concurrence.
• Devez-vous arrêter les mauvais paquets à l'entrée ? Les pare-feu de dépôts et les proxys de paquets les bloquent avant le téléchargement. Les scanners ne les signalent qu'après coup.
• Quelle CI utilisez-vous ? La plupart des outils SCA présentés ici s'adaptent à de nombreux systèmes CI. CRACI prend en charge uniquement GitHub Actions aujourd'hui, et GitLab CI et Jenkins figurent sur la roadmap.
• Couvre-t-il vos langages et vos systèmes de build ? Vérifiez chaque écosystème que vous livrez, y compris les monorepos et les parties de votre build qu'aucun lockfile ne décrit.
• Que devez-vous remettre ? Si vos clients ou le Cyber Resilience Act de l'UE demandent une SBOM par release, vérifiez les formats, le plan qui inclut l'export et si l'outil vous dit quand la liste est incomplète.
• Comment voulez-vous payer ? Par développeur, par committer, par contributeur, par plan ou sur devis.

En un coup d'œil

Dix colonnes ne tiennent pas dans un seul tableau : les produits sont donc répartis en deux. Les deux tableaux utilisent les mêmes lignes. « Non précisé » signifie que les pages des éditeurs que nous citons ne se prononcent pas. Tarifs en septembre 2026.

Suites SCA et AppSec pour les entreprises

Outils orientés développeurs et plateformes

Les outils, un par un

CRACI

CRACI est un enregistreur, pas un scanner. Vos jobs GitHub Actions s'exécutent sur des runners CRACI, et un proxy qui comprend les paquets enregistre ce que chaque job récupère, les preuves de dépendances suivant les caches CI. À partir de cet enregistrement, il produit une SBOM CycloneDX ou SPDX qui indique sa propre complétude, continue de réévaluer les SBOM surveillées, envoie chaque résultat à l'équipe chargée de la correction et peut bloquer un build en raison d'une licence. Idéal pour les équipes qui doivent prouver ce qui est entré dans chaque release. Attention : pas de SAST, de scan de secrets ou d'IaC, ni d'atteignabilité, et uniquement des jobs Linux sur GitHub Actions aujourd'hui (d'autres systèmes CI, Windows et macOS figurent sur la roadmap). La génération de SBOM au build

Snyk

Snyk est une plateforme orientée développeurs : SCA, Snyk Code (SAST), Snyk Container et Snyk IaC, dans l'IDE, la CLI, les intégrations SCM et la CI. Il priorise les résultats sur les dépendances avec l'atteignabilité, la maturité des exploits, EPSS et CVSS, et ouvre des pull requests de mise à niveau. Idéal pour les équipes qui veulent que les développeurs corrigent dès l'éditeur. Attention : son arbre de dépendances vient des manifestes et des lockfiles, et la commande snyk sbom n'est disponible que sur les plans Enterprise. CRACI vs Snyk

Sonatype

Sonatype est construit autour de la gouvernance de l'open source. Lifecycle applique des politiques de sécurité et de licences (ses politiques de licences couvrent plus de 2 000 licences), utilise Advanced Binary Fingerprinting sur ce que le build a produit et ouvre des Golden Pull Requests. Repository Firewall met en quarantaine les composants avant qu'ils n'entrent dans vos dépôts, et SBOM Manager surveille les SBOM importées. Idéal pour les grandes organisations qui veulent un contrôle au niveau du dépôt. Attention : l'offre évolue, et les nouveaux clients achètent désormais Sonatype Guide. CRACI vs Sonatype

Black Duck

Black Duck trouve l'open source où qu'il se cache : scans des gestionnaires de paquets, scan de signatures et d'extraits de code, et analyse binaire d'exécutables et de firmwares sans code source. Sa KnowledgeBase suit plus de 2 750 licences, et Coverity ajoute le SAST pour 22 langages. Idéal pour le code ayant un long historique d'open source copié ou vendoré, et pour vérifier des binaires tiers. Attention : le tarif est sur devis, et ses Fix PRs couvrent les dépendances directes. CRACI vs Black Duck

Mend.io

Mend AppSec associe Mend SCA, qui trace le graphe d'appels à travers les dépendances transitives, à Mend SAST pour plus de 30 langages. Mend Renovate maintient les dépendances à jour sur 90 gestionnaires de paquets ou plus, et la CLI Renovate est gratuite. Idéal pour les équipes ayant un gros backlog qui veulent à la fois la priorisation et les mises à jour automatisées. Attention : la documentation de Mend recommande elle-même de scanner après l'étape de build, si bien que la précision dépend de l'endroit du pipeline où vous l'exécutez. CRACI vs Mend.io

Checkmarx One

Checkmarx One est une large plateforme AppSec : SAST, SCA, secrets, IaC, sécurité des API, DAST, conteneurs et protection contre les paquets malveillants, avec une couche ASPM par-dessus. Son SCA utilise l'analyse des chemins exploitables, et les politiques peuvent faire échouer les builds. Idéal pour les organisations qui veulent un seul fournisseur pour les tests de sécurité applicative. Attention : la GitHub Action téléverse une archive zip de votre code source pour le scan (SCA Resolver peut analyser sur site à la place), et le tarif est sur devis. CRACI vs Checkmarx One et Alternatives à Checkmarx

Endor Labs

Endor Labs est construit autour de l'atteignabilité au niveau des fonctions, en traçant les chemins de code depuis votre source jusqu'à la fonction vulnérable dans les dépendances directes et transitives. Il ajoute l'analyse d'impact des mises à niveau, les Endor Patches qui rétroportent les correctifs, AI SAST, le scan de secrets et de conteneurs, un Package Firewall et la signature d'artefacts. Idéal pour les équipes submergées par les alertes de dépendances. Attention : lorsqu'un build complet n'est pas possible, il se rabat sur une atteignabilité plus grossière au niveau des dépendances. CRACI vs Endor Labs

Semgrep Supply Chain

Semgrep Supply Chain est le produit SCA de la plateforme AppSec de Semgrep, à côté de Semgrep Code (SAST) et de Semgrep Secrets. Il classe les résultats en atteignables, conditionnellement atteignables ou inatteignables, et Semgrep affirme que cela réduit jusqu'à 98 % des faux positifs. Lorsque les lockfiles sont incomplets, Dynamic Dependency Resolution combine l'analyse des manifestes et le gestionnaire de paquets pour compléter la liste. Il vérifie aussi les licences par rapport à votre politique, détecte les dépendances malveillantes, ouvre des pull requests de mise à niveau et exporte des SBOM CycloneDX. Idéal pour les équipes qui écrivent déjà des règles Semgrep, ou les petites équipes : le plan gratuit couvre jusqu'à 10 contributeurs. Attention : les produits payants sont facturés séparément, à partir de $30 par contributeur et par mois pour Supply Chain sur le plan Teams.

GitHub Advanced Security

GitHub vend désormais Secret Protection et Code Security (CodeQL, Copilot Autofix, dependency review) en plus du graphe de dépendances et de Dependabot, inclus dans tous les plans GitHub. Les Artifact attestations ajoutent une provenance signée au niveau SLSA v1.0 Build Level 2. Idéal pour les équipes déjà sur GitHub qui veulent la sécurité dans les pull requests. Attention : le graphe de dépendances décrit les manifestes et les lockfiles du dépôt, et les dépôts privés nécessitent un plan Team ou Enterprise pour les produits payants. CRACI vs GitHub Advanced Security

Aikido

Aikido réunit SCA, SAST, secrets, IaC, posture cloud, conteneurs, DAST et analyse des licences dans un seul tableau de bord. Son SCA utilise l'atteignabilité au niveau des fonctions, AutoFix ouvre des pull requests, et l'outil gratuit Safe Chain bloque les malwares connus lors des installations npm et PyPI. Idéal pour les petites équipes qui veulent une large couverture rapidement, ou des rapports SOC 2 et ISO 27001 à partir des résultats AppSec. Attention : ces rapports de conformité ne sont disponibles qu'à partir du plan Advanced, et les dépendances viennent des manifestes et des lockfiles. CRACI vs Aikido

Outils SCA gratuits et open source

Si le budget est la contrainte, quatre outils open source couvrent l'essentiel du SCA. Tous sont gratuits sous Apache-2.0. Vous les exécutez vous-même : la surveillance, le tri et le reporting sont donc à votre charge.

Trivy, d'Aqua Security, lit les lockfiles d'un dépôt et les métadonnées des paquets installés dans une image, et écrit des SBOM CycloneDX ou SPDX. CRACI vs Trivy. Grype, d'Anchore, scanne ce que liste son compagnon Syft et s'exécute entièrement en local, hormis le téléchargement de sa base de données. CRACI vs Syft et Grype. OSV-Scanner, de Google, est le client officiel de la base de données OSV.dev et prend en charge 19 types de lockfiles ou plus. OWASP Dependency-Check identifie les composants par CPE et les rapproche de la NVD, ce qui convient le mieux aux projets Java et .NET. Pour savoir comment les générateurs de SBOM gratuits sur lesquels reposent ces scanners lisent un dépôt, et pourquoi ils se contredisent, voir ce qui échappe aux générateurs de SBOM open source.

La place de CRACI

Tous les autres outils ci-dessus sont des scanners. Ils lisent un manifeste, un lockfile, une archive source ou un binaire et déterminent ce qu'ils contiennent. CRACI est un enregistreur. Vos jobs GitHub Actions s'exécutent sur des runners CRACI (remplacez runs-on par craci), et un proxy qui comprend les paquets enregistre ce que chaque job récupère depuis les sources npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk et Git, ainsi que les presets de téléchargement. Les preuves de dépendances suivent les caches CI. La vue d'inventaire de CRACI montre précisément quelles versions logicielles sont déployées dans quels produits, à l'échelle mondiale.

À partir de cet enregistrement, CRACI produit une SBOM CycloneDX ou SPDX qui indique sa propre complétude par job et par cache. Il applique une politique de trafic sortant qui bloque tout en cas d'échec, renvoie les SBOM, les traces réseau et la provenance via son API, continue de réévaluer les SBOM surveillées et permet aux équipes sécurité de trier les résultats et d'envoyer chacun à l'équipe chargée de la correction. Chaque composant porte sa licence déclarée : les licences copyleft et autres licences restrictives apparaissent donc avant que vous ne livriez, et la politique de licences peut bloquer un build en raison d'une licence. CRACI automatise une part importante de la visibilité sur la chaîne d'approvisionnement logicielle et des preuves dont les entreprises ont besoin pour leur démarche plus large de conformité au CRA.

CRACI n'est pas le bon choix lorsque :

• vous avez besoin de SAST, ou de scan de secrets ou d'IaC (il ne fait rien de tout cela),
• l'atteignabilité est votre priorité (CRACI ne la propose pas), ou vous avez besoin de listes de blocage de paquets dès aujourd'hui (sur la roadmap),
• vos pipelines s'exécutent sur GitLab, Jenkins ou CircleCI, ou nécessitent des runners Windows ou macOS (CRACI exécute aujourd'hui des jobs Linux sur GitHub Actions ; d'autres systèmes CI, Windows et macOS figurent sur la roadmap).

Dans ces cas, choisissez parmi les outils ci-dessus. Si vous devez aussi prouver ce qui est entré dans chaque release, utilisez CRACI comme runner et gardez votre SCA sur les pull requests. Pour approfondir la distinction entre scanner et enregistreur, voir CRACI vs les outils SCA et SBOM et le comparatif des outils SBOM. Découvrez aussi la génération de SBOM au build et les tarifs, ou réservez une démo pour voir l'enregistrement d'un build GitHub Actions.

CRACI comparé à chaque outil

• CRACI face à Snyk Ce que déclarent vos manifestes face à ce qu'a fait votre build.
• CRACI face à Aikido Une suite AppSec étendue face à des preuves de build déterministes.
• CRACI face à Sonatype Contrôle d'accès au dépôt et SCA face aux preuves de build.
• CRACI face à Black Duck Analyse du code, des extraits et des binaires face aux preuves de build.
• CRACI face à Mend.io Scan des dépendances face à l'observation des dépendances.
• CRACI face à Checkmarx Plateforme de tests AppSec face aux preuves issues du build.
• CRACI face à Endor Labs Analyse d'atteignabilité face à l'observation du build.
• CRACI face à JFrog Gestion des artefacts face aux preuves par build.
• CRACI face à GitHub Advanced Security Scan du code, des secrets et des dépendances face aux preuves de build.
• CRACI face à Dependabot Mises à jour de versions face à la connaissance de ce que vos builds ont utilisé.

Côte à côte

Plusieurs outils sur une même page, lorsque vous choisissez une catégorie plutôt qu'un produit.

• Comparatif Outils de gestion des vulnérabilités Tenable, Qualys, Rapid7, Microsoft Defender et des outils pour les logiciels que vous construisez.

Outils SCA : FAQ

Des réponses courtes aux questions fréquentes sur l'analyse de la composition logicielle

Qu'est-ce qu'un outil SCA ?

Un outil d'analyse de la composition logicielle (SCA) trouve les composants open source et tiers de votre logiciel, les confronte à des bases de données de vulnérabilités telles que la NVD, la GitHub Advisory Database ou OSV, et signale les vulnérabilités connues et les risques de licence. La plupart des outils SCA priorisent aussi les résultats, suggèrent ou ouvrent des pull requests de mise à niveau, exportent une SBOM et continuent de surveiller les nouvelles vulnérabilités.

Qu'est-ce qu'un scan SCA ?

Un scan SCA lit les manifestes, les lockfiles, les paquets installés ou l'image de conteneur d'un projet, détermine quels composants il contient et les confronte aux données de vulnérabilité et de licence. La plupart des outils le lancent sur chaque pull request et de façon planifiée, afin de repérer aussi les nouveaux avis de sécurité sur les versions que vous utilisez déjà.

Quelle est la différence entre le SCA et le SAST ?

Le SAST analyse le code écrit par votre équipe pour y trouver des failles telles que des bugs d'injection. Le SCA analyse les composants dont vous dépendez pour y trouver des vulnérabilités connues et des problèmes de licence. La plupart des outils commerciaux de cette page vendent désormais les deux, mais ils répondent à des questions différentes.

Quelle est la différence entre le SCA et une SBOM ?

Le SCA est le processus qui consiste à trouver et à évaluer les composants. Une SBOM est une liste de ces composants lisible par machine, généralement au format CycloneDX ou SPDX. La plupart des outils SCA peuvent en exporter une, et la SBOM n'est jamais plus complète que la méthode qui l'a produite : un scan de manifestes, un scan de binaires ou un enregistrement du build.

Quels sont les meilleurs outils SCA gratuits ?

Trivy, Grype, OSV-Scanner et OWASP Dependency-Check sont gratuits et open source. Parmi les outils commerciaux, Semgrep propose un plan gratuit jusqu'à 10 contributeurs, Snyk, Endor Labs et Aikido ont des offres gratuites, et les alertes Dependabot sont incluses dans tous les plans GitHub. Les outils gratuits vous laissent généralement la surveillance, le tri et le reporting.

Qu'est-ce que l'analyse d'atteignabilité en SCA ?

L'analyse d'atteignabilité vérifie si votre code peut réellement appeler la fonction vulnérable d'une dépendance, afin que les résultats inatteignables descendent dans la liste. Snyk, Endor Labs, Mend, Checkmarx, Semgrep, Aikido, Sonatype et Black Duck en proposent tous une forme. Pas CRACI.

CRACI est-il un outil SCA ?

Pas au sens classique. Les outils SCA scannent des fichiers pour déterminer ce qu'ils contiennent. CRACI est un enregistreur : il exécute vos jobs GitHub Actions et enregistre les paquets que chaque job a réellement récupérés, produit une SBOM CycloneDX ou SPDX qui indique sa propre complétude et continue de la surveiller pour détecter les nouvelles vulnérabilités. Les équipes l'utilisent en complément d'un outil SCA qui couvre les pull requests et le SAST.