Fortify vs Checkmarx One vs Veracode vs Snyk vs GitHub Code Security vs Semgrep : quelle plateforme AppSec enterprise choisir en 2026 ?

• si le code propriétaire contient des vulnérabilités,
• si les dépendances open source présentent des CVE connues ou des problèmes de licence,
• si des secrets se trouvent dans le dépôt,
• si Terraform, Kubernetes ou CloudFormation sont mal configurés,
• si l'image du conteneur contient des paquets vulnérables,
• si l'application en cours d'exécution et l'API sont vulnérables du point de vue d'un attaquant,
• si les résultats peuvent être attribués à des responsables, priorisés et appliqués sur des milliers de dépôts.

Aucun mot unique comme « scanner » ne couvre automatiquement toutes ces couches.

En 2026, les plateformes d'entreprise les plus souvent envisagées incluent notamment :

• OpenText Fortify,
• Checkmarx One,
• Veracode,
• Snyk,
• GitHub Code Security et GitHub Secret Protection, historiquement désignés sous le nom commun de GitHub Advanced Security,
• Semgrep.

À cela s'ajoutent des solutions complémentaires, telles que :

• SonarQube Advanced Security,
• Burp Suite DAST,
• Invicti.

Cet article n'attribue pas de notes fictives du type « 9,8/10 », ne répète pas les déclarations des fournisseurs concernant l'efficacité en pourcentage et ne désigne pas de gagnant sur la base du nombre de lignes dans une grille tarifaire.

Le meilleur outil AppSec n'est pas le produit doté du plus grand tableau de fonctionnalités. C'est le produit, ou l'ensemble de produits, qui détecte les problèmes importants dans la pile réelle de l'organisation, s'inscrit dans son modèle de déploiement et mène à des corrections, au lieu de générer un backlog ingérable.

Le périmètre des produits et la documentation ont été vérifiés le 23 juillet 2026.

TL;DR

Scénario	Point de départ le plus naturel
Grande organisation réglementée, legacy, exigences de déploiement et SAST/DAST étendu	Fortify
Une plateforme large couvrant le code, les dépendances, l'IaC, les secrets, les API, les conteneurs et le DAST	Checkmarx One
Programme AppSec managé avec des politiques centralisées, SAST, SCA et DAST	Veracode
Developer-first pour le code, l'open source, les conteneurs, l'IaC et désormais aussi le DAST/API	Snyk
Organisation travaillant principalement sur GitHub et souhaitant la sécurité dans les pull requests	GitHub Code Security + Secret Protection
SAST/SCA/secrets rapide et configurable, avec des règles personnalisées	Semgrep
Entreprise utilisant déjà SonarQube comme quality gate	SonarQube Advanced Security en extension
DAST d'entreprise dédié pour le web et les API	Burp Suite DAST ou Invicti, évalués dans un POC séparé

Ce n'est pas un tableau de gagnants inconditionnels. C'est une carte des produits dont l'architecture correspond le mieux à un problème donné.

1. Distinguez d'abord les types de tests

OWASP ASVS constitue une base ouverte pour définir les exigences et le niveau de rigueur de la vérification de la sécurité des applications. Il ne suppose pas qu'un seul outil automatique vérifiera toutes les exigences.

SAST

Le Static Application Security Testing analyse le code ou les artefacts sans exécuter l'application.

Il peut détecter notamment :

• le flux de données non fiables vers un sink dangereux,
• les erreurs de validation,
• les hardcoded credentials,
• les problèmes cryptographiques,
• les API dangereuses,
• certaines erreurs d'autorisation et de logique.

Le SAST ne confirme pas automatiquement qu'une vulnérabilité est exploitable dans un environnement runtime concret.

SCA

Le Software Composition Analysis analyse les dépendances, les paquets, les versions, les vulnérabilités et les licences open source.

Le SCA répond à une question différente de celle du SAST :

SAST: czy nasz kod zawiera niebezpieczny wzorzec lub przepływ?
SCA: czy używany komponent ma znaną podatność albo ryzyko licencyjne?

Secrets scanning

Il détecte les clés, les tokens, les mots de passe et d'autres données d'authentification dans le code actuel, l'historique Git et parfois avant l'exécution d'un push.

IaC scanning

Il analyse Terraform, Kubernetes, Helm, CloudFormation, ARM et d'autres déclarations d'infrastructure.

