SAST, DAST, SCA, fuzzing : les outils classés par famille

Tu connais les familles, reste à choisir l'outil

Le billet précédent sur l'OWASP Top 10 et l'AppSec répondait à une question de principe : que font le SAST, le DAST et le SCA, et pourquoi les trois plutôt qu'un seul. La question suivante arrive vite, en général devant un fichier de pipeline vide : quel outil, concrètement, et branché où.

Ce billet est le catalogue. Pas un classement du meilleur outil, un rangement par famille avec ce que chaque outil regarde, où il tourne, et ce qu'il ne fera pas pour toi.

Le découpage suit la taxonomie du guide d'analyse de code de Stéphane Robert, qui range le sujet en SAST, DAST, SCA et fuzzing. J'emprunte sa grille parce qu'elle est stable et qu'elle colle à la façon dont les outils se branchent réellement dans une chaîne CI/CD. Les commentaires et les arbitrages qui suivent sont les miens.

Quatre familles, donc, plus une cinquième qui les recoupe toutes : les conteneurs. Un conteneur embarque du code, des dépendances, une configuration et parfois un secret oublié, ce qui en fait le point de rencontre des quatre autres analyses.

Un scanner ne vaut que par l'endroit où il tourne. Le meilleur SAST du marché branché sur une pull request que personne ne lit produit exactement zéro sécurité.

Le tout s'inscrit dans la démarche décrite dans Qu'est-ce que le DevSecOps ? : les contrôles sont automatisés, précoces, et leurs résultats remontent là où la décision se prend.

Deux sujets restent hors périmètre ici : les agents d'exécution (RASP et IAST, qui instrumentent l'application en cours de fonctionnement) et la chaîne de confiance des artefacts (signature, attestations de provenance, cadre SLSA), qui méritent leur propre billet.

Comment lire ce panorama

Chaque tableau suit les mêmes colonnes, et chacune répond à une question que tu te poses avant d'installer quoi que ce soit.

Licence reste volontairement grossière : Open source, Freemium ou Commercial. Aucun prix, aucun quota, parce que ces valeurs changent plus vite qu'un billet de blog. Freemium signifie qu'une version utilisable existe sans payer, avec des limites qui apparaissent à l'usage.

Cibles dit ce que l'outil sait lire : des langages, des formats de fichiers, des images, un schéma d'API. C'est le premier filtre. Un scanner excellent qui ne parle pas ta stack ne sert à rien.

Intégration dit où il tourne : en pre-commit sur le poste, en CI, dans l'IDE, dans le registre d'images, en service hébergé. C'est le critère que l'on sous-estime le plus, alors que c'est lui qui détermine si l'outil sera utilisé ou contourné.

Point fort ou limite donne la raison de le choisir, ou la raison de ne pas s'en contenter. Court, parce qu'un tableau n'est pas une fiche produit.

Le placement dans la chaîne compte plus que la marque. Un outil qui rend son verdict trois heures après le commit ne changera pas le comportement de l'équipe.

Le schéma ci-dessous donne le calendrier d'exécution. Il ne décrit pas un pipeline complet, seulement les cinq moments où une famille d'analyse a du sens.

La flèche de retour est la partie que l'on oublie en dessinant un pipeline. Une CVE publiée trois semaines après la mise en production, ou un crash trouvé par un fuzzer qui tourne la nuit, doivent revenir au début de la chaîne. Sinon tu as un pipeline de conformité, pas un dispositif de sécurité.

SAST : trois domaines, pas un seul

Le SAST analyse sans exécuter. Il lit des fichiers, en construit une représentation, et cherche des motifs dangereux ou des chemins de données suspects entre une entrée non fiable et une opération sensible.

Réduire le SAST au code applicatif est l'erreur la plus fréquente. Dans un dépôt moderne, trois matières distinctes se lisent à froid : le code, la description de l'infrastructure, et les secrets qui traînent dans les deux.

