Aller au contenu principal

Guide

Qu'est-ce que le SAST ?

Le Static Application Security Testing (SAST) lit le code source et signale des patterns de vulnérabilité sans jamais exécuter le programme. Pas d'environnement de test, pas de requêtes forgées, pas de runtime — juste le code, examiné ligne par ligne, fonction par fonction.

Ce que fait réellement le SAST

Un moteur SAST parse les fichiers source en arbre syntaxique abstrait (AST), puis applique des règles sur cet arbre : des correspondances de pattern pour des appels de fonction connus comme dangereux, du taint tracking qui suit une valeur depuis une source non fiable (un paramètre de requête, un champ de formulaire) jusqu'à un sink dangereux (une requête SQL, une commande shell, un chemin de fichier), et sur les moteurs plus avancés, un dataflow cross-file qui relie une source dans un fichier à un sink dans un autre. Rien ne s'exécute. C'est ce qui rend le SAST utilisable avant même qu'un environnement de test n'existe — il tourne sur un laptop, dans un job CI, ou sur un codebase qui n'a jamais été déployé.

SAST vs DAST vs IAST vs SCA

Ces quatre acronymes sont utilisés de manière interchangeable dans le marketing éditeur. Ils testent des choses différentes, à des moments différents, et aucun ne remplace les autres.

Catégorie Quand ça s'exécute Ce que ça trouve
SAST Avant le build — sur le code source Patterns de vulnérabilité dans le code : injection, secrets en dur, crypto faible, désérialisation non sécurisée.
DAST Contre une application qui tourne Comportement runtime : comment l'app répond réellement à des requêtes HTTP forgées, contournement d'auth, headers mal configurés.
IAST Pendant l'exécution des tests, instrumenté Un hybride — observe les vrais chemins de code pendant que les tests tournent, combinant visibilité source et confirmation runtime.
SCA Contre l'arbre de dépendances CVE connues dans les bibliothèques tierces — pas votre code, du code que vous avez importé.

Un programme de sécurité mature superpose plusieurs de ces couches. Le SAST est généralement la première car il s'exécute le plus tôt — avant même qu'il y ait quelque chose à déployer ou attaquer.

Ce qu'un outil SAST devrait réellement couvrir

Tous les scanners qui se disent « SAST » ne couvrent pas le même terrain. Une checklist courte et concrète :

  • Mapping aux standards — findings tagués CWE au minimum ; mapping OWASP Top 10, ISO 27001, ASVS ou NIST CSF si vous avez besoin de preuves de conformité, pas juste d'un label de sévérité.
  • Une couverture langage qui correspond à votre stack — un outil qui couvre 30 langages mais pas celui que vous utilisez réellement couvre zéro de votre code.
  • Un taux de faux positifs assez bas pour être utilisable — un scanner qui noie le triage sous le bruit finit ignoré en moins d'un mois, quel que soit son nombre brut de findings.
  • Un rapport lisible par quelqu'un hors de l'équipe sécurité — un dump JSON convient au gating CI, inutile à remettre à un auditeur ou un client.
  • Intégration CI/CD — export SARIF, codes de sortie, ou une Action/étape de pipeline native, pour que le scan ne soit pas une étape manuelle qu'on oublie.
  • Une réponse claire à « où va mon code » — SAST cloud-upload et SAST hors-ligne sont deux profils de risque différents, pas une note de bas de page. Voir ce que signifie réellement le SAST hors-ligne.

Où se situe StaticCodeAudit

StaticCodeAudit est un SAST curé, hors-ligne : un binaire autonome qui scanne 8 langages (Python, JavaScript/TypeScript, HTML, Java, C#, PHP, YAML, Dockerfile) avec 708 règles, toutes mappées au minimum au CWE, avec des matrices ISO 27001 Annexe A, OWASP ASVS v5.0, WCAG 2.1 et NIST CSF 2.0 intégrées — pas assemblées après coup. Il n'envoie jamais le code source où que ce soit ; tout le scan tourne sur la machine qui exécute le binaire.

708
Règles de détection
8
Langages
676 + 32
CWE + WCAG mappés
100 %
Hors-ligne

Questions fréquentes

Le SAST remplace-t-il la revue de code manuelle ou le pentest ?

Non. Le SAST est rapide, reproductible, et attrape des classes de patterns connues à grande échelle — il ne détectera pas une faille de logique métier qu'un relecteur humain repérerait (« cette API laisse n'importe quel utilisateur annuler la commande d'un autre »), et ne confirme pas l'exploitabilité comme le fait un pentest sur un système en marche. C'est une couche, généralement la première et la moins coûteuse à mettre en place.

À combien de faux positifs dois-je m'attendre ?

Cela dépend entièrement du moteur et de la conception des règles — il n'y a pas de chiffre universel, et tout éditeur qui en cite un sans benchmark nommé devine. Demandez un benchmark publié et reproductible (OWASP Benchmark, NIST Juliet, ou similaire) avec précision/recall/F1 par catégorie, pas un chiffre agrégé unique de « précision ». Voir comment c'est mesuré sur la page des benchmarks langages.

Un linter, est-ce la même chose que le SAST ?

Non, bien qu'ils se recoupent dans le mécanisme. Un linter (ESLint, Pylint, RuboCop) vérifie surtout le style et des bugs de correction basiques. Les règles SAST ciblent spécifiquement des classes de vulnérabilités exploitables — injection, désérialisation, secrets en dur, faiblesses cryptographiques — et sont généralement mappées au CWE pour que les findings soient traçables à une taxonomie de faiblesse connue.

Le SAST a-t-il besoin d'accès internet pour tourner ?

Pas intrinsèquement — c'est un choix de déploiement de l'éditeur, pas une exigence de l'analyse statique elle-même. Les SAST cloud envoient votre code source pour exécuter l'analyse à distance ; les SAST hors-ligne exécutent toute l'analyse, y compris l'évaluation des règles, sur votre propre machine. Voir ce que signifie réellement le SAST hors-ligne et comment le vérifier.

Que signifie concrètement « 708 règles » ?

Cela signifie 708 patterns de détection maintenus individuellement, chacun mappé à au moins un CWE, couvrant des catégories comme la sécurité (injection, secrets, crypto), l'architecture, les dépendances, la config de pipeline CI/CD, et plus. Le chiffre seul dit peu sans connaître le mapping et le taux de détection mesuré par règle — c'est pourquoi StaticCodeAudit publie à la fois le mapping complet aux standards et de vrais benchmarks précision/recall plutôt que juste le compte.

Voyez un vrai rapport SAST, pas une maquette

Ouvrez le rapport démo en direct — généré sur un vrai codebase, tous les graphiques interactifs, mapping CWE/ISO/ASVS/WCAG complet inclus.

Ouvrir le rapport en direct Lire le guide SAST hors-ligne