Container scanning

Il analyse les images, le système de base, les paquets système, les dépendances applicatives et parfois la configuration du workload.

DAST

Le Dynamic Application Security Testing teste l'application en cours d'exécution depuis l'extérieur. OWASP définit le DAST comme un test black-box qui communique avec l'application via son interface web.

Le DAST peut trouver :

• les problèmes de configuration du serveur,
• les vulnérabilités visibles uniquement en runtime,
• une partie des erreurs d'authentification et de session,
• les injections SQL,
• les XSS,
• les vulnérabilités des endpoints d'API,
• les problèmes dépendant du déploiement réel.

Il ne voit pas le code source et ne remplace pas la revue de code.

ASPM et gouvernance

L'Application Security Posture Management agrège les résultats, attribue les applications à des responsables, corrèle les findings et aide à appliquer des politiques à l'échelle de l'organisation.

Une plateforme peut disposer d'un dashboard étendu tout en s'appuyant sur des moteurs de profondeur variable. La simple présence d'une interface commune ne prouve pas une qualité égale de tous les modules.

2. Comment cette comparaison a-t-elle été établie ?

Une fonctionnalité n'a été inscrite dans le tableau que lorsqu'elle a été confirmée dans la documentation officielle actuelle du fournisseur.

Nous n'utilisons pas comme preuve :

• les classements sponsorisés,
• les publications de partenaires commerciaux,
• les chiffres d'« accuracy » sans méthodologie indépendante,
• les déclarations « zero false positives »,
• les récompenses marketing génériques,
• un résultat isolé de l'OWASP Benchmark fourni par l'éditeur.

Symboles de la matrice

Symbole	Signification
●	partie native et confirmée de l'offre actuelle
◐	fonctionnalité disponible via un module distinct, un module complémentaire ou avec un périmètre nettement plus restreint
-	absence de module natif confirmé dans l'offre analysée
POC	impossible à évaluer honnêtement sans test sur la pile de l'organisation

3. Matrice du périmètre des produits

Plateforme	SAST	SCA	Secrets	IaC	Containers	DAST / API runtime	Gouvernance centralisée
Fortify	●	●	◐	-	-	●	●
Checkmarx One	●	●	●	●	●	●	●
Veracode	●	●	●	●	●	●	●
Snyk	●	●	◐	●	●	●	●
GitHub Code Security + Secret Protection	●	●	●	-	-	-	●
Semgrep	●	●	●	-	-	-	●
SonarQube Advanced Security	●	●	●	-	-	-	●
Burp Suite DAST	-	-	-	-	-	●	●
Invicti	-	-	-	-	-	●	●

Le tableau montre le périmètre, pas l'efficacité.

Exemple : un produit doté d'un SAST et d'un DAST natifs ne l'emporte pas nécessairement sur la combinaison du meilleur outil au niveau du dépôt et d'un DAST séparé. À l'inverse, deux produits distincts peuvent augmenter le coût d'intégration, le nombre de dashboards et la difficulté de déduplication des résultats.

4. OpenText Fortify

L'offre actuelle de Fortify comprend des solutions distinctes pour :

• le SAST,
• le DAST,
• le Software Composition Analysis,
• le Fortify on Demand managé.

OpenText décrit Fortify SAST comme une solution d'entreprise dotée de modèles de déploiement flexibles. Fortify DAST teste les applications, les API et les services en cours d'exécution. Fortify Software Composition Analysis est un produit distinct qui analyse les composants open source. Fortify on Demand met à disposition, en mode service, notamment le SAST, le DAST et le MAST.

La distinction terminologique la plus importante

Le nom historique Fortify Static Code Analyzer était souvent abrégé en « Fortify SCA ».

Dans le nouveau contexte, SCA désigne toutefois Software Composition Analysis.

C'est pourquoi, dans la documentation et lors de la commande, il faut distinguer précisément :

Fortify SAST / Static Code Analyzer
Fortify Software Composition Analysis

Ce ne sont pas les mêmes tests.

Points forts de Fortify

• un SAST et un DAST étendus au sein d'une même famille de produits,
• la possibilité de déploiements exigeant un contrôle accru de l'infrastructure,
• une offre SaaS via Fortify on Demand,
• la prise en charge des environnements d'entreprise traditionnels et des piles plus anciennes,
• la gestion centralisée du programme AppSec.