Le SAST voit tout ce qui est écrit et rien de ce qui se passe. Il signale des chemins théoriquement dangereux, à toi de dire lesquels sont réellement atteignables.

Code applicatif

Les généralistes couvrent beaucoup de langages avec un moteur unique. C'est le socle, celui qui tourne sur toute la base de code.

Trois noms manquent à cette liste et se croisent surtout dans les grands comptes, l'embarqué et l'industrie : Fortify d'OpenText, Coverity et Klocwork. Analyses profondes, licences lourdes, et une intégration CI qui demande du travail.

Les spécialisés, eux, ne parlent qu'un langage, mais ils en connaissent les idiomes et les pièges. Ils coûtent quelques secondes de CI et se posent volontiers en complément d'un généraliste.

Côté PHP, Psalm propose une analyse de teinte pour suivre une entrée non fiable jusqu'à une opération sensible. PHPStan reste centré sur le typage, ce qui élimine déjà une classe entière de bugs mais ne remplace pas un scanner de sécurité.

Infrastructure as Code

Un bucket public, un groupe de sécurité ouvert sur le monde, un conteneur qui tourne en root : ces failles ne sont pas dans le code applicatif, elles sont dans les fichiers qui décrivent la plateforme. Ce sont des fichiers texte, donc du SAST.

Secrets

Une clé d'API commitée est un incident, pas une alerte. La détection se joue à deux endroits : sur le poste avant le commit, et en CI sur l'historique complet, parce qu'un secret retiré au commit suivant reste lisible dans les objets Git.

Détecter ne suffit pas. Un secret trouvé dans l'historique doit être révoqué et remplacé, jamais simplement supprimé du fichier. Et si des secrets réapparaissent régulièrement dans le code, c'est qu'il manque un coffre en amont.

Côté stockage, Vault centralise et distribue des identifiants dynamiques, SOPS chiffre des fichiers de configuration versionnés, Sealed Secrets permet de committer un secret Kubernetes sans le révéler, et External Secrets synchronise un coffre externe vers le cluster.

Quatre critères suffisent à trancher entre tous ces outils.

• Langages et formats couverts. Un scanner qui ignore la moitié de ton dépôt donne un faux sentiment de couverture. Vérifie la liste avant le tableau comparatif.
• Règles custom et faux positifs. Le taux de détection annoncé compte moins que ta capacité à écrire une règle métier et à taire une alerte de façon durable et tracée.
• pre-commit ou pull request. Le pre-commit donne un retour en secondes mais reste contournable. La pull request est le point de contrôle qui compte, parce qu'il est visible et opposable.
• Stratégie de blocage. Bloque sur Critical et High, alerte sur Medium, ignore le reste au démarrage. Un pipeline qui casse sur tout est désactivé en deux semaines.

DAST : trois types de scanners

Le DAST attaque l'application en fonctionnement, sans regarder son code. Il envoie des requêtes malformées, observe les réponses, et conclut. Trois profils d'outils cohabitent sous ce sigle, et ils ne servent pas au même usage.

Les scanners automatisés explorent l'application puis rejouent des attaques génériques sur ce qu'ils ont trouvé.

Tenable Web App Scanning complète la liste côté suites d'entreprise, dans la même logique d'intégration à un inventaire existant.

Les scanners à templates fonctionnent autrement : ils ne raisonnent pas, ils rejouent une bibliothèque de signatures.

Les proxies d'interception, enfin, ne scannent pas : ils te placent au milieu du trafic pour comprendre et rejouer.

Trois réglages décident du résultat. Le mode d'abord : un scan baseline se contente de parcourir l'application et de signaler les problèmes passifs en quelques minutes, un scan d'API part d'une définition OpenAPI, un scan complet lance les attaques actives et prend des heures. Commence par le baseline en CI, garde le complet pour une exécution nocturne.

L'authentification ensuite. Un scanner non authentifié ne voit que les pages publiques, soit la partie la moins intéressante. Fournir un jeton valide et un moyen de le renouveler est ce qui sépare un rapport décoratif d'un rapport utile.

