Le test statique de s\u00e9curit\u00e9 applicative (SAST) est un contr\u00f4le fondamental de la livraison logicielle s\u00e9curis\u00e9e. Toutefois, la simple pr\u00e9sence d’un outil SAST ne constitue pas un contr\u00f4le efficace. Les auditeurs, les responsables conformit\u00e9 et les r\u00e9gulateurs doivent \u00e9valuer si la gouvernance de l’outil SAST de l’organisation \u2014 de la s\u00e9lection \u00e0 l’exploitation continue \u2014 r\u00e9pond aux standards exig\u00e9s par des r\u00e9f\u00e9rentiels tels que DORA, NIS2 et ISO 27001.<\/p>\n\n\n\n
Ce guide propose un cadre de v\u00e9rification structur\u00e9 pour \u00e9valuer la gouvernance des outils SAST dans les environnements d’entreprise et r\u00e9glement\u00e9s.<\/p>\n\n\n\n
Avant d’\u00e9valuer les capacit\u00e9s de l’outil, les auditeurs devraient v\u00e9rifier que l’organisation a suivi un processus de s\u00e9lection gouvern\u00e9.<\/p>\n\n\n\n
Les points de v\u00e9rification ci-dessus d\u00e9crivent ce qu’un processus de s\u00e9lection gouvern\u00e9 devrait couvrir. La liste ci-dessous les transforme en un instrument d’\u00e9valuation concret et pr\u00eat pour l’audit \u2014 vingt-huit questions regroup\u00e9es par domaine de contr\u00f4le qu’un auditeur ou un comit\u00e9 d’\u00e9valuation peut appliquer directement pour \u00e9valuer un outil de test statique de s\u00e9curit\u00e9 applicative (SAST) destin\u00e9 aux environnements CI\/CD d’entreprise et r\u00e9glement\u00e9s. Chaque question se r\u00e9pond par oui ou par non, et tout \u00e9cart significatif devrait \u00eatre document\u00e9 et faire l’objet d’une acceptation du risque au moyen d’un processus formel.<\/p>\n\n\n\n Une fois la liste compl\u00e9t\u00e9e, les r\u00e9ponses individuelles devraient se consolider en un petit nombre de domaines de d\u00e9cision qu’un comit\u00e9 de s\u00e9lection peut valider.<\/p>\n\n\n\n Un outil SAST ne devrait pas \u00eatre approuv\u00e9<\/strong> pour un CI\/CD d’entreprise si :<\/p>\n\n\n\n Les auditeurs devraient v\u00e9rifier que l’outil SAST applique les politiques de s\u00e9curit\u00e9 de mani\u00e8re coh\u00e9rente et que la configuration des politiques est gouvern\u00e9e.<\/p>\n\n\n\n Points de v\u00e9rification<\/strong><\/p>\n\n\n\n Question de l’auditeur :<\/strong> l’organisation peut-elle d\u00e9montrer qui a modifi\u00e9 les politiques SAST, quand et pourquoi ?<\/p>\n\n\n\n Les auditeurs devraient v\u00e9rifier que l’outil SAST est int\u00e9gr\u00e9 au pipeline de livraison logicielle en tant que contr\u00f4le automatis\u00e9 et contraignant.<\/p>\n\n\n\n Points de v\u00e9rification<\/strong><\/p>\n\n\n\n Question de l’auditeur :<\/strong> l’organisation peut-elle d\u00e9montrer que le SAST s’ex\u00e9cute \u00e0 chaque ex\u00e9cution de pipeline pertinente et que les lacunes sont d\u00e9tect\u00e9es ?<\/p>\n\n\n\n La gouvernance de la mani\u00e8re dont les constats sont tri\u00e9s, supprim\u00e9s et r\u00e9solus est aussi importante que la capacit\u00e9 de d\u00e9tection de l’outil.<\/p>\n\n\n\n Points de v\u00e9rification<\/strong><\/p>\n\n\n\n Question de l’auditeur :<\/strong> l’organisation peut-elle produire une piste d’audit compl\u00e8te pour tout constat supprim\u00e9 ou accept\u00e9 ?<\/p>\n\n\n\n Les auditeurs devraient v\u00e9rifier que la couverture SAST s’aligne sur le portefeuille applicatif et le profil de risque de l’organisation.<\/p>\n\n\n\n Points de v\u00e9rification<\/strong><\/p>\n\n\n\n Question de l’auditeur :<\/strong> l’organisation peut-elle d\u00e9montrer quelles applications sont couvertes par le SAST et lesquelles ne le sont pas \u2014 et pourquoi ?<\/p>\n\n\n\n La production de preuves est un axe d’audit primordial. Les auditeurs devraient v\u00e9rifier que l’outil SAST et les processus qui l’entourent produisent des preuves fiables et r\u00e9sistantes \u00e0 l’alt\u00e9ration.<\/p>\n\n\n\n Points de v\u00e9rification<\/strong><\/p>\n\n\n\n Question de l’auditeur :<\/strong> l’organisation peut-elle produire des preuves SAST pour n’importe quelle release donn\u00e9e, en rattachant les constats au commit et \u00e0 l’ex\u00e9cution de pipeline pr\u00e9cis ?<\/p>\n\n\n\n Les auditeurs devraient \u00e9valuer si l’organisation g\u00e8re l’outillage SAST comme une capacit\u00e9 gouvern\u00e9e dot\u00e9e d’un cycle de vie d\u00e9fini, et non comme une d\u00e9cision d’achat ponctuelle.<\/p>\n\n\n\n Les cinq \u00e9tapes de la gouvernance de l’outil :<\/strong><\/p>\n\n\n\n Chaque \u00e9tape devrait produire des preuves auditables. L’absence de l’une d’elles signale une lacune de gouvernance.<\/p>\n\n\n\n Les appels d’offres (RFP) sont le m\u00e9canisme le plus courant qu’utilisent les grandes organisations pour s\u00e9lectionner un outil SAST ; pourtant, dans les environnements r\u00e9glement\u00e9s, de nombreux RFP SAST \u00e9chouent \u2014 non pas au moment de l’achat, mais des mois plus tard, lors des audits, des incidents ou face \u00e0 la r\u00e9alit\u00e9 op\u00e9rationnelle. La cause est rarement le seul mauvais choix d’outil ; c’est g\u00e9n\u00e9ralement un ensemble de failles structurelles dans la fa\u00e7on dont les exigences SAST sont d\u00e9finies, \u00e9valu\u00e9es et valid\u00e9es. Les sept sch\u00e9mas d’\u00e9chec ci-dessous sont ceux que les auditeurs rencontrent le plus souvent, suivis de ce que les organisations rigoureuses font diff\u00e9remment.<\/p>\n\n\n\n De nombreux RFP se concentrent fortement sur :<\/p>\n\n\n\n Bien que ces aspects soient pertinents, ils ne sont pas d\u00e9cisifs<\/strong> dans les environnements r\u00e9glement\u00e9s.<\/p>\n\n\n\n Les auditeurs ne demandent pas :<\/p>\n\n\n\n \u00ab Combien de vuln\u00e9rabilit\u00e9s votre outil SAST d\u00e9tecte-t-il ? \u00bb<\/p>\n<\/blockquote>\n\n\n\n Ils demandent :<\/p>\n\n\n\n \u00ab Comment appliquez-vous les politiques de codage s\u00e9curis\u00e9 et comment le prouvez-vous dans la dur\u00e9e ? \u00bb<\/p>\n<\/blockquote>\n\n\n\n Lorsqu’un RFP privil\u00e9gie les listes de fonctionnalit\u00e9s au d\u00e9triment de la gouvernance et de l’application, l’outil retenu ne r\u00e9pond souvent pas aux attentes r\u00e9glementaires.<\/p>\n\n\n\n Une exigence fr\u00e9quente des RFP est :<\/p>\n\n\n\n \u00ab L’outil doit s’int\u00e9grer au CI\/CD. \u00bb<\/p>\n<\/blockquote>\n\n\n\n En pratique, cette exigence est interpr\u00e9t\u00e9e de mani\u00e8re trop souple.<\/p>\n\n\n\n Ce qui compte n’est pas l’int\u00e9gration, mais l’application<\/strong> :<\/p>\n\n\n\n#<\/strong><\/th> Domaine de contr\u00f4le<\/strong><\/th> Question d’audit<\/strong><\/th> Oui<\/strong><\/th> Non<\/strong><\/th><\/tr><\/thead> 1<\/strong><\/td> Gouvernance<\/td> L’outil prend-il en charge une application fond\u00e9e sur des politiques (bloquer \/ avertir \/ signaler uniquement) ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 2<\/strong><\/td> Gouvernance<\/td> Les politiques peuvent-elles \u00eatre d\u00e9finies par application, par \u00e9quipe ou par environnement ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 3<\/strong><\/td> Gouvernance<\/td> Les politiques de s\u00e9curit\u00e9 sont-elles versionn\u00e9es et auditables ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 4<\/strong><\/td> Gouvernance<\/td> Les r\u00e8gles peuvent-elles \u00eatre personnalis\u00e9es (s\u00e9v\u00e9rit\u00e9, p\u00e9rim\u00e8tre, exclusions) ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 5<\/strong><\/td> Int\u00e9gration CI\/CD<\/td> L’outil s’int\u00e8gre-t-il nativement aux plateformes CI\/CD d’entreprise ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 6<\/strong><\/td> Int\u00e9gration CI\/CD<\/td> Les analyses peuvent-elles s’ex\u00e9cuter automatiquement sur les PR \/ fusions \/ pipelines ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 7<\/strong><\/td> Int\u00e9gration CI\/CD<\/td> Le pipeline peut-il \u00eatre bloqu\u00e9 en fonction de conditions de politique ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 8<\/strong><\/td> Int\u00e9gration CI\/CD<\/td> Les r\u00e9sultats sont-ils accessibles via une API ou un export (JSON, CSV, etc.) ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 9<\/strong><\/td> Exp\u00e9rience d\u00e9veloppeur<\/td> Les constats sont-ils clairement rattach\u00e9s \u00e0 des emplacements du code source ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 10<\/strong><\/td> Exp\u00e9rience d\u00e9veloppeur<\/td> Des conseils de correction sont-ils fournis pour les constats ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 11<\/strong><\/td> Exp\u00e9rience d\u00e9veloppeur<\/td> Les faux positifs peuvent-ils \u00eatre supprim\u00e9s avec justification ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 12<\/strong><\/td> Pr\u00e9cision<\/td> La logique de d\u00e9tection est-elle explicable (pas uniquement une bo\u00eete noire) ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 13<\/strong><\/td> Pr\u00e9cision<\/td> Le taux de faux positifs est-il acceptable sur des codes r\u00e9els ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 14<\/strong><\/td> Couverture<\/td> L’outil couvre-t-il tous les langages de production dans le p\u00e9rim\u00e8tre ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 15<\/strong><\/td> Couverture<\/td> Les jeux de r\u00e8gles sont-ils activement maintenus et mis \u00e0 jour ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 16<\/strong><\/td> Performance<\/td> Les dur\u00e9es d’analyse sont-elles compatibles avec les contraintes d’ex\u00e9cution CI\/CD ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 17<\/strong><\/td> Performance<\/td> L’outil passe-t-il \u00e0 l’\u00e9chelle sur de nombreux d\u00e9p\u00f4ts \/ \u00e9quipes ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 18<\/strong><\/td> Reporting<\/td> L’outil fournit-il des tendances historiques et le vieillissement des vuln\u00e9rabilit\u00e9s ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 19<\/strong><\/td> Reporting<\/td> Des rapports peuvent-ils \u00eatre g\u00e9n\u00e9r\u00e9s \u00e0 des fins d’audit (pas seulement des tableaux de bord) ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 20<\/strong><\/td> Preuves<\/td> Les constats sont-ils horodat\u00e9s et attribuables \u00e0 une ex\u00e9cution de pipeline ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 21<\/strong><\/td> Preuves<\/td> Les preuves peuvent-elles \u00eatre conserv\u00e9es selon des politiques de r\u00e9tention d\u00e9finies ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 22<\/strong><\/td> Conformit\u00e9<\/td> L’outil rattache-t-il les constats \u00e0 CWE \/ OWASP Top 10 ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 23<\/strong><\/td> Conformit\u00e9<\/td> Les r\u00e9sultats peuvent-ils soutenir les audits ISO 27001 \/ SOC 2 \/ DORA \/ NIS2 ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 24<\/strong><\/td> Exploitation<\/td> L’administration centralis\u00e9e est-elle prise en charge ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 25<\/strong><\/td> Exploitation<\/td> La charge op\u00e9rationnelle est-elle acceptable \u00e0 l’\u00e9chelle de l’entreprise ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 26<\/strong><\/td> \u00c9diteur<\/td> Existe-t-il une feuille de route claire de support et de mises \u00e0 jour ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 27<\/strong><\/td> Strat\u00e9gie<\/td> L’outil peut-il \u00e9voluer d’une simple visibilit\u00e9 vers un contr\u00f4le appliqu\u00e9 ?<\/td> \u2610<\/td> \u2610<\/td><\/tr> 28<\/strong><\/td> Strat\u00e9gie<\/td> L’outil s’inscrit-il dans le mod\u00e8le de SDLC s\u00e9curis\u00e9 de l’organisation ?<\/td> \u2610<\/td> \u2610<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Synth\u00e8se des conclusions d’audit<\/strong><\/h2>\n\n\n\n
Domaine de d\u00e9cision<\/strong><\/th> \u00c9valuation<\/strong><\/th><\/tr><\/thead> Maturit\u00e9 de la gouvernance<\/td> \u2610 R\u00e9ussite \u2610 Conditionnelle \u2610 \u00c9chec<\/td><\/tr> Ad\u00e9quation au CI\/CD<\/td> \u2610 R\u00e9ussite \u2610 Conditionnelle \u2610 \u00c9chec<\/td><\/tr> Risque d’adoption par les d\u00e9veloppeurs<\/td> \u2610 Faible \u2610 Moyen \u2610 \u00c9lev\u00e9<\/td><\/tr> Pr\u00e9paration \u00e0 l’audit<\/td> \u2610 Ad\u00e9quate \u2610 Partielle \u2610 Insuffisante<\/td><\/tr> D\u00e9cision globale<\/strong><\/td> \u2610 Approuv\u00e9 \u2610 Approuv\u00e9 sous conditions \u2610 Rejet\u00e9<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Recommandations \u00e0 l’auditeur<\/strong><\/h2>\n\n\n\n
\n
\n\n\n\n1. Gouvernance et application des politiques<\/strong><\/h2>\n\n\n\n
\n
\n\n\n\n2. Gouvernance de l’int\u00e9gration CI\/CD<\/strong><\/h2>\n\n\n\n
\n
\n\n\n\n3. Gestion des constats et qualit\u00e9 du signal<\/strong><\/h2>\n\n\n\n
\n
\n\n\n\n4. Gouvernance de la couverture et du p\u00e9rim\u00e8tre<\/strong><\/h2>\n\n\n\n
\n
\n\n\n\n5. Reporting, preuves et pr\u00e9paration \u00e0 l’audit<\/strong><\/h2>\n\n\n\n
\n
\n\n\n\nCycle de vie de la gouvernance de l’outil<\/strong><\/h2>\n\n\n\n
\n
\n\n\n\nPourquoi la plupart des RFP SAST \u00e9chouent<\/strong><\/h2>\n\n\n\n
\u00c9chec n\u00b0 1 : traiter le SAST comme une comparaison de fonctionnalit\u00e9s<\/strong><\/h3>\n\n\n\n
\n
\n
\n
\u00c9chec n\u00b0 2 : ignorer la r\u00e9alit\u00e9 de l’application dans le CI\/CD<\/strong><\/h3>\n\n\n\n
\n
\n