Dans la version SAST 26.2, OpenText a notamment annoncé des extensions concernant COBOL, Fortran, C++23, PHP 8.5, Kotlin 2.3 et Swift 6.3. C'est important pour les organisations disposant d'un mélange de systèmes modernes et plus anciens.

Limites à vérifier

• la durée d'un scan complet et incrémental sur vos propres monorepos,
• les exigences relatives aux builds et à la préparation des artefacts,
• la qualité de l'intégration avec les pull requests,
• le coût opérationnel de l'infrastructure self-managed,
• la manière de gérer l'IaC et les conteneurs, s'ils sont requis,
• l'ergonomie du triage pour les développeurs.

Pour qui ?

Fortify est un candidat naturel pour :

• les banques,
• les opérateurs télécoms,
• l'administration,
• les grandes organisations ayant des exigences en matière de déploiement et de données,
• les environnements avec Java, .NET, C/C++, COBOL et d'autres technologies à longue durée de vie.

Cela ne signifie pas une victoire automatique dans une nouvelle startup cloud-native. Cela signifie une bonne adéquation du modèle produit à une entreprise complexe.

5. Checkmarx One

Checkmarx One est positionné comme une large plateforme d'Application Security couvrant les étapes allant de l'écriture du code au runtime.

Les documents officiels confirment notamment :

• le SAST,
• le SCA,
• la secrets detection,
• l'IaC security,
• l'API Security,
• le Container Security,
• le DAST,
• la software supply chain security.

Le principal avantage

Checkmarx One est l'un des candidats les plus naturels lorsque l'objectif de l'achat est de réduire le nombre de fournisseurs.

Une seule architecture peut couvrir :

kod własny
+ zależności
+ sekrety
+ IaC
+ kontenery
+ API
+ działającą aplikację

Que faut-il vérifier dans un POC ?

L'étendue du portefeuille ne répond pas à la question de la profondeur.

Il faut mesurer séparément :

• le SAST sur les langages essentiels pour l'entreprise,
• la qualité de la reachability dans le SCA,
• la couverture de l'IaC,
• la prise en charge des registries privés et des images de base,
• le scan DAST authentifié,
• l'import d'OpenAPI, de GraphQL et les workflows réels,
• la manière dont les résultats sont corrélés entre les modules,
• la data residency et le traitement du code.

Pour qui ?

Il vaut la peine de placer Checkmarx One en haut de la liste lorsque :

• l'entreprise souhaite un unique fournisseur AppSec stratégique,
• elle a besoin de plus que du SAST et du SCA,
• elle dispose de nombreuses équipes, langages, clouds et dépôts,
• une équipe de sécurité centrale souhaite une gouvernance sur l'ensemble du SDLC.

Un verdict honnête

Le périmètre confirmé le plus large ne signifie pas « le meilleur moteur pour tout ». Checkmarx One ne devrait l'emporter qu'après avoir prouvé que les deux ou trois modules les plus importants pour l'organisation sont suffisamment bons.

6. Veracode

Veracode propose une plateforme d'Application Risk Management et des produits confirmés pour :

• le SAST,
• le SCA,
• le DAST,
• le Container Security,
• le scan de l'IaC,
• la détection des secrets,
• les workflows de scan et la gestion centralisée des résultats.

Veracode SAST analyse les applications de manière statique, le DAST teste les applications et les API en cours d'exécution, et Veracode Container Security scanne les conteneurs, les fichiers IaC et les secrets exposés.

Points forts

• un modèle de plateforme managé et cohérent,
• SAST, SCA et DAST au sein d'un même programme,
• des politiques et des rapports centralisés,
• la réduction du besoin de maintenir une lourde infrastructure de scanners,
• une approche adaptée aux organisations qui préfèrent le SaaS.

Une caractéristique architecturale importante

Veracode est associé depuis des années à l'analyse d'artefacts binaires ou de bytecode préparés dans une partie des workflows statiques. La configuration actuelle dépend du langage et du type de scan, c'est pourquoi le POC doit reproduire le processus de build réel de l'organisation, et non uniquement un petit projet de démonstration.

Limites à vérifier

