Static Application Security Testing (SAST) is often presented as a core DevSecOps control.
However, there is a significant gap between how security teams believe auditors assess SAST and how auditors actually do it.
In regulated environments, auditors do not evaluate SAST tools as security products.
They evaluate them as operational controls within the software delivery lifecycle.
This article explains how auditors really review SAST controls — and why many organizations are surprised by audit findings despite “having SAST in place”.
The Auditor’s Starting Point: SAST Is a Control, Not a Tool
Les auditeurs ne commencent pas par :
“Which SAST tool do you use?”
Ils commencent par :
“How do you prevent insecure code from being released, and how can you prove it?”
Du point de vue de l’audit, le SAST est évalué comme :
- a preventive control,
- intégré dans les pipelines CI/CD,
- fonctionnant de manière cohérente dans le temps,
- soutenu par la gouvernance et les preuves.
The specific vendor matters far less than how the control operates in practice.
Étape 1 : Périmètre et définition du contrôle
Auditors first seek to understand what the SAST control is supposed to achieve.
Ils demandent généralement :
- Quelles applications sont dans le périmètre ?
- À quelles étapes le SAST s’exécute-t-il ?
- Quels risques le SAST adresse-t-il ?
- Quels risques sont explicitement hors périmètre ?
If the organization cannot clearly articulate the control objective, SAST is already considered weak.
Un signal d’alerte courant est des réponses vagues telles que :
“We run SAST on most projects.”
Étape 2 : Application dans les pipelines CI/CD
Auditors then examine how SAST is enforced.
Les questions clés incluent :
- Le SAST s’exécute-t-il automatiquement dans le CI/CD ?
- Peut-il bloquer un build ou un déploiement ?
- Les seuils sont-ils définis et appliqués de manière cohérente ?
Du point de vue de l’audit :
- a SAST scan that runs but does not enforce is a detective activity, not a preventive control.
- les contrôles préventifs ont plus de poids dans les évaluations des risques.
Les auditeurs demandent souvent à voir :
- les définitions de pipeline,
- les logs de tâches,
- des preuves de builds échoués en raison de résultats SAST.
Étape 3 : Gouvernance et séparation des fonctions
Next, auditors evaluate who controls SAST.
Ils évaluent :
- qui peut modifier les règles ou politiques,
- qui peut supprimer des résultats,
- si les développeurs peuvent contourner les contrôles sans supervision.
Questions d’audit typiques :
- Les modifications de politique sont-elles approuvées ?
- Les suppressions sont-elles justifiées et limitées dans le temps ?
- Existe-t-il une séparation entre les rôles de développement et de sécurité ?
Uncontrolled rule changes or permanent suppressions are viewed as control bypasses, not operational flexibility.
Étape 4 : Qualité des preuves et traçabilité
Les preuves sont centrales dans les résultats d’audit.
Les auditeurs s’attendent à ce que les preuves SAST soient :
- horodatées,
- attribuables à une exécution de pipeline spécifique,
- liées à un commit ou une release,
- conservées selon la politique.
Les tableaux de bord seuls sont insuffisants.
Les auditeurs demandent souvent :
- des résultats d’analyse exportés,
- des rapports historiques,
- la corrélation entre les résultats et les actions de remédiation.
Si les preuves ne peuvent pas être reproduites ou vérifiées indépendamment, elles sont considérées comme non fiables.
Étape 5 : Gestion des exceptions et des faux positifs
Les faux positifs ne sont pas un échec — les faux positifs non gérés le sont.
Les auditeurs examinent :
- comment les faux positifs sont identifiés,
- qui approuve les suppressions,
- combien de temps les suppressions restent valides,
- si les suppressions sont revues périodiquement.
Constatation d’audit courante :
“SAST findings are suppressed without documented justification or review.”
Cela sape la crédibilité de l’ensemble du contrôle.
Étape 6 : Cohérence dans le temps
Auditors are less interested in a single “good” scan than in control consistency.
Ils évaluent :
- si le SAST s’exécute sur chaque pipeline pertinent,
- si les politiques sont appliquées uniformément,
- si l’application a été désactivée pendant des périodes critiques.
Les lacunes dans les preuves, telles que des analyses manquantes pendant les phases de livraison intense, soulèvent des préoccupations sur la fiabilité du contrôle.
Étape 7 : Intégration avec le SDLC sécurisé
Enfin, les auditeurs évaluent le SAST dans son contexte.
Ils vérifient si :
- le SAST fait partie d’un SDLC sécurisé plus large,
- les résultats influencent les décisions de risque,
- les sorties SAST sont corrélées avec d’autres contrôles (SCA, DAST, runtime).
Le SAST isolé est considéré comme faible.
Le SAST intégré dans un SDLC gouverné est considéré comme efficace.
Ce dont les auditeurs se soucient rarement
Contrary to common assumptions, auditors usually do not focus on:
- le nombre exact de vulnérabilités,
- la complexité avancée des règles,
- les plugins IDE,
- les arguments marketing des fournisseurs.
They care about control reliability, not feature sophistication.
Constatations d’audit courantes liées au SAST
- Analyses SAST non appliquées dans le CI/CD
- Couverture applicative incohérente
- Aucune traçabilité entre les analyses et les releases
- Suppressions non gérées excessives
- Manque de conservation historique des preuves
These findings often lead to moderate or high-risk observations, even when SAST tools are deployed.
Comment se préparer pour une revue d’audit SAST
Les organisations qui réussissent les audits SAST :
- documentent clairement les objectifs de contrôle SAST,
- appliquent automatiquement les politiques dans le CI/CD,
- restreignent les capacités de contournement,
- conservent les preuves de manière centralisée,
- revoient périodiquement les exceptions.
La préparation est opérationnelle, pas cosmétique.
Conclusion
Auditors do not assess SAST by asking which tool you bought.
They assess it by asking whether your organization can reliably prevent insecure code from reaching production — and prove it.
Comprendre comment les auditeurs examinent réellement les contrôles SAST permet aux organisations de :
- concevoir des pipelines plus solides,
- éviter les constatations d’audit courantes,
- et transformer le SAST d’une case à cocher en un contrôle de confiance.
FAQ – Auditor Perspective Focus
Q1. Do auditors manually review SAST findings?
Rarely. Auditors focus on process integrity, enforcement, and traceability rather than individual vulnerabilities.
Q2. What raises red flags during SAST audits?
Inconsistent execution, undocumented suppressions, missing approvals, and lack of historical evidence.
Q3. How can teams prepare for SAST-related audit questions?
By documenting policies, automating enforcement, and maintaining centralized, tamper-resistant evidence.
