Le Static Application Security Testing (SAST) est un contrôle de sécurité fondamental dans les environnements de livraison logicielle réglementés. For auditors, compliance officers, and regulators, the critical question is not which SAST tool an organisation has selected, but whether SAST controls are effective, enforced, evidenced, and governed.
In regulated environments, SAST is not a tooling decision — it is an architectural and governance decision that directly affects the organisation’s ability to demonstrate secure development practices to auditors and regulators.
This guide provides a structured framework for assessing SAST control effectiveness within CI/CD pipelines — focusing on coverage, enforcement, policy gates, exception management, evidence generation, and regulatory alignment.
Pourquoi les contrôles SAST sont importants pour l’audit et la gouvernance
SAST analyses source code for security vulnerabilities before applications are compiled or deployed. When properly implemented, SAST provides early detection of coding weaknesses — reducing the cost and risk of vulnerabilities reaching production.
Du point de vue de la gouvernance, le SAST remplit plusieurs fonctions :
- It provides evidence of proactive vulnerability detection within the development lifecycle.
- It demonstrates that security is embedded in delivery processes, not applied retrospectively.
- It generates auditable records of what was scanned, when, what was found, and how findings were resolved.
- It supports regulatory compliance by mapping to secure development requirements across multiple frameworks.
Organisations that treat SAST as an optional or advisory tool — rather than an enforced control — create significant governance gaps that auditors will identify.
Cadre d’évaluation SAST pour les auditeurs
Lors de l’évaluation des contrôles SAST d’une organisation, les auditeurs doivent évaluer six domaines clés :
1. Couverture — Pourcentage de la base de code analysée
Déterminer si l’analyse SAST couvre adéquatement la base de code de l’organisation :
- Quel pourcentage des dépôts actifs est soumis à l’analyse SAST ?
- Tous les langages de la stack technologique sont-ils couverts par l’outil SAST ?
- Les dépôts nouvellement créés sont-ils automatiquement inscrits à l’analyse ?
- Existe-t-il un inventaire des dépôts exclus avec une justification documentée ?
2. Application — Les résultats sont-ils pris en compte ?
Évaluer si les résultats SAST influencent les décisions de développement et de déploiement :
- Les analyses SAST sont-elles exécutées automatiquement dans les pipelines CI/CD ?
- Les résultats génèrent-ils des éléments de travail exploitables dans les systèmes de suivi ?
- Existe-t-il des preuves que les résultats sont triés, assignés et remédiés ?
- Les développeurs sont-ils responsables de la résolution des résultats dans des délais définis ?
3. Portes de politique — Les résultats critiques bloquent-ils le déploiement ?
Vérifier que les portes de politique appliquent des normes de sécurité minimales :
- Les résultats critiques ou de haute gravité bloquent-ils les fusions ou les déploiements ?
- Les seuils de porte sont-ils définis dans la politique et appliqués dans les configurations de pipeline ?
- Les portes peuvent-elles être contournées ? Si oui, le contournement est-il journalisé, justifié et approuvé ?
- Existe-t-il une séparation des fonctions entre les développeurs et ceux qui approuvent les exceptions de porte ?
4. Gestion des exceptions — Les suppressions sont-elles gouvernées ?
Évaluer comment les faux positifs et les risques acceptés sont gérés :
- Existe-t-il un processus formel pour supprimer les résultats SAST ?
- Les suppressions nécessitent-elles une justification documentée et l’approbation de la direction ou de l’équipe sécurité ?
- Les suppressions sont-elles limitées dans le temps et soumises à une revue périodique ?
- Le taux de suppression est-il suivi et rapporté comme métrique de gouvernance ?
5. Preuves et piste d’audit
Évaluer la qualité et l’exhaustivité des preuves SAST :
- Les résultats d’analyse sont-ils conservés selon une politique de conservation définie ?
- L’exécution des analyses peut-elle être tracée vers des commits, pull requests ou releases spécifiques ?
- Les résultats sont-ils mappés vers des normes reconnues (CWE, OWASP Top 10) ?
- Les données historiques sont-elles disponibles pour l’analyse des tendances et le reporting d’amélioration continue ?
6. Propriété et gouvernance
Confirmer que le SAST fonctionne sous une gouvernance définie :
- Existe-t-il un propriétaire défini pour la politique et la configuration SAST ?
- Les politiques d’analyse sont-elles versionnées et revues périodiquement ?
- Existe-t-il une visibilité centralisée sur toutes les équipes et dépôts ?
- Les rôles et responsabilités sont-ils documentés (qui analyse, qui trie, qui approuve les exceptions) ?
Tableau d’évaluation des contrôles SAST
Le tableau suivant fournit une référence structurée pour les auditeurs évaluant les contrôles SAST :
| Assessment Area | Evidence to Request | Pass Criteria | Fail Indicators |
|---|---|---|---|
| Scan coverage | List of repositories scanned vs. total active repositories; language coverage report | 90%+ of active repositories scanned; all primary languages covered | Significant repositories excluded; unsupported languages in production stack |
| Scan frequency | CI/CD pipeline logs; scan execution timestamps | Scans run on every pull request and before release; no gaps exceeding defined thresholds | Ad-hoc scanning only; scans not triggered by code changes |
| Policy gates | Pipeline configuration files; gate threshold definitions; deployment records | Critical and high findings block merge or deployment; gates are version-controlled | No gating; findings are advisory only; gates can be silently bypassed |
| Finding remediation | Issue tracking records; remediation SLA compliance reports | Critical findings remediated within defined SLAs; systematic tracking in place | Findings not tracked; no SLAs defined; large backlog of unaddressed criticals |
| Exception management | Suppression records; approval workflows; exception review logs; suppression ratio reports | Suppressions require justification and approval; time-limited; ratio tracked | Bulk suppressions without review; no expiry; suppression ratio trending upward without justification |
| Evidence retention | Historical scan reports; data retention policy; traceability records | Results retained per policy; traceable to commits and releases | No retention policy; results overwritten; no link to specific code versions |
| Standards mapping | Finding classification reports; CWE/OWASP mapping documentation | Findings mapped to CWE and OWASP; consistent classification across scans | Proprietary classifications only; no mapping to recognised standards |
| Ownership and governance | RACI matrix; SAST policy documents; role definitions; review records | Clear ownership; policies version-controlled and periodically reviewed | No defined ownership; ad-hoc configuration; no governance documentation |
Correspondance réglementaire — Contrôles SAST
Les contrôles SAST correspondent aux exigences de plusieurs référentiels réglementaires et de conformité :
| Framework | Relevant Requirement | How SAST Controls Apply |
|---|---|---|
| DORA (Digital Operational Resilience Act) | Article 8 — ICT risk management; Article 9 — Protection and prevention | SAST provides evidence of proactive vulnerability detection within the development lifecycle. Demonstrates that code is analysed for security weaknesses before deployment as part of ICT risk management. |
| NIS2 (Network and Information Security Directive) | Article 21 — Cybersecurity risk-management measures | SAST supports the requirement for vulnerability handling and secure development practices. Demonstrates systematic code-level vulnerability detection as part of risk management. |
| ISO 27001:2022 | Annex A 8.25 — Secure development lifecycle; A 8.28 — Secure coding | SAST is a core control within the secure development lifecycle and directly supports secure coding requirements. Provides evidence of systematic code review for security weaknesses. |
| SOC 2 (Type II) | CC7.1 — Detection of changes; CC8.1 — Change management | SAST provides evidence that code changes are analysed for security vulnerabilities before deployment. Supports detection of insecure code changes within the change management process. |
| PCI DSS 4.0 | Requirement 6.3 — Security vulnerabilities are identified and addressed; 6.5 — Changes are managed | SAST satisfies the requirement to identify security vulnerabilities in custom code. Demonstrates that code is reviewed for vulnerabilities as part of the development process. |
Métriques clés que les auditeurs devraient demander
Lors de l’évaluation de l’efficacité des contrôles SAST, les auditeurs devraient demander les métriques suivantes et les évaluer en contexte :
| Metric | What It Measures | What to Look For | Red Flags |
|---|---|---|---|
| Scan coverage rate | Percentage of active repositories scanned regularly | Consistently above 90%; new repositories enrolled automatically | Below 80%; declining trend; manual enrolment only |
| Critical finding remediation SLA compliance | Percentage of critical findings remediated within the defined SLA | Above 95% compliance; clear escalation for missed SLAs | Below 80%; no SLA defined; no escalation process |
| Suppression ratio | Percentage of total findings that are suppressed or marked as accepted | Stable or declining; each suppression individually justified | Trending upward; bulk suppressions; ratio exceeds 20% without clear justification |
| False positive rate trend | How the false positive rate changes over time as rules are tuned | Declining trend; evidence of active rule tuning and feedback loops | Stable or increasing; no tuning performed; developers distrust results |
| Mean time to remediate (MTTR) | Average time from finding detection to verified remediation | Within defined SLA thresholds; trending downward | Exceeding SLAs; no tracking; findings open for extended periods |
| Gate enforcement rate | Percentage of deployments that passed through SAST gates vs. bypassed | Above 98% enforcement; bypasses are rare, logged, and approved | Frequent bypasses; no logging; bypasses not reviewed |
Constatations d’audit SAST courantes
Sur la base de schémas observés dans les environnements réglementés, les déficiences suivantes des contrôles SAST sont fréquemment identifiées lors des audits :
1. Couverture incomplète de la base de code
Organisations scan a subset of repositories — typically those onboarded during initial rollout — while newer repositories, microservices, or repositories using unsupported languages are excluded. Without automated enrolment, coverage degrades as the codebase grows.
2. Le SAST s’exécute mais ne bloque pas
Scans execute in pipelines, but results are informational only. Critical findings do not block merges or deployments, making SAST a reporting exercise rather than a preventive control. This is one of the most significant control design deficiencies.
3. Pratiques de suppression non gouvernées
Developers suppress findings directly in code or configuration without documented justification, approval, or expiry. Over time, the suppression ratio grows, and the organisation loses visibility into actual code risk. In some cases, suppressions are used to bypass gates entirely.
4. Absence de suivi de remédiation
Findings are reported but not systematically routed to issue tracking systems. There is no evidence that findings were triaged, assigned, prioritised, or resolved within defined timeframes. This makes it impossible to demonstrate control operating effectiveness.
5. Absence de conservation des preuves
Scan results are overwritten with each pipeline execution, and no historical data is retained. When auditors request evidence of SAST activity over the audit period, the organisation cannot produce it. This is a fundamental evidence gap.
6. Politique incohérente entre les équipes
Different development teams use different SAST configurations, severity thresholds, or scanning frequencies. The absence of centralised policy means audit results vary depending on which team is reviewed, and the organisation cannot demonstrate consistent control application.
7. Absence de boucle de retour pour l’ajustement des règles
The SAST tool produces a high false positive rate, but no process exists to tune rules based on developer feedback. This erodes trust, increases suppression, and ultimately leads to developers disengaging from the tool — undermining the control’s effectiveness.
Checklist de vérification de la gouvernance
Les auditeurs examinant les contrôles SAST doivent vérifier les éléments suivants :
- Une politique SAST existe, est approuvée et définit le périmètre, la fréquence, les seuils et la propriété
- La couverture d’analyse inclut tous les dépôts et langages dans le périmètre
- Les analyses sont automatisées et intégrées dans les pipelines CI/CD
- Les portes de politique appliquent les décisions de déploiement en fonction de la gravité des résultats
- Les résultats sont suivis jusqu’à la remédiation ou l’acceptation documentée du risque
- Les suppressions sont gouvernées, justifiées, approuvées, limitées dans le temps et suivies
- Les preuves sont conservées avec traçabilité vers des commits et releases spécifiques
- Les rôles et responsabilités sont clairement définis (analyse, triage, approbation des exceptions)
- Les métriques clés (couverture, conformité SLA, taux de suppression, tendance des faux positifs) sont rapportées régulièrement
Conclusion
Assessing SAST controls in regulated environments requires auditors to look beyond whether a tool is installed. The focus must be on whether SAST is applied consistently across the codebase, whether findings are enforced and remediated, whether exceptions are governed, and whether evidence is retained and traceable.
In regulated environments, SAST is not about finding bugs — it is about demonstrating that the organisation systematically identifies, manages, and remediates code-level security weaknesses as part of an enforceable, evidenced control.
Organisations that achieve this are significantly better positioned to satisfy regulatory requirements under DORA, NIS2, ISO 27001, SOC 2, and PCI DSS.
Contenu associé
- Best SAST Tools for Enterprise CI/CD Pipelines (2026 Edition)
- RFP Evaluation Matrix for SAST Tools
- SAST Tool Selection Checklist
Frequently Asked Questions — Auditing SAST Controls
What should auditors evaluate first when assessing SAST controls?
Start with coverage and enforcement. Verify that SAST scanning covers the organisation’s codebase and that critical findings block deployment through defined policy gates.
What is the most common SAST control deficiency found during audits?
The most common deficiency is SAST running in advisory mode only — scans execute but findings do not gate deployments, making the control ineffective as a preventive measure.
Which regulatory frameworks require SAST or static code analysis?
DORA, NIS2, ISO 27001, SOC 2, and PCI DSS all include requirements that map to secure development practices and code-level vulnerability detection. SAST provides direct evidence of compliance with these requirements.