• la rapidité avec laquelle le développeur obtient un résultat après une modification,
• la charge de travail nécessaire pour préparer un artefact,
• le comportement du Pipeline Scan par rapport au policy scan complet,
• la prise en charge des monorepos,
• l'intégration avec un SCM et un CI self-hosted,
• les exigences relatives à l'envoi des artefacts,
• la qualité et le périmètre de Container Security, de l'IaC et des secrets sur les artefacts réels de l'organisation.

Pour qui ?

Veracode est un candidat solide pour une organisation qui souhaite :

• un AppSec managé et centralisé,
• une combinaison de SAST, SCA et DAST,
• des politiques et des rapports sans construire sa propre plateforme de scan,
• un modèle cohérent pour de nombreuses équipes.

7. Snyk

L'offre actuelle de Snyk est plus large que l'association antérieure au seul dependency scanning.

Les produits officiels comprennent :

• Snyk Code - SAST,
• Snyk Open Source - SCA et license compliance,
• Snyk Container,
• Snyk IaC,
• Snyk API & Web - DAST cloud-based pour les applications et les API.

Snyk dispose également d'une couche de gestion et de priorisation du risque applicatif.

Points forts

• l'intégration avec l'IDE, la CLI, le SCM et le CI/CD,
• l'accent mis sur le workflow du développeur,
• une seule famille de produits pour le code, les dépendances, les conteneurs, l'IaC et le runtime DAST,
• des remediation guidance,
• un contexte concernant la reachability, l'exploit et le déploiement dans certains modules,
• une bonne adéquation avec le cloud-native et le platform engineering.

Une mise à jour importante par rapport aux anciennes comparaisons

L'affirmation « Snyk n'a pas de DAST » est obsolète en 2026.

Snyk API & Web est officiellement décrit comme une solution DAST cloud pour les applications web et les API en cours d'exécution.

C'est pourquoi une comparaison actuelle doit évaluer sa couverture réelle par rapport aux produits dédiés Burp Suite DAST, Invicti, Fortify DAST, Checkmarx DAST et Veracode DAST.

Que vérifier ?

• la couverture des langages en SAST,
• la précision et la durée du scan sur un dépôt réel,
• la qualité des fix suggestions,
• le SCA pour les transitive dependencies et les monorepos,
• les images de base personnalisées et les registries privés,
• Terraform, Kubernetes, Helm et CloudFormation,
• le DAST pour les applications authentifiées et les API complexes,
• le modèle de données et la région d'hébergement,
• le coût total de plusieurs modules.

Pour qui ?

Snyk est un candidat naturel pour :

• les entreprises cloud-native,
• les équipes utilisant des conteneurs et l'IaC,
• les organisations souhaitant une sécurité proche du développeur,
• les équipes qui ont besoin d'une plateforme large mais ne veulent pas commencer par un SAST traditionnel et lourd.

8. GitHub Code Security et GitHub Secret Protection

Dans son modèle actuel, GitHub répartit les fonctionnalités payantes entre :

• GitHub Code Security,
• GitHub Secret Protection.

La documentation les décrit encore comme des produits GitHub Advanced Security.

GitHub Code Security comprend notamment :

• le code scanning,
• CodeQL,
• les fonctionnalités premium de Dependabot,
• la dependency review.

GitHub Secret Protection comprend notamment :

• le secret scanning,
• la push protection,
• les custom patterns,
• la détection de certains credentials non structurés.

CodeQL est un moteur d'analyse de code développé par GitHub. Dependabot peut créer des pull requests qui mettent à jour les dépendances vulnérables.

Le principal avantage

Les résultats sont disponibles là où le développeur :

• ouvre une pull request,
• examine le diff,
• applique la branch protection,
• mène la revue de code,
• exécute Actions,
• gère les responsables du dépôt.

Cela réduit les frictions organisationnelles.

Ce que GitHub ne remplace pas

L'offre native n'est pas un équivalent complet de :

• un DAST d'entreprise,
• le scan des workflows applicatifs en cours d'exécution,
• une suite dédiée d'IaC security,
• une plateforme complète de container security,
• un pentest manuel.

GitHub code scanning peut recevoir les résultats d'outils externes, mais l'agrégation de SARIF ne signifie pas que GitHub a lui-même effectué ces tests.

Pour qui ?

L'adéquation la plus forte apparaît lorsque :

• GitHub est le standard de toute l'organisation,
• la sécurité doit fonctionner dans les pull requests,
• CodeQL prend en charge les langages essentiels,
• l'équipe accepte d'ajouter un DAST séparé et éventuellement un scanner IaC/conteneurs.