Les exclusions enfin. Sans liste noire, le scanner trouvera le bouton de déconnexion et perdra sa session, ou déclenchera un endpoint destructeur. Excluer /logout, les suppressions en masse et les envois de mails fait partie de la configuration initiale.

docker run -v $(pwd):/zap/wrk/:rw -t ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py -t https://recette.exemple.internal -r rapport.html

Un DAST ne trouve que ce qu'il atteint. S'il ne sait pas s'authentifier ni parcourir ton application, son rapport vide ne veut pas dire que tout va bien.

Et une règle sans exception : jamais sur la production. Un scan actif crée des comptes, remplit des formulaires, déclenche des traitements. Il s'exécute sur une recette dont les données sont jetables.

SCA : inventorier avant de scanner

Le SCA répond à une question simple qui a une réponse difficile : qu'est-ce que mon application embarque exactement. Tout le reste, la corrélation avec les bases de failles, le calcul de sévérité, la remédiation, découle de cet inventaire.

Les scanners en ligne de commande sont le point d'entrée. Ils lisent un fichier de verrouillage ou un arbre de dépendances, et le confrontent à une base de vulnérabilités.

Un scanner CLI dit ce qui est vulnérable aujourd'hui, au moment où il tourne. Une plateforme, elle, garde l'inventaire et le réévalue quand une nouvelle faille est publiée. C'est le rôle de Dependency-Track, qui ingère des SBOM au format CycloneDX et sait donc te dire, sans relancer un build, quels projets embarquent le composant qui vient d'exploser.

syft dir:. -o cyclonedx-json > sbom.json
grype sbom:sbom.json --fail-on high

Les suites commerciales ajoutent la remédiation guidée, le volet licences et le suivi de conformité.

Deux outils sont souvent rangés ici par erreur : Dependabot et Renovate. Ils ne scannent pas, ils mettent à jour. Ils ouvrent une pull request quand une version plus récente existe, ce qui règle une bonne part du problème sans jamais produire d'inventaire. Un SCA détecte, un updater corrige, les deux sont complémentaires.

Reste la question de l'inventaire lui-même. Syft génère un SBOM à partir d'un répertoire ou d'une image, au format CycloneDX ou SPDX. Le premier porte nativement des informations de vulnérabilité et de VEX, le second est un standard normalisé très présent côté conformité.

VEX sert à dire « cette CVE est présente mais pas exploitable chez nous », avec une justification tracée. Sans ce mécanisme, une équipe finit par ignorer un rapport dont l'essentiel des lignes est hors sujet.

Un dernier point structure tout le reste : la différence entre dépendances directes et transitives. Tu déclares une quinzaine de bibliothèques, ton node_modules en contient mille. La quasi-totalité des alertes SCA porte sur des composants que tu n'as jamais choisis, souvent tirés à trois niveaux de profondeur. D'où l'importance de savoir remonter la chaîne pour identifier quelle dépendance directe mettre à jour.

Fuzzing : ni SAST ni DAST

Le fuzzing occupe une case à part. Il exécute le code, comme un DAST, mais il vise une fonction ou un parseur plutôt qu'une URL, et il génère lui-même ses entrées au lieu de rejouer un catalogue. Son terrain de prédilection : tout ce qui lit un format binaire, un protocole ou une entrée non structurée.

La distinction compte au moment de choisir. Un fuzzer coverage-guided finit par atteindre les branches profondes d'un parseur, mais il lui faut une cible instrumentable. Un fuzzer structure-aware franchit d'emblée les validations d'entrée, ce qui le rend bien plus efficace sur une API qui rejette d'emblée les requêtes aléatoires.

Les sanitizers méritent une mention à part : sans eux, un fuzzer trouve une entrée qui plante, ou pire, une entrée qui corrompt la mémoire sans rien signaler. Avec eux, chaque anomalie devient un rapport exploitable.

