Le test statique de sécurité applicative (SAST) est un contrôle fondamental de la livraison logicielle sécurisée. Toutefois, la simple présence d’un outil SAST ne constitue pas un contrôle efficace. Les auditeurs, les responsables conformité et les régulateurs doivent évaluer si la gouvernance de l’outil SAST de l’organisation — de la sélection à l’exploitation continue — répond aux standards exigés par des référentiels tels que DORA, NIS2 et ISO 27001.
Ce guide propose un cadre de vérification structuré pour évaluer la gouvernance des outils SAST dans les environnements d’entreprise et réglementés.
Liste de vérification de l’auditeur — processus de sélection de l’outil
Avant d’évaluer les capacités de l’outil, les auditeurs devraient vérifier que l’organisation a suivi un processus de sélection gouverné.
- L’organisation dispose-t-elle d’un processus de sélection documenté pour les outils de sécurité ?
- Les critères de gouvernance (auditabilité, production de preuves, application des politiques) ont-ils été pondérés de manière appropriée lors de l’évaluation ?
- Plusieurs outils ont-ils été évalués selon un ensemble cohérent d’exigences ?
- Existe-t-il une justification documentée de la décision de sélection finale ?
- Le processus de sélection a-t-il été approuvé par les parties prenantes appropriées (sécurité, ingénierie, conformité) ?
- Existe-t-il des preuves d’une revue continue de l’efficacité de l’outil ?
Liste de vérification pour l’audit de la sélection de l’outil
Les points de vérification ci-dessus décrivent ce qu’un processus de sélection gouverné devrait couvrir. La liste ci-dessous les transforme en un instrument d’évaluation concret et prêt pour l’audit — vingt-huit questions regroupées par domaine de contrôle qu’un auditeur ou un comité d’évaluation peut appliquer directement pour évaluer un outil de test statique de sécurité applicative (SAST) destiné aux environnements CI/CD d’entreprise et réglementés. Chaque question se répond par oui ou par non, et tout écart significatif devrait être documenté et faire l’objet d’une acceptation du risque au moyen d’un processus formel.
| # | Domaine de contrôle | Question d’audit | Oui | Non |
|---|---|---|---|---|
| 1 | Gouvernance | L’outil prend-il en charge une application fondée sur des politiques (bloquer / avertir / signaler uniquement) ? | ☐ | ☐ |
| 2 | Gouvernance | Les politiques peuvent-elles être définies par application, par équipe ou par environnement ? | ☐ | ☐ |
| 3 | Gouvernance | Les politiques de sécurité sont-elles versionnées et auditables ? | ☐ | ☐ |
| 4 | Gouvernance | Les règles peuvent-elles être personnalisées (sévérité, périmètre, exclusions) ? | ☐ | ☐ |
| 5 | Intégration CI/CD | L’outil s’intègre-t-il nativement aux plateformes CI/CD d’entreprise ? | ☐ | ☐ |
| 6 | Intégration CI/CD | Les analyses peuvent-elles s’exécuter automatiquement sur les PR / fusions / pipelines ? | ☐ | ☐ |
| 7 | Intégration CI/CD | Le pipeline peut-il être bloqué en fonction de conditions de politique ? | ☐ | ☐ |
| 8 | Intégration CI/CD | Les résultats sont-ils accessibles via une API ou un export (JSON, CSV, etc.) ? | ☐ | ☐ |
| 9 | Expérience développeur | Les constats sont-ils clairement rattachés à des emplacements du code source ? | ☐ | ☐ |
| 10 | Expérience développeur | Des conseils de correction sont-ils fournis pour les constats ? | ☐ | ☐ |
| 11 | Expérience développeur | Les faux positifs peuvent-ils être supprimés avec justification ? | ☐ | ☐ |
| 12 | Précision | La logique de détection est-elle explicable (pas uniquement une boîte noire) ? | ☐ | ☐ |
| 13 | Précision | Le taux de faux positifs est-il acceptable sur des codes réels ? | ☐ | ☐ |
| 14 | Couverture | L’outil couvre-t-il tous les langages de production dans le périmètre ? | ☐ | ☐ |
| 15 | Couverture | Les jeux de règles sont-ils activement maintenus et mis à jour ? | ☐ | ☐ |
| 16 | Performance | Les durées d’analyse sont-elles compatibles avec les contraintes d’exécution CI/CD ? | ☐ | ☐ |
| 17 | Performance | L’outil passe-t-il à l’échelle sur de nombreux dépôts / équipes ? | ☐ | ☐ |
| 18 | Reporting | L’outil fournit-il des tendances historiques et le vieillissement des vulnérabilités ? | ☐ | ☐ |
| 19 | Reporting | Des rapports peuvent-ils être générés à des fins d’audit (pas seulement des tableaux de bord) ? | ☐ | ☐ |
| 20 | Preuves | Les constats sont-ils horodatés et attribuables à une exécution de pipeline ? | ☐ | ☐ |
| 21 | Preuves | Les preuves peuvent-elles être conservées selon des politiques de rétention définies ? | ☐ | ☐ |
| 22 | Conformité | L’outil rattache-t-il les constats à CWE / OWASP Top 10 ? | ☐ | ☐ |
| 23 | Conformité | Les résultats peuvent-ils soutenir les audits ISO 27001 / SOC 2 / DORA / NIS2 ? | ☐ | ☐ |
| 24 | Exploitation | L’administration centralisée est-elle prise en charge ? | ☐ | ☐ |
| 25 | Exploitation | La charge opérationnelle est-elle acceptable à l’échelle de l’entreprise ? | ☐ | ☐ |
| 26 | Éditeur | Existe-t-il une feuille de route claire de support et de mises à jour ? | ☐ | ☐ |
| 27 | Stratégie | L’outil peut-il évoluer d’une simple visibilité vers un contrôle appliqué ? | ☐ | ☐ |
| 28 | Stratégie | L’outil s’inscrit-il dans le modèle de SDLC sécurisé de l’organisation ? | ☐ | ☐ |
Synthèse des conclusions d’audit
Une fois la liste complétée, les réponses individuelles devraient se consolider en un petit nombre de domaines de décision qu’un comité de sélection peut valider.
| Domaine de décision | Évaluation |
|---|---|
| Maturité de la gouvernance | ☐ Réussite ☐ Conditionnelle ☐ Échec |
| Adéquation au CI/CD | ☐ Réussite ☐ Conditionnelle ☐ Échec |
| Risque d’adoption par les développeurs | ☐ Faible ☐ Moyen ☐ Élevé |
| Préparation à l’audit | ☐ Adéquate ☐ Partielle ☐ Insuffisante |
| Décision globale | ☐ Approuvé ☐ Approuvé sous conditions ☐ Rejeté |
Recommandations à l’auditeur
Un outil SAST ne devrait pas être approuvé pour un CI/CD d’entreprise si :
- les politiques ne peuvent pas être appliquées automatiquement,
- les résultats ne peuvent pas être exportés comme preuves d’audit,
- ou si les développeurs contournent systématiquement l’outil.
1. Gouvernance et application des politiques
Les auditeurs devraient vérifier que l’outil SAST applique les politiques de sécurité de manière cohérente et que la configuration des politiques est gouvernée.
Points de vérification
- Vérifier que l’outil prend en charge une application fondée sur des politiques (modes bloquer, avertir ou signaler uniquement)
- Confirmer que les politiques peuvent être définies et différenciées par application, équipe, environnement ou profil de risque
- Évaluer si la configuration des politiques est versionnée et auditable — les modifications de politiques devraient être traçables
- Vérifier que la personnalisation des règles (sévérité, périmètre, exclusions) est gouvernée et documentée
- Confirmer que l’organisation dispose d’un chemin allant de la simple visibilité au blocage appliqué
Question de l’auditeur : l’organisation peut-elle démontrer qui a modifié les politiques SAST, quand et pourquoi ?
2. Gouvernance de l’intégration CI/CD
Les auditeurs devraient vérifier que l’outil SAST est intégré au pipeline de livraison logicielle en tant que contrôle automatisé et contraignant.
Points de vérification
- Vérifier que les analyses SAST s’exécutent automatiquement sur les pull requests, les fusions vers la branche principale et à intervalles planifiés
- Confirmer que des conditions d’échec du pipeline sont définies et appliquées en fonction de la politique
- Évaluer si l’outil fonctionne à l’échelle sur tous les dépôts du périmètre sans intervention manuelle
- Vérifier que les résultats d’analyse sont accessibles via API ou export structuré pour agrégation et revue
- Confirmer que l’intégration SAST est surveillée — les échecs et les lacunes d’exécution sont détectés et escaladés
Question de l’auditeur : l’organisation peut-elle démontrer que le SAST s’exécute à chaque exécution de pipeline pertinente et que les lacunes sont détectées ?
3. Gestion des constats et qualité du signal
La gouvernance de la manière dont les constats sont triés, supprimés et résolus est aussi importante que la capacité de détection de l’outil.
Points de vérification
- Vérifier que les constats sont clairement rattachés à des emplacements de code et comportent des conseils de correction exploitables
- Confirmer que la suppression des faux positifs exige une justification et une approbation
- Évaluer si les décisions d’acceptation du risque sont documentées avec une validation appropriée
- Vérifier que la logique de détection s’appuie sur des standards reconnus (correspondances CWE, OWASP)
- Confirmer que l’historique des suppressions et reclassifications est préservé et auditable
Question de l’auditeur : l’organisation peut-elle produire une piste d’audit complète pour tout constat supprimé ou accepté ?
4. Gouvernance de la couverture et du périmètre
Les auditeurs devraient vérifier que la couverture SAST s’aligne sur le portefeuille applicatif et le profil de risque de l’organisation.
Points de vérification
- Vérifier que l’outil couvre tous les langages et frameworks de production du périmètre
- Évaluer si la profondeur d’analyse est cohérente entre les langages — pas superficielle pour certains et approfondie pour d’autres
- Confirmer que les jeux de règles sont activement maintenus et mis à jour
- Vérifier que les lacunes de couverture sont identifiées, documentées et acceptées au moyen d’un processus formel de gestion du risque
Question de l’auditeur : l’organisation peut-elle démontrer quelles applications sont couvertes par le SAST et lesquelles ne le sont pas — et pourquoi ?
5. Reporting, preuves et préparation à l’audit
La production de preuves est un axe d’audit primordial. Les auditeurs devraient vérifier que l’outil SAST et les processus qui l’entourent produisent des preuves fiables et résistantes à l’altération.
Points de vérification
- Vérifier que l’outil fournit une analyse des tendances historiques — vieillissement des vulnérabilités, suivi de la correction et violations de politique dans le temps
- Confirmer que les rapports sont prêts pour l’audit — horodatés, attribuables et reproductibles
- Évaluer si des politiques de rétention sont configurées et alignées sur les exigences réglementaires
- Vérifier que les preuves sont exportables dans des formats adaptés à une revue réglementaire
- Confirmer que l’intégrité des preuves est protégée — les résultats ne peuvent être altérés ou supprimés sans détection
Question de l’auditeur : l’organisation peut-elle produire des preuves SAST pour n’importe quelle release donnée, en rattachant les constats au commit et à l’exécution de pipeline précis ?
Cycle de vie de la gouvernance de l’outil
Les auditeurs devraient évaluer si l’organisation gère l’outillage SAST comme une capacité gouvernée dotée d’un cycle de vie défini, et non comme une décision d’achat ponctuelle.
Les cinq étapes de la gouvernance de l’outil :
- Sélection — l’outil a-t-il été retenu au moyen d’un processus d’évaluation formel et documenté, fondé sur des critères de gouvernance ?
- Déploiement — l’outil a-t-il été déployé de manière cohérente sur toutes les applications et pipelines du périmètre ?
- Exploitation — l’outil est-il activement surveillé, maintenu et produit-il des résultats fiables ?
- Revue — existe-t-il une revue périodique de l’efficacité, de la couverture et de l’adéquation de l’outil ?
- Remplacement — existe-t-il un processus défini pour remplacer ou mettre hors service les outils qui ne répondent plus aux exigences ?
Chaque étape devrait produire des preuves auditables. L’absence de l’une d’elles signale une lacune de gouvernance.
Pourquoi la plupart des RFP SAST échouent
Les appels d’offres (RFP) sont le mécanisme le plus courant qu’utilisent les grandes organisations pour sélectionner un outil SAST ; pourtant, dans les environnements réglementés, de nombreux RFP SAST échouent — non pas au moment de l’achat, mais des mois plus tard, lors des audits, des incidents ou face à la réalité opérationnelle. La cause est rarement le seul mauvais choix d’outil ; c’est généralement un ensemble de failles structurelles dans la façon dont les exigences SAST sont définies, évaluées et validées. Les sept schémas d’échec ci-dessous sont ceux que les auditeurs rencontrent le plus souvent, suivis de ce que les organisations rigoureuses font différemment.
Échec n° 1 : traiter le SAST comme une comparaison de fonctionnalités
De nombreux RFP se concentrent fortement sur :
- le nombre de langages pris en charge,
- les allégations de détection de vulnérabilités,
- les mesures de vitesse d’analyse,
- les intégrations d’IDE.
Bien que ces aspects soient pertinents, ils ne sont pas décisifs dans les environnements réglementés.
Les auditeurs ne demandent pas :
« Combien de vulnérabilités votre outil SAST détecte-t-il ? »
Ils demandent :
« Comment appliquez-vous les politiques de codage sécurisé et comment le prouvez-vous dans la durée ? »
Lorsqu’un RFP privilégie les listes de fonctionnalités au détriment de la gouvernance et de l’application, l’outil retenu ne répond souvent pas aux attentes réglementaires.
Échec n° 2 : ignorer la réalité de l’application dans le CI/CD
Une exigence fréquente des RFP est :
« L’outil doit s’intégrer au CI/CD. »
En pratique, cette exigence est interprétée de manière trop souple.
Ce qui compte n’est pas l’intégration, mais l’application :
- L’outil peut-il bloquer un pipeline ?
- Peut-il appliquer automatiquement des seuils de politique ?
- Les exceptions peuvent-elles être contrôlées et auditées ?
Les RFP qui ne testent pas explicitement le comportement de blocage du build retiennent des outils qui s’exécutent passivement, génèrent des rapports et finissent par être ignorés.
Dans les environnements réglementés, un contrôle de sécurité qui ne peut rien imposer n’est pas un contrôle.
Échec n° 3 : sous-estimer la gouvernance et la séparation des tâches
De nombreux RFP SAST supposent que :
- les développeurs configurent les règles,
- la sécurité examine les résultats,
- les auditeurs consomment les rapports.
Sans mécanismes de gouvernance clairs, ce modèle s’effondre.
Les lacunes de gouvernance courantes comprennent :
- aucune séparation des rôles entre développeurs et sécurité,
- des modifications de règles sans approbation ni traçabilité,
- des constats supprimés sans justification.
Les auditeurs identifient rapidement ces faiblesses et concluent que les contrôles SAST ne sont pas fiables.
Échec n° 4 : confondre tableaux de bord et preuves d’audit
Les plateformes SAST modernes offrent des tableaux de bord attrayants :
- scores de risque,
- tendances,
- graphiques.
Toutefois, les tableaux de bord ne sont pas des preuves d’audit.
Les auditeurs exigent :
- des résultats horodatés,
- une traçabilité vers des exécutions de pipeline précises,
- un lien avec les commits, les approbations et les exceptions,
- une rétention historique.
Les RFP qui n’exigent pas explicitement des preuves exportables et immuables conduisent à des outils qui font bonne impression en interne mais échouent sous l’examen d’un audit.
Échec n° 5 : négliger la gouvernance des faux positifs
Les faux positifs sont inévitables en SAST.
L’échec survient lorsque les RFP ne traitent pas :
- la manière dont les faux positifs sont supprimés,
- qui approuve les suppressions,
- combien de temps les suppressions restent valides,
- si les suppressions sont auditables.
Dans les environnements réglementés, les suppressions non gérées sont considérées comme des contournements de contrôle.
Les RFP qui ignorent cet aspect retiennent des outils qui minent la confiance au lieu de la renforcer.
Échec n° 6 : croire qu’un seul outil couvre tout le SDLC
Certains RFP attendent implicitement que le SAST :
- sécurise le comportement à l’exécution,
- détecte les mauvaises configurations,
- prévienne les attaques de la chaîne d’approvisionnement.
C’est irréaliste.
Lorsque le SAST est survendu comme une solution de sécurité complète, les organisations :
- délimitent mal le périmètre des contrôles,
- s’appuient excessivement sur l’analyse statique,
- ne le complètent pas par du DAST, du SCA ou des contrôles à l’exécution.
Les auditeurs interprètent cela comme une mauvaise compréhension du risque, non comme une sécurité avancée.
Échec n° 7 : ne pas valider les preuves pendant le POC
De nombreux RFP incluent une preuve de concept (POC), mais :
- se concentrent uniquement sur la précision de détection,
- ignorent la production de preuves dans le pipeline,
- ne testent pas les scénarios d’audit.
Un POC correct en environnement réglementé devrait valider :
- l’application des politiques dans le CI/CD,
- les circuits de gestion des exceptions,
- l’export et la rétention des preuves.
Sauter cette étape garantit un échec tardif.
Ce que font différemment les RFP SAST réussis
Les organisations qui réussissent conçoivent leurs RFP SAST autour des contrôles, non des outils.
Elles exigent explicitement :
- une application fondée sur des politiques dans le CI/CD,
- une gouvernance fondée sur les rôles et une séparation des tâches,
- des circuits de gestion des exceptions auditables,
- des preuves exportables et conservées,
- un alignement sur le SDLC sécurisé et les objectifs de conformité.
Plus important encore, elles admettent qu’aucun outil SAST à lui seul ne garantit la conformité.
Un meilleur cadrage pour les RFP SAST
Au lieu de demander :
« Quel est le meilleur outil SAST ? »
Demandez :
« Quelle solution SAST peut être exploitée comme un contrôle CI/CD réglementé ? »
Ce changement de cadrage améliore considérablement les résultats.
Signaux d’alerte pour les auditeurs
Les indicateurs suivants devraient susciter des inquiétudes lors d’un audit de la gouvernance des outils SAST :
- Aucun processus de sélection documenté — l’outil a été adopté sans évaluation ni comparaison formelle
- Aucun critère de gouvernance dans la sélection — l’évaluation a porté uniquement sur les fonctionnalités techniques, sans tenir compte de l’auditabilité, de la production de preuves ou de l’application des politiques
- Aucune revue périodique de l’efficacité — l’outil n’a pas été réévalué depuis son déploiement initial
- Analyses exécutées manuellement ou de façon incohérente — le SAST n’est pas intégré au pipeline CI/CD comme un contrôle automatisé
- Aucune rétention des preuves — les résultats d’analyse et les journaux ne sont pas conservés à des fins d’audit
- Suppression non contrôlée des constats — les développeurs peuvent supprimer des vulnérabilités sans supervision de gouvernance ni justification documentée
- Outil désactivé ou contourné en silence — les configurations de pipeline permettent de sauter le SAST sans approbation
- Politiques non versionnées — les modifications des règles et politiques SAST ne sont ni suivies ni attribuables
Alignement réglementaire
La gouvernance des outils SAST correspond directement aux exigences des principaux référentiels réglementaires. Les auditeurs devraient évaluer l’alignement avec les éléments suivants :
DORA (Digital Operational Resilience Act)
- L’article 9 exige des cadres de gestion du risque lié aux TIC qui incluent le test des systèmes TIC — le SAST est un contrôle primordial pour le test au niveau du code
- Exige une application proportionnée et fondée sur le risque des tests — les auditeurs devraient vérifier que la couverture SAST s’aligne sur la criticité
- Impose des preuves documentées des activités et des résultats des tests
NIS2 (directive sur la sécurité des réseaux et de l’information)
- Exige des organisations qu’elles mettent en œuvre des mesures de sécurité dans la chaîne d’approvisionnement et les processus de développement
- La gouvernance des outils SAST démontre une approche proactive du développement sécurisé
- Les preuves de tests de sécurité continus soutiennent la conformité aux obligations de gestion des risques
ISO 27001
- Contrôle A.8.25 de l’Annexe A (cycle de développement sécurisé) — le SAST est un contrôle technique clé
- Contrôle A.8.29 de l’Annexe A (tests de sécurité en développement et en recette) — exige des preuves de tests de sécurité tout au long du SDLC
- Exige des processus documentés, des preuves de fonctionnement du contrôle et une revue périodique
Conclusion
Auditer la gouvernance des outils SAST exige d’aller au-delà de la simple présence d’un outil. Les auditeurs devraient évaluer l’ensemble du cycle de vie de la gouvernance — de la sélection à l’exploitation continue et à la revue — et vérifier que l’organisation produit les preuves nécessaires pour démontrer l’efficacité du contrôle.
Les organisations qui traitent la sélection d’un outil SAST comme une décision d’achat ponctuelle, plutôt que comme une responsabilité de gouvernance continue, sont susceptibles de présenter des lacunes de couverture, de preuves et d’application qui les exposent à des risques réglementaires et de sécurité.
Foire aux questions — gouvernance des outils SAST
Que les auditeurs devraient-ils vérifier en premier lors de l’évaluation de la gouvernance d’un outil SAST ?
Commencez par le processus de sélection de l’outil. Vérifiez qu’une évaluation documentée a eu lieu, que des critères de gouvernance (auditabilité, production de preuves, application des politiques) ont été inclus et que la décision a été approuvée par les parties prenantes appropriées.
Quel est le lien entre la gouvernance des outils SAST et la conformité à DORA et NIS2 ?
DORA exige des preuves documentées du test des systèmes TIC, y compris les contrôles au niveau du code. NIS2 exige des mesures de sécurité dans les processus de développement. Un outillage SAST gouverné — avec des preuves d’exécution cohérente, d’application des politiques et de revue périodique — soutient directement la conformité aux deux référentiels.
Quelle est la lacune de gouvernance la plus fréquente dans la gestion des outils SAST ?
L’absence de revue périodique de l’efficacité. De nombreuses organisations déploient un outil SAST et ne réévaluent jamais s’il continue de répondre à leurs exigences de sécurité, de conformité et d’exploitation — créant un écart entre l’existence du contrôle et son efficacité réelle.
Contenus liés
- Le SAST en environnement réglementé — guide de l’auditeur pour évaluer les contrôles SAST
- Matrice d’évaluation RFP
- Meilleurs outils SAST pour les pipelines CI/CD d’entreprise (édition 2026)