Ensemble potentiel

GitHub Code Security
+ GitHub Secret Protection
+ dedykowany DAST
+ opcjonalny IaC/container scanner

Il peut être préférable à une plateforme large pour une entreprise qui souhaite exploiter au maximum l'écosystème GitHub existant.

9. Semgrep

La Semgrep AppSec Platform confirme trois produits principaux :

• Semgrep Code - SAST,
• Semgrep Supply Chain - SCA,
• Semgrep Secrets.

La plateforme s'intègre au SCM et au CI, permet la gestion des politiques et le blocage de certains problèmes dans les pull requests.

Le principal avantage

Semgrep permet de créer des règles personnalisées adaptées à :

• des frameworks internes,
• des wrappers de sécurité,
• des anti-patterns propres à l'entreprise,
• des règles d'architecture,
• des fonctions dangereuses,
• des processus d'autorisation.

Exemple de règle simplifiée :

rules:
  - id: internal-unsafe-query
    message: Use the approved parameterized database wrapper.
    severity: ERROR
    languages: [javascript]
    patterns:
      - pattern: db.raw($QUERY)

La facilité d'écriture des règles peut être plus importante qu'un millier de checks génériques supplémentaires.

Points forts

• un retour rapide dans le workflow du développeur,
• des règles configurables,
• SAST, SCA et secrets au sein d'une même plateforme,
• une application pertinente dans les monorepos et les piles modernes,
• la possibilité de déployer des guardrails spécifiques à l'organisation.

Limites

Semgrep n'est pas un DAST d'entreprise natif et ne remplace pas :

• le test d'une application en cours d'exécution,
• le crawling authentifié,
• les runtime API attacks,
• un container security complet,
• une suite dédiée d'IaC security.

Pour qui ?

Il vaut la peine de choisir Semgrep lorsque :

• l'équipe sécurité souhaite créer rapidement ses propres règles,
• la developer experience est une priorité,
• l'organisation accepte un ensemble d'outils assemblé,
• un DAST séparé et un scanner container/IaC font partie du plan.

10. SonarQube Advanced Security

Pendant des années, SonarQube a surtout été associé au code quality et à l'analyse statique.

En 2026, SonarQube Advanced Security étend l'offre d'entreprise avec :

• l'Advanced SAST,
• le Software Composition Analysis,
• des fonctionnalités supplémentaires de sécurité et de compliance.

La documentation et les release notes confirment également le développement de règles de secrets detection.

Quand est-ce pertinent ?

Lorsqu'une organisation utilise déjà SonarQube comme quality gate obligatoire, étendre la plateforme existante peut être opérationnellement plus simple que de déployer un nouveau dashboard pour chaque dépôt.

Ce qu'il ne faut pas présumer

SonarQube Advanced Security ne devient pas pour autant automatiquement :

• un DAST,
• une plateforme de tests web authentifiés,
• un container scanner complet,
• une plateforme IaC complète.

Rôle dans la comparaison

SonarQube est une solide alternative de consolidation pour les entreprises qui souhaitent combiner qualité et sécurité dans un processus existant. Il ne relève toutefois pas de la même catégorie que les plateformes larges couvrant le runtime.

11. Burp Suite DAST et Invicti

Le DAST doit être évalué séparément, car la qualité d'un scan dynamique dépend de :

• la crawl coverage,
• la prise en charge des SPA,
• l'authentification,
• le maintien de la session,
• l'enregistrement de workflows complexes,
• l'API discovery,
• l'import d'OpenAPI, de GraphQL ou de SOAP,
• le contrôle de l'intensité du scan,
• la vérification des findings,
• le fonctionnement au sein du réseau interne.

Burp Suite DAST

PortSwigger documente :

• l'intégration de CI-driven scans avec les plateformes prenant en charge les conteneurs,
• une variante cloud ainsi que self-hosted,
• une GraphQL API et une REST API pour l'intégration.

Un avantage naturel réside dans le lien avec l'écosystème Burp utilisé par les pentesters.

Invicti

Invicti est une plateforme DAST dédiée pour le web et les API. La documentation officielle décrit le discovery, le stateful API scanning et la proof-based validation.

Les déclarations de l'éditeur concernant la précision en pourcentage ne devraient pas être reportées dans une décision d'achat sans test indépendant.