Le fuzzing prouve la présence de bugs, jamais leur absence. Une campagne sans crash signifie que le fuzzer n'a rien trouvé dans le temps qui lui a été donné, pas que le code est sûr.

Une campagne se juge donc sur la durée, la qualité du corpus initial et la couverture atteinte. C'est ce qui explique que le fuzzing tourne en continu plutôt qu'à chaque commit. Le contrôle Fuzzing d'OpenSSF Scorecard vérifie d'ailleurs simplement qu'un projet en fait, signe qu'il s'agit désormais d'un critère de maturité et non d'une curiosité de chercheur.

Conteneurs : la famille transverse

Une image de conteneur est un empilement : une distribution de base, ses paquets système, tes dépendances applicatives, ton code, et une configuration d'exécution. Chaque couche relève d'une famille d'analyse déjà vue, d'où le statut particulier de cette catégorie.

Le registre est l'endroit le plus rentable pour scanner : toutes les images y passent, y compris celles construites hors de ta CI. Harbor intègre nativement cette analyse et sait refuser la récupération d'une image dont la sévérité dépasse un seuil, ce qui transforme le rapport en garde-fou effectif.

La configuration de construction, elle, relève des outils déjà cités côté IaC : hadolint sur le Dockerfile, Dockle sur l'image produite. Les deux répondent à des questions différentes, l'un sur ce que tu as écrit, l'autre sur ce que tu as obtenu.

Côté plateformes, Aqua, Sysdig, Prisma Cloud et Wiz couvrent la chaîne complète, du scan d'image à la posture du cluster et des comptes cloud. Elles s'adressent à des parcs où le nombre d'images rend le suivi manuel impossible.

Scanner une image ne dit rien de ce qu'elle fait une fois démarrée. Un conteneur sans CVE peut très bien lancer un shell inattendu à trois heures du matin.

Cette surveillance du comportement à l'exécution est un autre métier, celui de Falco et des outils de détection runtime, hors périmètre de ce panorama.

Plateformes ASPM : tout agréger

Une fois les familles précédentes en place, un nouveau problème apparaît : sept outils, sept formats de rapport, sept listes de vulnérabilités qui se recoupent partiellement, et aucune vue d'ensemble. C'est le créneau de l'ASPM (Application Security Posture Management) : agréger, dédupliquer, prioriser et suivre la correction.

Cycode, Apiiro et ArmorCode occupent le même segment, sur la même promesse d'agrégation et de priorisation. Je n'ai pas de retour d'usage à en donner.

Une plateforme ASPM remplace la glu entre les outils, pas les outils eux-mêmes. Sous le capot, ce sont toujours un SAST, un SCA et un scanner d'images qui produisent les résultats.

Le critère de décision est prosaïque : si tu passes plus de temps à recoller des rapports qu'à corriger des failles, la plateforme se justifie. Avant ce seuil, DefectDojo et un tableur suffisent souvent.

Ouverture : l'IA entre dans la chaîne

Trois évolutions récentes touchent directement l'outillage décrit plus haut. Aucune ne remplace une famille existante, toutes en déplacent l'usage.

L'IA ne supprime pas les faux positifs, elle en change la nature. Une alerte fausse coûte cinq minutes de lecture, un correctif faux entre en production.

Les scanners assistés par IA

L'assistance porte sur les deux tâches les plus ingrates de l'AppSec : trier des alertes et écrire le correctif.

Semgrep Assistant et SonarQube AI CodeFix jouent sur le même terrain, respectivement pour le tri des résultats et la proposition de correctif dans l'interface de l'outil.

Le déplacement est net : le travail du relecteur glisse de « lire les alertes » à « valider les correctifs proposés ». Le second exercice est plus rapide mais plus dangereux, parce qu'un correctif plausible et faux passe plus facilement qu'une alerte incompréhensible.

MCP : brancher les scanners sur les agents

Le Model Context Protocol est un protocole ouvert qui standardise la façon dont un modèle accède à des outils et à des données externes, via des serveurs déclarés côté client. Deux mouvements opposés en découlent côté sécurité.

