Le test statique de sécurité applicative (SAST) est un contrôle de sécurité fondamental dans les environnements de livraison logicielle réglementés. Pour les auditeurs, les responsables conformité et les régulateurs, la question essentielle n’est pas de savoir quel outil SAST une organisation a retenu, mais si les contrôles SAST sont efficaces, appliqués, documentés par des preuves et gouvernés.
Dans les environnements réglementés, le SAST n’est pas un choix d’outillage : c’est une décision d’architecture et de gouvernance qui influe directement sur la capacité de l’organisation à démontrer des pratiques de développement sécurisé face aux auditeurs et aux régulateurs.
Ce guide propose un cadre structuré pour évaluer l’efficacité des contrôles SAST au sein des pipelines CI/CD, en se concentrant sur la couverture, l’application, les portes de politique, la gestion des exceptions, la production de preuves et l’alignement réglementaire.
Pourquoi les contrôles SAST comptent pour l’audit et la gouvernance
Le SAST analyse le code source à la recherche de vulnérabilités de sécurité avant que les applications ne soient compilées ou déployées. Correctement mis en œuvre, il permet une détection précoce des faiblesses de codage, réduisant le coût et le risque liés aux vulnérabilités qui atteindraient la production.
Du point de vue de la gouvernance, le SAST remplit plusieurs fonctions :
- Il fournit une preuve de détection proactive des vulnérabilités au sein du cycle de développement.
- Il démontre que la sécurité est intégrée aux processus de livraison, et non appliquée après coup.
- Il génère des enregistrements auditables indiquant ce qui a été analysé, à quel moment, ce qui a été trouvé et comment les constats ont été résolus.
- Il soutient la conformité réglementaire en s’alignant sur les exigences de développement sécurisé de plusieurs référentiels.
Les organisations qui traitent le SAST comme un outil facultatif ou consultatif, plutôt que comme un contrôle appliqué, créent des lacunes de gouvernance importantes que les auditeurs relèveront.
Cadre d’évaluation SAST pour les auditeurs
Lorsqu’ils évaluent les contrôles SAST d’une organisation, les auditeurs devraient examiner six domaines clés :
1. Couverture — pourcentage du code analysé
Déterminez si l’analyse SAST couvre suffisamment le code de l’organisation :
- Quel pourcentage des dépôts actifs fait l’objet d’une analyse SAST ?
- Tous les langages de la pile technologique sont-ils pris en charge par l’outil SAST ?
- Les dépôts nouvellement créés sont-ils automatiquement intégrés à l’analyse ?
- Existe-t-il un inventaire des dépôts exclus, assorti d’une justification documentée ?
2. Application — les résultats sont-ils suivis d’effet ?
Évaluez si les constats SAST influencent les décisions de développement et de déploiement :
- Les analyses SAST s’exécutent-elles automatiquement dans les pipelines CI/CD ?
- Les constats génèrent-ils des tâches exploitables dans les systèmes de suivi des tickets ?
- Existe-t-il des preuves que les constats sont triés, attribués et corrigés ?
- Les développeurs sont-ils responsables de la résolution des constats dans des délais définis ?
3. Portes de politique — les constats critiques bloquent-ils le déploiement ?
Vérifiez que les portes de politique imposent des standards de sécurité minimaux :
- Les constats de sévérité critique ou élevée bloquent-ils les fusions ou les déploiements ?
- Les seuils des portes 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 tâches entre les développeurs et ceux qui approuvent les exceptions aux portes ?
4. Gestion des exceptions — les suppressions sont-elles gouvernées ?
Évaluez la manière dont les faux positifs et les risques acceptés sont gérés :
- Existe-t-il un processus formel de suppression des constats SAST ?
- Les suppressions exigent-elles une justification documentée et l’approbation d’un responsable 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 indicateur de gouvernance ?
5. Preuves et piste d’audit
Évaluez la qualité et l’exhaustivité des preuves SAST :
- Les résultats d’analyse sont-ils conservés selon une politique de rétention définie ?
- L’exécution des analyses peut-elle être rattachée à des commits, des pull requests ou des releases précis ?
- Les constats sont-ils rattachés à des standards reconnus (CWE, OWASP Top 10) ?
- Des données historiques sont-elles disponibles pour l’analyse de tendances et le reporting d’amélioration continue ?
6. Responsabilité et gouvernance
Confirmez que le SAST fonctionne sous une gouvernance définie :
- Existe-t-il un responsable désigné 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 l’ensemble des équipes et des 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 offre une référence structurée aux auditeurs qui évaluent les contrôles SAST :
| Domaine d’évaluation | Preuves à demander | Critères de réussite | Indicateurs d’échec |
|---|---|---|---|
| Couverture de l’analyse | Liste des dépôts analysés par rapport au total des dépôts actifs ; rapport de couverture des langages | Plus de 90 % des dépôts actifs analysés ; tous les langages principaux couverts | Dépôts importants exclus ; langages non pris en charge dans la pile de production |
| Fréquence des analyses | Journaux des pipelines CI/CD ; horodatage d’exécution des analyses | Analyses exécutées à chaque pull request et avant chaque release ; aucun écart dépassant les seuils définis | Analyses ponctuelles uniquement ; analyses non déclenchées par les modifications de code |
| Portes de politique | Fichiers de configuration des pipelines ; définitions des seuils de portes ; enregistrements de déploiement | Les constats critiques et élevés bloquent la fusion ou le déploiement ; les portes sont versionnées | Aucune porte ; constats purement consultatifs ; portes contournables sans trace |
| Correction des constats | Enregistrements de suivi des tickets ; rapports de respect des SLA de correction | Constats critiques corrigés dans les SLA définis ; suivi systématique en place | Constats non suivis ; aucun SLA défini ; important arriéré de constats critiques non traités |
| Gestion des exceptions | Enregistrements de suppression ; circuits d’approbation ; journaux de revue des exceptions ; rapports de taux de suppression | Les suppressions exigent justification et approbation ; limitées dans le temps ; taux suivi | Suppressions en masse sans revue ; aucune expiration ; taux de suppression en hausse sans justification |
| Rétention des preuves | Rapports d’analyse historiques ; politique de rétention des données ; enregistrements de traçabilité | Résultats conservés selon la politique ; traçables jusqu’aux commits et aux releases | Aucune politique de rétention ; résultats écrasés ; aucun lien avec des versions de code précises |
| Correspondance aux standards | Rapports de classification des constats ; documentation de correspondance CWE/OWASP | Constats rattachés à CWE et OWASP ; classification cohérente d’une analyse à l’autre | Classifications propriétaires uniquement ; aucune correspondance avec des standards reconnus |
| Responsabilité et gouvernance | Matrice RACI ; documents de politique SAST ; définitions de rôles ; enregistrements de revue | Responsabilité claire ; politiques versionnées et revues périodiquement | Aucune responsabilité définie ; configuration ponctuelle ; aucune documentation de gouvernance |
Correspondance réglementaire — contrôles SAST
Les contrôles SAST correspondent à des exigences de plusieurs référentiels réglementaires et de conformité :
| Référentiel | Exigence pertinente | Application des contrôles SAST |
|---|---|---|
| DORA (Digital Operational Resilience Act) | Article 8 — gestion du risque lié aux TIC ; Article 9 — protection et prévention | Le SAST apporte la preuve d’une détection proactive des vulnérabilités au sein du cycle de développement. Il démontre que le code est analysé à la recherche de faiblesses de sécurité avant le déploiement, dans le cadre de la gestion du risque lié aux TIC. |
| NIS2 (directive sur la sécurité des réseaux et de l’information) | Article 21 — mesures de gestion des risques de cybersécurité | Le SAST répond à l’exigence de traitement des vulnérabilités et de développement sécurisé. Il démontre une détection systématique des vulnérabilités au niveau du code dans le cadre de la gestion des risques. |
| ISO 27001:2022 | Annexe A 8.25 — cycle de développement sécurisé ; A 8.28 — codage sécurisé | Le SAST est un contrôle central du cycle de développement sécurisé et soutient directement les exigences de codage sécurisé. Il apporte la preuve d’une revue systématique du code à la recherche de faiblesses de sécurité. |
| SOC 2 (Type II) | CC7.1 — détection des changements ; CC8.1 — gestion des changements | Le SAST prouve que les modifications de code sont analysées à la recherche de vulnérabilités avant le déploiement. Il soutient la détection des modifications de code non sécurisées dans le cadre du processus de gestion des changements. |
| PCI DSS 4.0 | Exigence 6.3 — les vulnérabilités de sécurité sont identifiées et traitées ; 6.5 — les changements sont gérés | Le SAST satisfait l’exigence d’identification des vulnérabilités de sécurité dans le code sur mesure. Il démontre que le code est revu à la recherche de vulnérabilités dans le cadre du processus de développement. |
Indicateurs clés que les auditeurs devraient demander
Pour évaluer l’efficacité des contrôles SAST, les auditeurs devraient demander les indicateurs suivants et les analyser dans leur contexte :
| Indicateur | Ce qu’il mesure | Ce qu’il faut rechercher | Signaux d’alerte |
|---|---|---|---|
| Taux de couverture des analyses | Pourcentage de dépôts actifs analysés régulièrement | Constamment au-dessus de 90 % ; nouveaux dépôts intégrés automatiquement | En dessous de 80 % ; tendance à la baisse ; intégration manuelle uniquement |
| Respect des SLA de correction des constats critiques | Pourcentage de constats critiques corrigés dans le SLA défini | Plus de 95 % de conformité ; escalade claire en cas de SLA dépassé | En dessous de 80 % ; aucun SLA défini ; aucun processus d’escalade |
| Taux de suppression | Pourcentage du total des constats supprimés ou marqués comme acceptés | Stable ou en baisse ; chaque suppression justifiée individuellement | En hausse ; suppressions en masse ; taux supérieur à 20 % sans justification claire |
| Tendance du taux de faux positifs | Évolution du taux de faux positifs dans le temps, à mesure que les règles sont affinées | Tendance à la baisse ; preuves d’un affinage actif des règles et de boucles de retour | Stable ou en hausse ; aucun affinage réalisé ; les développeurs se défient des résultats |
| Délai moyen de correction (MTTR) | Temps moyen entre la détection d’un constat et la correction vérifiée | Dans les seuils SLA définis ; en baisse | SLA dépassés ; aucun suivi ; constats ouverts pendant de longues périodes |
| Taux d’application des portes | Pourcentage de déploiements passés par les portes SAST par rapport à ceux qui les ont contournées | Plus de 98 % d’application ; contournements rares, journalisés et approuvés | Contournements fréquents ; aucune journalisation ; contournements non revus |
Constats d’audit SAST fréquents
D’après les schémas observés dans les environnements réglementés, les déficiences de contrôle SAST suivantes sont fréquemment identifiées lors des audits :
1. Couverture incomplète du code
Les organisations analysent un sous-ensemble de dépôts — généralement ceux intégrés lors du déploiement initial — tandis que les dépôts plus récents, les microservices ou les dépôts utilisant des langages non pris en charge sont exclus. Sans intégration automatisée, la couverture se dégrade à mesure que le code grandit.
2. Le SAST s’exécute mais ne bloque rien
Les analyses s’exécutent dans les pipelines, mais les résultats sont purement informatifs. Les constats critiques ne bloquent ni les fusions ni les déploiements, réduisant le SAST à un exercice de reporting plutôt qu’à un contrôle préventif. C’est l’une des déficiences de conception de contrôle les plus significatives.
3. Pratiques de suppression non gouvernées
Les développeurs suppriment les constats directement dans le code ou la configuration, sans justification documentée, approbation ni expiration. Avec le temps, le taux de suppression augmente et l’organisation perd la visibilité sur le risque réel du code. Dans certains cas, les suppressions servent à contourner entièrement les portes.
4. Aucun suivi de la correction
Les constats sont rapportés mais ne sont pas systématiquement acheminés vers les systèmes de suivi des tickets. Rien ne prouve que les constats ont été triés, attribués, priorisés ou résolus dans des délais définis. Il devient alors impossible de démontrer l’efficacité opérationnelle du contrôle.
5. Aucune rétention des preuves
Les résultats d’analyse sont écrasés à chaque exécution du pipeline et aucune donnée historique n’est conservée. Lorsque les auditeurs demandent des preuves de l’activité SAST sur la période d’audit, l’organisation ne peut pas les produire. C’est une lacune fondamentale en matière de preuve.
6. Politique incohérente entre les équipes
Différentes équipes de développement utilisent des configurations SAST, des seuils de sévérité ou des fréquences d’analyse différents. L’absence de politique centralisée signifie que les résultats d’audit varient selon l’équipe examinée, et l’organisation ne peut pas démontrer une application cohérente du contrôle.
7. Aucune boucle de retour pour l’affinage des règles
L’outil SAST produit un taux de faux positifs élevé, mais aucun processus ne permet d’affiner les règles à partir des retours des développeurs. Cela érode la confiance, accroît les suppressions et conduit finalement les développeurs à se désengager de l’outil, minant l’efficacité du contrôle.
Comment les auditeurs examinent réellement les contrôles SAST
Les déficiences ci-dessus ne sont pas découvertes par hasard. Elles apparaissent parce que les auditeurs suivent un processus de revue reproductible, et il existe souvent un écart important entre la façon dont les équipes de sécurité imaginent cette revue et la façon dont elle est réellement menée. Dans les environnements réglementés, les auditeurs n’évaluent pas le SAST comme un produit de sécurité : ils l’évaluent comme un contrôle opérationnel au sein du cycle de livraison logicielle. Comprendre la séquence qu’ils suivent est le moyen le plus fiable d’anticiper les constats avant qu’ils ne soient formulés.
Le point de départ de l’auditeur : le SAST est un contrôle, pas un outil
Les auditeurs ouvrent rarement par « quel outil SAST utilisez-vous ? ». Ils commencent par une question plus exigeante :
« Comment empêchez-vous la mise en production de code non sécurisé, et comment pouvez-vous le prouver ? »
Du point de vue de l’audit, le SAST est évalué comme un contrôle préventif, intégré aux pipelines CI/CD, fonctionnant de manière cohérente dans le temps et soutenu par une gouvernance et des preuves. L’éditeur précis compte bien moins que la manière dont le contrôle fonctionne en pratique.
Étape 1 — périmètre et définition du contrôle
Les auditeurs cherchent d’abord à comprendre ce que le contrôle SAST est censé accomplir. 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 traite-t-il ?
- Quels risques sont explicitement hors périmètre ?
Si l’organisation ne peut pas énoncer clairement l’objectif du contrôle, le SAST est déjà considéré comme faible. Un signal d’alerte fréquent est une réponse vague du type « nous exécutons le SAST sur la plupart des projets ».
Étape 2 — application dans les pipelines CI/CD
Les auditeurs examinent ensuite comment le SAST est appliqué : 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, une analyse SAST qui s’exécute sans rien imposer est une activité de détection, pas un contrôle préventif — et les contrôles préventifs pèsent davantage dans les évaluations de risque. Pour confirmer l’application, les auditeurs demandent souvent à voir :
- les définitions de pipeline,
- les journaux de jobs,
- des preuves de builds échoués en raison de constats SAST.
Étape 3 — gouvernance et séparation des tâches
Les auditeurs évaluent ensuite qui contrôle le SAST : qui peut modifier les règles ou les politiques, qui peut supprimer des constats, et si les développeurs peuvent contourner les contrôles sans supervision. Les questions habituelles portent sur l’approbation des changements de politique, la justification et la limitation dans le temps des suppressions, et l’existence d’une séparation entre les rôles de développement et de sécurité. Les modifications de règles non contrôlées ou les suppressions permanentes sont vues comme des contournements de contrôle, non comme de la souplesse opérationnelle.
Étape 4 — qualité des preuves et traçabilité
Les preuves sont au cœur des conclusions d’audit. Les auditeurs attendent des preuves SAST horodatées, attribuables à une exécution de pipeline précise, liées à un commit ou à une release, et conservées conformément à la politique. Les tableaux de bord seuls ne suffisent pas ; les auditeurs demandent souvent des résultats d’analyse exportés, des rapports historiques et une corrélation démontrable entre les constats et les actions de correction. Si une preuve ne peut être reproduite ou vérifiée de manière indépendante, elle est jugée non fiable.
Étape 5 — traitement 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 et si elles sont revues périodiquement. Un constat d’audit récurrent résume précisément le problème :
« Les constats SAST sont supprimés sans justification documentée ni revue. »
Cette seule faiblesse mine la crédibilité de l’ensemble du contrôle.
Étape 6 — cohérence dans le temps
Les auditeurs s’intéressent moins à une seule « bonne » analyse qu’à la cohérence du contrôle. Ils évaluent si le SAST s’exécute sur chaque pipeline pertinent, si les politiques sont appliquées uniformément et si l’application a déjà été désactivée pendant des périodes de livraison critiques. Les lacunes de preuve — comme des analyses manquantes pendant les phases de release intenses — soulèvent des doutes sur la fiabilité du contrôle, même lorsque l’outil est par ailleurs bien configuré.
Étape 7 — intégration au SDLC sécurisé
Enfin, les auditeurs évaluent le SAST dans son contexte. Ils vérifient s’il s’inscrit dans un SDLC sécurisé plus large, si les constats influencent les décisions de risque et si les résultats du SAST sont corrélés à d’autres contrôles tels que l’analyse de composition logicielle, le DAST et la protection à l’exécution. Le SAST isolé est considéré comme faible ; le SAST intégré à un SDLC gouverné est considéré comme efficace.
Ce sur quoi les auditeurs se concentrent rarement
Contrairement aux idées reçues, les auditeurs ne se focalisent généralement pas sur le nombre exact de vulnérabilités, la complexité avancée des règles, les extensions d’IDE ou les arguments marketing des éditeurs. Ils se soucient de la fiabilité du contrôle, non de la sophistication des fonctionnalités — ce qui explique pourquoi les organisations qui investissent beaucoup dans l’outillage mais peu dans la gouvernance sont si souvent surprises par leurs résultats d’audit.
Comment se préparer à une revue d’audit SAST
Les organisations qui réussissent leurs audits SAST documentent généralement clairement les objectifs de contrôle, appliquent les politiques automatiquement dans le CI/CD, restreignent les capacités de contournement, conservent les preuves de manière centralisée et revoient périodiquement les exceptions. La préparation est opérationnelle, non cosmétique : l’objectif est de démontrer que l’organisation peut empêcher de manière fiable le code non sécurisé d’atteindre la production — et de le prouver sur toute la période d’audit.
Liste de vérification de la gouvernance
Les auditeurs qui examinent les contrôles SAST devraient vérifier les points suivants :
- Une politique SAST existe, est approuvée et définit le périmètre, la fréquence, les seuils et la responsabilité
- La couverture des analyses inclut tous les dépôts et langages du périmètre
- Les analyses sont automatisées et intégrées aux pipelines CI/CD
- Les portes de politique conditionnent les décisions de déploiement selon la sévérité des constats
- Les constats sont suivis jusqu’à leur correction ou une acceptation du risque documentée
- Les suppressions sont gouvernées, justifiées, approuvées, limitées dans le temps et suivies
- Les preuves sont conservées avec une traçabilité jusqu’aux commits et releases précis
- Les rôles et responsabilités sont clairement définis (analyse, tri, approbation des exceptions)
- Les indicateurs clés (couverture, respect des SLA, taux de suppression, tendance des faux positifs) sont rapportés régulièrement
Conclusion
Évaluer les contrôles SAST dans les environnements réglementés exige des auditeurs qu’ils aillent au-delà de la simple présence d’un outil. L’attention doit porter sur la question de savoir si le SAST est appliqué de manière cohérente à l’ensemble du code, si les constats sont imposés et corrigés, si les exceptions sont gouvernées, et si les preuves sont conservées et traçables.
Dans les environnements réglementés, le SAST ne consiste pas à trouver des bugs — il s’agit de démontrer que l’organisation identifie, gère et corrige systématiquement les faiblesses de sécurité au niveau du code, dans le cadre d’un contrôle contraignant et documenté par des preuves.
Les organisations qui y parviennent sont bien mieux placées pour satisfaire les exigences réglementaires au titre de DORA, NIS2, ISO 27001, SOC 2 et PCI DSS.
Contenus liés
- Meilleurs outils SAST pour les pipelines CI/CD d’entreprise (édition 2026)
- Matrice d’évaluation RFP pour les outils SAST
- Gouvernance des outils SAST — liste de sélection, RFP et points à vérifier par les auditeurs
Foire aux questions — auditer les contrôles SAST
Que les auditeurs devraient-ils évaluer en premier lors de l’examen des contrôles SAST ?
Commencez par la couverture et l’application. Vérifiez que l’analyse SAST couvre le code de l’organisation et que les constats critiques bloquent le déploiement au moyen de portes de politique définies.
Quelle est la déficience de contrôle SAST la plus fréquente lors des audits ?
La déficience la plus fréquente est un SAST fonctionnant en mode consultatif uniquement : les analyses s’exécutent mais les constats ne conditionnent pas les déploiements, rendant le contrôle inefficace comme mesure préventive.
Quels référentiels réglementaires exigent le SAST ou l’analyse statique de code ?
DORA, NIS2, ISO 27001, SOC 2 et PCI DSS comportent tous des exigences qui s’alignent sur les pratiques de développement sécurisé et la détection des vulnérabilités au niveau du code. Le SAST fournit une preuve directe de conformité à ces exigences.