Lequel est le meilleur ?

Il est impossible de répondre honnêtement sur la base d'une page produit.

Le POC doit couvrir :

• la connexion via SSO,
• la MFA,
• le rafraîchissement du token,
• les rôles des utilisateurs,
• un workflow en plusieurs étapes,
• les SPA,
• REST,
• GraphQL,
• l'upload,
• les webhooks,
• les endpoints internes,
• le risque de corruption des données.

12. Comparaison de l'adéquation organisationnelle

Critère	Fortify	Checkmarx One	Veracode	Snyk	GitHub	Semgrep
Entreprise réglementée et legacy	très naturel	naturel	naturel	dépend de la pile	comme couche dépôt	comme couche dépôt
Une plateforme large	large	très large	SAST/SCA/DAST	très large	non	non
Developer-first	POC	POC	POC	profil solide	très solide sur GitHub	très solide
Self-managed / contrôle de l'infrastructure	candidat solide	vérifier le modèle	modèle principalement managé	vérifier le module	GHES pour une partie des fonctionnalités	options enterprise
Legacy languages	profil solide	POC	POC	POC	dépend de CodeQL	dépend du langage
IaC et conteneurs	outils supplémentaires	modules natifs	module natif Container Security	modules natifs	outils supplémentaires	outils supplémentaires
DAST natif	oui	oui	oui	oui	non	non
Règles SAST personnalisées	possible, vérifier le coût	possible, POC	POC	POC	CodeQL queries	avantage clé

Un « profil solide » nécessite quand même un POC.

13. Peut-on désigner un seul gagnant ?

Pas de manière responsable.

On peut en revanche désigner les shortlists les plus logiques.

Shortlist A : une plateforme au périmètre large

Checkmarx One
Snyk
Fortify
Veracode

Il faut pondérer les modules. Exemple :

SAST              25%
SCA               15%
DAST i API        20%
IaC i containers  15%
developer UX      10%
governance        10%
deployment/data    5%

Si l'entreprise n'a besoin ni de l'IaC ni des conteneurs, leur poids devrait être nul. Il ne faut pas attribuer de points à un module qui ne résout aucun problème de l'organisation.

Shortlist B : GitHub-native

GitHub Code Security
GitHub Secret Protection
+ Burp Suite DAST lub Invicti
+ Snyk IaC/Container albo inny wyspecjalizowany scanner

Shortlist C : custom rules et developer-first

Semgrep Code + Supply Chain + Secrets
+ dedykowany DAST
+ osobne IaC/container security

Shortlist D : legacy et contrôle du déploiement

Fortify SAST + DAST + Software Composition Analysis

Il faut vérifier si les autres couches seront prises en charge par les outils d'infrastructure existants.

Shortlist E : SonarQube existant

SonarQube Advanced Security
+ dedykowany DAST
+ osobne IaC/container security, jeżeli potrzebne

14. Comment mener un POC honnête ?

L'OWASP Benchmark contient des jeux de tests et des outils pour évaluer l'accuracy, la coverage et la vitesse des scanners automatiques.

Il ne devrait toutefois pas être la seule base d'une décision :

• une partie des tests est synthétique,
• le Java Benchmark est maintenu sans modification significative des cas depuis de nombreuses années,
• le nouveau Benchmark pour Python a un niveau de maturité différent,
• le résultat ne mesure pas le workflow du développeur,
• il ne mesure pas la gouvernance,
• il ne reproduit pas les frameworks de l'entreprise.

OWASP Juice Shop est une application volontairement vulnérable en Node.js, Express et Angular, utile pour les exercices et pour tester les outils sur un frontend JavaScript et une REST API.

Ensemble de tests minimal

1. OWASP Benchmark pour un langage pris en charge.
2. OWASP Juice Shop pour le DAST.
3. Une application maison représentant la stack de production.
4. Un monorepo de taille réelle.
5. Un dépôt contenant :
   • des dépendances vulnérables,
   • un secret dans la version courante,
   • un secret dans l'historique Git,
   • un Dockerfile,
   • du Terraform,
   • du Kubernetes,
   • du code généré.
6. Un environnement en fonctionnement avec :
   • SSO,
   • plusieurs rôles,
   • REST et GraphQL,
   • une fonction d'upload,
   • un processus en plusieurs étapes.

15. Métriques du POC

Efficacité de détection