Le second mouvement mérite qu'on s'y arrête. Un serveur MCP installé sur ton poste ou dans ton agent est du code tiers qui reçoit du contexte, obtient des jetons et exécute des actions. C'est un point d'entrée de chaîne d'approvisionnement, au même titre qu'un paquet npm, avec une surface d'attaque particulière : la description d'un outil est lue par le modèle, donc elle peut contenir des instructions.

La discipline à appliquer est celle que tu appliques déjà aux dépendances. Épingler les versions, vérifier l'origine, scanner les secrets exposés dans la configuration, et relire ce qu'un serveur déclare avant de l'autoriser.

Tester les LLM et les agents

Quand ton application expose un modèle, les familles classiques ne couvrent plus le risque principal. Un prompt système contourné ne se voit ni dans le SAST ni dans le SCA.

Le OWASP Top 10 for LLM Applications sert de carte des risques, exactement comme le Top 10 web sert de carte pour une API. Les outils ci-dessous en sont le pendant outillé.

La bonne façon de les situer : ce sont les DAST des applications IA. Ils attaquent un système en fonctionnement, depuis l'extérieur, sans rien savoir de ses poids ni de son prompt. Et comme un DAST, ils ne prouvent rien, ils explorent.

Quelle combinaison selon ton contexte

Personne n'installe trente outils. La bonne question est celle du premier lot, cohérent et tenable, quitte à l'étendre ensuite.

Une remarque sur l'ordre d'installation. Commence toujours par la détection de secrets, parce que c'est le contrôle au meilleur rapport valeur sur effort, puis le SCA, parce que la majorité des vulnérabilités exploitables vient des dépendances. Le SAST et le DAST arrivent ensuite, quand l'équipe a pris l'habitude de traiter les alertes plutôt que de les accumuler.

Un outil de plus dans un pipeline dont personne ne lit les résultats dégrade la sécurité, parce qu'il fabrique la croyance qu'un contrôle existe.

Ce panorama reste théorique tant qu'il n'est pas confronté à une installation réelle. C'est l'objet du prochain billet côté lab, la cartographie de mon SOC homelab en sept couches, avec ce que j'ai réellement déployé et surtout ce qui manque encore.

Points clés

• Le SAST couvre trois domaines, pas un seul : le code applicatif, l'Infrastructure as Code et les secrets. Négliger les deux derniers laisse une base de code propre sur une plateforme ouverte.
• Le DAST regroupe trois profils d'outils : scanners automatisés, scanners à templates et proxies d'interception. Sans authentification configurée ni exclusions, son rapport ne vaut rien, et il ne tourne jamais sur la production.
• Le SCA commence par l'inventaire. Un SBOM versionné et une plateforme qui le réévalue valent mieux qu'un scan ponctuel, et un updater comme Renovate corrige sans jamais scanner.
• Le fuzzing est une campagne, pas une étape de CI. Il prouve la présence de bugs, jamais leur absence, et n'a de sens qu'associé à des sanitizers et à un corpus soigné.
• L'IA déplace le travail plus qu'elle ne le supprime : correctifs à valider plutôt qu'alertes à lire, serveurs MCP à traiter comme des dépendances, applications LLM à tester avec leur propre outillage.

Pour aller plus loin

• Le guide de Stéphane Robert, dont ce billet reprend la taxonomie : SAST, DAST, SCA et fuzzing
• OWASP Source Code Analysis Tools et OWASP Vulnerability Scanning Tools, les listes communautaires de référence
• OWASP Top 10 pour la carte des risques web, et OWASP Top 10 for LLM Applications pour son équivalent côté IA
• La spécification du Model Context Protocol, pour comprendre ce qu'un serveur MCP expose réellement
• Sécuriser le code et les API : OWASP Top 10, SAST, DAST, SCA, le billet qui pose les familles avant ce catalogue
• Qu'est-ce que le DevSecOps ?, pour replacer tout cet outillage dans une démarche d'équipe