• true positives,
• false positives,
• false negatives,
• les doublons,
• les findings sans chemin d'exécution réel,
• les vulnérabilités de dépendances réellement atteignables.

Performance

• la durée du premier scan complet,
• la durée du scan d'une pull request,
• la durée après la modification d'une seule ligne,
• l'utilisation du CPU et de la RAM,
• le comportement sur un monorepo,
• le parallélisme.

Remediation

• si le résultat indique la source et le sink,
• s'il montre le data flow complet,
• si la correction est compatible avec le framework,
• si le développeur peut vérifier le résultat sans l'équipe AppSec,
• si le correctif automatique passe les tests,
• combien de résultats sont clôturés en « won't fix ».

Gouvernance

• RBAC,
• SSO et SCIM,
• audit log,
• des politiques par business unit,
• des exceptions avec date d'expiration,
• SLA,
• les applications et les responsables,
• l'intégration avec Jira ou un autre système,
• l'export des données,
• API,
• les rapports de compliance.

Déploiement et données

• SaaS, self-hosted ou hybride,
• la région des données,
• si le code sort de l'organisation,
• le mode de stockage des artefacts,
• les registries privés,
• les applications internes,
• le proxy,
• un air-gapped environment,
• le chiffrement,
• la rétention.

Coût total

Pas seulement le prix de la licence :

TCO =
licencja
+ infrastruktura
+ onboarding
+ tuning
+ triage
+ integracje
+ utrzymanie reguł
+ wsparcie
+ czas developerów

Un outil bon marché générant des milliers de findings non traités peut coûter plus cher qu'une plateforme dont le prix de licence est plus élevé.

16. Erreurs d'achat courantes

Acheter sur la base du nombre de langages

La « prise en charge d'un langage » peut signifier :

• un parseur de syntaxe,
• des règles de base,
• un interprocedural data flow complet,
• la prise en charge de frameworks spécifiques.

Le POC doit utiliser les frameworks de l'organisation.

Confondre SAST et SCA

Ce sont des techniques distinctes. L'abréviation similaire dans le nom historique de Fortify augmente encore le risque de confusion.

Compter chaque module de la même façon

Si l'entreprise n'utilise pas Terraform, le module IaC ne devrait pas améliorer la note.

Ne tester qu'une application de démonstration publique

Un petit benchmark ne reproduit pas :

• un monorepo,
• un custom framework,
• un package manager interne,
• un build system,
• le SSO,
• un réseau privé.

L'absence de test de la developer experience

Un outil peut trouver de bons problèmes mais échouer au déploiement à cause de :

• résultats disponibles après plusieurs heures,
• l'absence de commentaire dans la PR,
• une remediation incompréhensible,
• des suppressions compliquées,
• des builds instables.

Croire au chiffre marketing de false positives

Sans jeu de données public, configuration, version et définition du résultat, ce chiffre ne se prête pas à la comparaison.

Acheter un DAST sans résoudre l'authentification

Un scanner qui ne parvient pas à passer la connexion ne peut tester qu'un petit fragment public de l'application.

17. Recommandations selon le type d'entreprise

Banque, assurance, administration

Shortlist :

• Fortify,
• Checkmarx One,
• Veracode.

Priorités :

• le déploiement et les données,
• legacy languages,
• l'audit,
• la compliance,
• SAST et DAST,
• un support à long terme.

Entreprise SaaS utilisant GitHub

Shortlist :

• GitHub Code Security + Secret Protection,
• Snyk,
• Semgrep,
• un Burp Suite DAST séparé ou Invicti.

Priorités :

• PR feedback,
• la durée du scan,
• dependency updates,
• secrets,
• API et DAST,
• une friction minimale pour le développeur.

Cloud-native avec Kubernetes et Terraform

Shortlist :

• Snyk,
• Checkmarx One,
• en alternative, l'ensemble GitHub/Semgrep plus un IaC et un container security spécialisés.

Priorités :

• SCA,
• containers,
• IaC,
• private registries,
• runtime context,
• DAST/API.

Organisation disposant déjà de SonarQube

Shortlist :

• SonarQube Advanced Security,
• GitHub Code Security,
• Semgrep,
• un DAST dédié.

La décision doit répondre à la question de savoir si la consolidation de la qualité et de la sécurité est plus importante qu'un portefeuille plus large auprès d'un seul fournisseur.

18. Verdict final

Le meilleur candidat pour une plateforme large auprès d'un seul fournisseur

Checkmarx One dispose d'un périmètre très large et officiellement confirmé couvrant le code, l'open source, les secrets, l'IaC, les conteneurs, les API et le DAST.

Cela le qualifie pour un POC, mais ne lui donne pas une victoire automatique.

Le plus naturel pour le legacy et l'entreprise contrôlée

Fortify reste un candidat solide pour les grandes organisations réglementées et technologiquement hétérogènes.

Le programme managé le plus naturel couvrant le code et le runtime

Veracode est le choix logique pour une entreprise qui préfère une plateforme de service centralisée couvrant SAST, SCA, DAST ainsi qu'un module Container Security distinct avec IaC et secrets, plutôt que de maintenir plusieurs scanners.

Le plus naturel en cloud-native developer-first

Snyk dispose des modules confirmés Code, Open Source, Container, IaC ainsi que API & Web DAST. Les anciennes comparaisons qui omettent le DAST sont obsolètes.

La plus faible friction dans un environnement GitHub

GitHub Code Security et Secret Protection offrent l'intégration la plus étroite avec les dépôts et les pull requests, mais nécessitent une couche runtime DAST distincte.

Le meilleur candidat pour des guardrails personnalisés

Semgrep est particulièrement attractif lorsqu'une organisation souhaite créer et maintenir rapidement ses propres règles SAST, SCA et secrets au plus près du développeur.

DAST

Burp Suite DAST et Invicti doivent être comparés sur votre propre application. Il n'existe aucune base fiable pour désigner un gagnant inconditionnel sans test de l'authentification, des API, des workflows et de la couverture.

Le plus souvent, la meilleure solution d'entreprise ne sera pas un scanner unique, mais un ensemble consciemment conçu : couche dépôt + supply chain + runtime DAST + gouvernance.

19. Checklist de sélection

Périmètre

• Les types de tests nécessaires ont été définis.
• Le SAST et le SCA sont évalués séparément.
• On a déterminé si un DAST est nécessaire.
• On a déterminé si des secrets sont nécessaires.
• On a déterminé si l'IaC et les containers sont nécessaires.
• Les exigences d'API Security ont été établies.
• Les applications et les langages critiques ont été définis.

POC

• Chaque produit scanne le même code.
• Les mêmes versions et configurations sont utilisées.
• Le test inclut une application maison.
• Le test inclut un monorepo.
• Le test inclut une pull request.
• Le DAST passe l'authentification.
• Les rôles et les workflows sont testés.
• Les false positives ont été mesurés.
• Les false negatives ont été vérifiés manuellement.
• Le temps jusqu'à la correction a été mesuré.

Enterprise

• Le SSO, le SCIM et le RBAC ont été confirmés.
• L'audit log a été confirmé.
• Le modèle de données et la région ont été confirmés.
• L'intégration avec le SCM et le CI a été confirmée.
• L'accès aux applications privées a été confirmé.
• La prise en charge du proxy et des registries a été confirmée.
• La rétention des données a été confirmée.
• L'API et l'export ont été confirmés.
• Le modèle d'exceptions a été confirmé.
• Le TCO a été calculé, pas seulement la licence.

Déploiement

• Les responsables des findings ont été définis.
• Les SLA ont été définis selon le risque.
• Le nouveau code est séparé du backlog.
• Le quality gate ne bloque que les problèmes fiables.
• Il existe un processus de tuning des règles.
• Les exceptions ont une date d'expiration.
• Les résultats DAST sont dédupliqués avec le SAST.
• Le développeur reçoit le contexte et les instructions de correction.
• L'équipe mesure le fix rate, et non le nombre d'alertes.

20. Outils et ressources POLPROG

Il est utile de compléter les scanners automatiques par un contrôle de la couche publique :

• Santé du site aide à détecter les problèmes techniques, de SEO, de performance et d'accessibilité.
• Inspecteur des en-têtes de sécurité vérifie CSP, HSTS et d'autres protections des réponses HTTP.
• Inspecteur DNS et SSL analyse la couche du domaine et le TLS.
• FlowTrace aide à visualiser le parcours d'une requête à travers DNS, TLS, CDN, backend et rendu.
• La base de connaissances POLPROG contient des ressources sur la sécurité des applications et de l'infrastructure.