{"id":1299,"date":"2026-03-25T17:24:13","date_gmt":"2026-03-25T16:24:13","guid":{"rendered":"https:\/\/regulated-devsecops.com\/uncategorized\/application-security-metrics-auditors-2\/"},"modified":"2026-03-26T00:14:26","modified_gmt":"2026-03-25T23:14:26","slug":"application-security-metrics-auditors","status":"publish","type":"post","link":"https:\/\/regulated-devsecops.com\/fr\/application-security-governance\/application-security-metrics-auditors\/","title":{"rendered":"M\u00e9triques de s\u00e9curit\u00e9 applicative auxquelles les auditeurs peuvent se fier"},"content":{"rendered":"<h2>Pourquoi les m\u00e9triques sont essentielles pour l&rsquo;assurance d&rsquo;audit<\/h2>\n<p>Les contr\u00f4les fonctionnent ou ne fonctionnent pas \u2014 mais le d\u00e9terminer n\u00e9cessite plus qu&rsquo;une v\u00e9rification ponctuelle. Les m\u00e9triques fournissent les preuves longitudinales dont les auditeurs ont besoin pour \u00e9valuer si les contr\u00f4les de s\u00e9curit\u00e9 fonctionnent efficacement <strong>dans le temps<\/strong>, pas seulement le jour de l&rsquo;audit.<\/p>\n<p>Une organisation capable de produire des m\u00e9triques de s\u00e9curit\u00e9 applicative coh\u00e9rentes et g\u00e9n\u00e9r\u00e9es par le syst\u00e8me d\u00e9montre une maturit\u00e9 op\u00e9rationnelle. Une organisation qui ne peut pas produire de m\u00e9triques \u2014 ou qui ne produit que des chiffres compil\u00e9s manuellement \u2014 r\u00e9v\u00e8le une lacune fondamentale dans son environnement de contr\u00f4le.<\/p>\n<p>Pour les responsables conformit\u00e9, les m\u00e9triques servent un double objectif : elles satisfont les exigences de reporting r\u00e9glementaire (DORA, NIS2 et les mandats sectoriels exigent de plus en plus un reporting quantitatif de la s\u00e9curit\u00e9) et fournissent une alerte pr\u00e9coce lorsque les contr\u00f4les se d\u00e9gradent. Un temps moyen de rem\u00e9diation en hausse ou un pourcentage de couverture des tests en baisse signale des probl\u00e8mes avant qu&rsquo;ils ne deviennent des constats d&rsquo;audit.<\/p>\n<p>Ce guide d\u00e9finit les m\u00e9triques qui comptent, explique comment les auditeurs peuvent \u00e9valuer leur fiabilit\u00e9 et identifie les moyens les plus courants de manipulation des m\u00e9triques.<\/p>\n<h2>Cat\u00e9gories de m\u00e9triques AppSec<\/h2>\n<p>Les m\u00e9triques de s\u00e9curit\u00e9 applicative se r\u00e9partissent en quatre cat\u00e9gories, chacune servant un objectif d&rsquo;assurance diff\u00e9rent :<\/p>\n<ul>\n<li><strong>M\u00e9triques de couverture :<\/strong> Mesurent l&rsquo;\u00e9tendue du programme de s\u00e9curit\u00e9 \u2014 quel pourcentage du portefeuille applicatif est test\u00e9 et surveill\u00e9<\/li>\n<li><strong>M\u00e9triques d&rsquo;efficience :<\/strong> Mesurent la qualit\u00e9 de la r\u00e9ponse de l&rsquo;organisation aux constats \u2014 la rapidit\u00e9 de rem\u00e9diation des vuln\u00e9rabilit\u00e9s et l&rsquo;utilisation efficace des ressources<\/li>\n<li><strong>M\u00e9triques de risque :<\/strong> Mesurent l&rsquo;exposition actuelle aux risques \u2014 combien de vuln\u00e9rabilit\u00e9s sont ouvertes, depuis combien de temps et combien ont \u00e9t\u00e9 accept\u00e9es<\/li>\n<li><strong>M\u00e9triques de conformit\u00e9 :<\/strong> Mesurent le respect des politiques internes et des exigences r\u00e9glementaires externes \u2014 si les portes sont appliqu\u00e9es, les SLA respect\u00e9s et les preuves compl\u00e8tes<\/li>\n<\/ul>\n<h2>R\u00e9f\u00e9rentiel des m\u00e9triques cl\u00e9s<\/h2>\n<p>Le tableau suivant fournit un r\u00e9f\u00e9rentiel complet des m\u00e9triques de s\u00e9curit\u00e9 applicative les plus importantes. Pour chaque m\u00e9trique, les auditeurs devraient comprendre ce qu&rsquo;elle mesure, \u00e0 quoi ressemble un objectif raisonnable, d&rsquo;o\u00f9 les donn\u00e9es devraient provenir et comment elle peut \u00eatre manipul\u00e9e.<\/p>\n<table>\n<thead>\n<tr>\n<th>Nom de la m\u00e9trique<\/th>\n<th>Ce qu&rsquo;elle mesure<\/th>\n<th>Objectif \/ Seuil<\/th>\n<th>Source de donn\u00e9es<\/th>\n<th>Risque de manipulation<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Taux de couverture SAST<\/td>\n<td>% d&rsquo;applications avec un scan SAST actif<\/td>\n<td>100% pour Tier 1-3 ; bas\u00e9 sur le risque pour Tier 4<\/td>\n<td>Plateforme SAST, enregistrements du pipeline CI\/CD<\/td>\n<td>Exclure des applications du p\u00e9rim\u00e8tre pour gonfler le pourcentage<\/td>\n<\/tr>\n<tr>\n<td>Taux de couverture DAST<\/td>\n<td>% d&rsquo;applications avec un scan DAST \u00e0 la fr\u00e9quence requise<\/td>\n<td>100% pour Tier 1-2 ; 100% annuellement pour Tier 3<\/td>\n<td>Plateforme DAST, enregistrements du calendrier de scan<\/td>\n<td>Ex\u00e9cuter les scans avec un p\u00e9rim\u00e8tre limit\u00e9 ou des chemins authentifi\u00e9s<\/td>\n<\/tr>\n<tr>\n<td>Taux de couverture SCA<\/td>\n<td>% d&rsquo;applications avec un scan actif des d\u00e9pendances<\/td>\n<td>100% pour Tier 1-3<\/td>\n<td>Plateforme SCA, journaux du pipeline de build<\/td>\n<td>Exclure des d\u00e9p\u00f4ts ou des configurations de build<\/td>\n<\/tr>\n<tr>\n<td>Couverture des mod\u00e8les de menaces<\/td>\n<td>% d&rsquo;applications Tier 1-2 avec des mod\u00e8les de menaces \u00e0 jour<\/td>\n<td>100% pour Tier 1 ; 100% pour Tier 2<\/td>\n<td>Outil de mod\u00e9lisation des menaces ou d\u00e9p\u00f4t documentaire<\/td>\n<td>Cr\u00e9er des mod\u00e8les superficiels ne refl\u00e9tant pas l&rsquo;architecture r\u00e9elle<\/td>\n<\/tr>\n<tr>\n<td>Temps moyen de rem\u00e9diation (Critique)<\/td>\n<td>Jours moyens de l&rsquo;identification de la vuln\u00e9rabilit\u00e9 \u00e0 la correction v\u00e9rifi\u00e9e pour la s\u00e9v\u00e9rit\u00e9 critique<\/td>\n<td>&le;15 jours<\/td>\n<td>Plateforme de gestion des vuln\u00e9rabilit\u00e9s<\/td>\n<td>Abaisser la s\u00e9v\u00e9rit\u00e9 pour \u00e9viter le SLA ; fermer sans v\u00e9rification<\/td>\n<\/tr>\n<tr>\n<td>Temps moyen de rem\u00e9diation (\u00c9lev\u00e9)<\/td>\n<td>Jours moyens de l&rsquo;identification \u00e0 la correction v\u00e9rifi\u00e9e pour la s\u00e9v\u00e9rit\u00e9 \u00e9lev\u00e9e<\/td>\n<td>&le;30 jours<\/td>\n<td>Plateforme de gestion des vuln\u00e9rabilit\u00e9s<\/td>\n<td>Idem<\/td>\n<\/tr>\n<tr>\n<td>Taux de r\u00e9ouverture des vuln\u00e9rabilit\u00e9s<\/td>\n<td>% de vuln\u00e9rabilit\u00e9s ferm\u00e9es puis r\u00e9apparues<\/td>\n<td>&lt;5%<\/td>\n<td>Plateforme de gestion des vuln\u00e9rabilit\u00e9s<\/td>\n<td>Red\u00e9finir les crit\u00e8res de r\u00e9ouverture ; cr\u00e9er de nouveaux tickets au lieu de rouvrir<\/td>\n<\/tr>\n<tr>\n<td>Taux de faux positifs<\/td>\n<td>% de constats marqu\u00e9s comme faux positifs apr\u00e8s triage<\/td>\n<td>&lt;20% (varie selon l&rsquo;outil)<\/td>\n<td>Outils de tests de s\u00e9curit\u00e9, enregistrements de triage<\/td>\n<td>Classifier des vrais positifs comme faux pour r\u00e9duire la charge de travail<\/td>\n<\/tr>\n<tr>\n<td>Vuln\u00e9rabilit\u00e9s critiques\/\u00e9lev\u00e9es ouvertes<\/td>\n<td>Nombre de vuln\u00e9rabilit\u00e9s critiques et de haute s\u00e9v\u00e9rit\u00e9 non r\u00e9solues<\/td>\n<td>Tendance \u00e0 la baisse ; z\u00e9ro critique dans les apps Tier 1<\/td>\n<td>Plateforme de gestion des vuln\u00e9rabilit\u00e9s<\/td>\n<td>Abaisser la s\u00e9v\u00e9rit\u00e9 ; passer en acceptation de risque sans approbation ad\u00e9quate<\/td>\n<\/tr>\n<tr>\n<td>\u00c2ge des vuln\u00e9rabilit\u00e9s (P90)<\/td>\n<td>90e percentile de l&rsquo;\u00e2ge des vuln\u00e9rabilit\u00e9s ouvertes<\/td>\n<td>Dans le SLA pour chaque niveau de s\u00e9v\u00e9rit\u00e9<\/td>\n<td>Plateforme de gestion des vuln\u00e9rabilit\u00e9s<\/td>\n<td>R\u00e9initialiser la date de d\u00e9couverte ; fermer et rouvrir<\/td>\n<\/tr>\n<tr>\n<td>Nombre d&rsquo;exceptions\/suppressions<\/td>\n<td>Nombre d&rsquo;exceptions ou suppressions actives de vuln\u00e9rabilit\u00e9s<\/td>\n<td>Tendance stable ou \u00e0 la baisse ; chacune avec approbation document\u00e9e<\/td>\n<td>Registre des exceptions, plateforme de vuln\u00e9rabilit\u00e9s<\/td>\n<td>Suppression informelle en dehors des syst\u00e8mes suivis<\/td>\n<\/tr>\n<tr>\n<td>Arri\u00e9r\u00e9 d&rsquo;acceptation de risques<\/td>\n<td>Nombre de risques formellement accept\u00e9s avec dates de revue ouvertes<\/td>\n<td>Tous dans la p\u00e9riode de revue ; aucun en retard<\/td>\n<td>Registre des risques<\/td>\n<td>Fixer des dates de revue lointaines pour \u00e9viter la r\u00e9\u00e9valuation<\/td>\n<\/tr>\n<tr>\n<td>Taux de passage des portes de politique<\/td>\n<td>% de releases passant toutes les portes de politique de s\u00e9curit\u00e9 au premier essai<\/td>\n<td>&gt;80% (en am\u00e9lioration)<\/td>\n<td>Pipeline CI\/CD, journaux du moteur de politique<\/td>\n<td>Affaiblir les crit\u00e8res des portes pour augmenter le taux de passage<\/td>\n<\/tr>\n<tr>\n<td>Taux de contournement d&rsquo;approbation<\/td>\n<td>% de releases ayant contourn\u00e9 les approbations de s\u00e9curit\u00e9 requises<\/td>\n<td>&lt;2% ; tous avec exception document\u00e9e<\/td>\n<td>Syst\u00e8me de gestion des changements, journaux du pipeline<\/td>\n<td>Utiliser les proc\u00e9dures d&rsquo;urgence de mani\u00e8re routini\u00e8re<\/td>\n<\/tr>\n<tr>\n<td>Taux de conformit\u00e9 aux SLA<\/td>\n<td>% de vuln\u00e9rabilit\u00e9s rem\u00e9di\u00e9es dans le SLA d\u00e9fini<\/td>\n<td>&gt;90%<\/td>\n<td>Plateforme de gestion des vuln\u00e9rabilit\u00e9s<\/td>\n<td>Ajuster les d\u00e9finitions de SLA ; mettre en pause les compteurs de SLA<\/td>\n<\/tr>\n<tr>\n<td>Score de compl\u00e9tude des preuves<\/td>\n<td>% d&rsquo;artefacts de preuves d&rsquo;audit requis qui sont disponibles et \u00e0 jour<\/td>\n<td>&gt;95%<\/td>\n<td>D\u00e9p\u00f4t de preuves, plateforme GRC<\/td>\n<td>G\u00e9n\u00e9rer les preuves r\u00e9trospectivement avant l&rsquo;audit<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>M\u00e9triques de couverture en d\u00e9tail<\/h2>\n<p>Les m\u00e9triques de couverture r\u00e9pondent \u00e0 la question : <strong>l&rsquo;organisation teste-t-elle ce qu&rsquo;elle devrait tester ?<\/strong><\/p>\n<p>La m\u00e9trique de couverture la plus fondamentale est le pourcentage d&rsquo;applications b\u00e9n\u00e9ficiant de tests de s\u00e9curit\u00e9 actifs par rapport \u00e0 l&rsquo;inventaire total des applications. Cela devrait \u00eatre segment\u00e9 par niveau d&rsquo;application, car un taux de couverture global de 90% pourrait masquer le fait que plusieurs applications critiques de Tier 1 ne sont pas test\u00e9es.<\/p>\n<p>Les auditeurs devraient demander les donn\u00e9es de couverture ventil\u00e9es comme suit :<\/p>\n<ul>\n<li>Couverture SAST par niveau d&rsquo;application<\/li>\n<li>Couverture DAST par niveau d&rsquo;application, avec v\u00e9rification de la fr\u00e9quence<\/li>\n<li>Couverture SCA par niveau d&rsquo;application<\/li>\n<li>Pourcentage d&rsquo;applications critiques avec des mod\u00e8les de menaces \u00e0 jour<\/li>\n<li>Couverture des tests de s\u00e9curit\u00e9 par niveau d&rsquo;application compar\u00e9e \u00e0 la fr\u00e9quence requise d\u00e9finie dans le cadre de classification<\/li>\n<\/ul>\n<p>Une m\u00e9trique de couverture n&rsquo;est significative que si le d\u00e9nominateur est exact. Si l&rsquo;inventaire des applications est incomplet, les pourcentages de couverture sont trompeurs. Les auditeurs devraient recouper l&rsquo;inventaire des applications utilis\u00e9 pour les calculs de couverture avec d&rsquo;autres sources (CMDB, plateformes de d\u00e9ploiement, inventaires de comptes cloud) pour v\u00e9rifier la compl\u00e9tude.<\/p>\n<h2>M\u00e9triques d&rsquo;efficience en d\u00e9tail<\/h2>\n<p>Les m\u00e9triques d&rsquo;efficience r\u00e9pondent \u00e0 la question : <strong>lorsque l&rsquo;organisation trouve des vuln\u00e9rabilit\u00e9s, les corrige-t-elle efficacement ?<\/strong><\/p>\n<p><strong>Le temps moyen de rem\u00e9diation (MTTR)<\/strong> est la m\u00e9trique d&rsquo;efficience la plus importante. Elle devrait \u00eatre suivie par niveau de s\u00e9v\u00e9rit\u00e9 et par niveau d&rsquo;application, car un MTTR moyen de 30 jours est acceptable pour les constats de haute s\u00e9v\u00e9rit\u00e9 mais pas pour les constats critiques dans les applications de Tier 1.<\/p>\n<p>Le MTTR devrait \u00eatre mesur\u00e9 de la date d&rsquo;identification (lorsque le constat a \u00e9t\u00e9 signal\u00e9 pour la premi\u00e8re fois par un outil de scan ou un testeur) \u00e0 la date de rem\u00e9diation v\u00e9rifi\u00e9e (lorsqu&rsquo;un re-scan ou un retest confirme l&rsquo;efficacit\u00e9 de la correction). Les organisations qui mesurent jusqu&rsquo;\u00e0 la date o\u00f9 le d\u00e9veloppeur ferme le ticket \u2014 sans v\u00e9rification \u2014 rapportent une m\u00e9trique incompl\u00e8te.<\/p>\n<p><strong>Le taux de r\u00e9ouverture des vuln\u00e9rabilit\u00e9s<\/strong> indique la qualit\u00e9 des corrections. Un taux sup\u00e9rieur \u00e0 5% sugg\u00e8re que les rem\u00e9diations sont superficielles ou que les causes racines ne sont pas trait\u00e9es.<\/p>\n<p><strong>Le taux de faux positifs<\/strong> indique l&rsquo;efficacit\u00e9 de l&rsquo;outil et la qualit\u00e9 du triage. Un taux de faux positifs anormalement \u00e9lev\u00e9 peut indiquer que les constats sont rejet\u00e9s comme faux positifs plut\u00f4t qu&rsquo;investigu\u00e9s \u2014 les auditeurs devraient \u00e9chantillonner les classifications de faux positifs pour v\u00e9rifier leur l\u00e9gitimit\u00e9.<\/p>\n<p><strong>Le temps de cycle scan-\u00e0-correction<\/strong> mesure le temps \u00e9coul\u00e9 de bout en bout entre la fin d&rsquo;un scan et la r\u00e9solution de tous les constats de ce scan. Cela capture les retards de triage et d&rsquo;assignation que le MTTR seul peut ne pas r\u00e9v\u00e9ler.<\/p>\n<h2>M\u00e9triques de risque en d\u00e9tail<\/h2>\n<p>Les m\u00e9triques de risque r\u00e9pondent \u00e0 la question : <strong>quelle est l&rsquo;exposition actuelle aux vuln\u00e9rabilit\u00e9s et est-elle g\u00e9r\u00e9e ?<\/strong><\/p>\n<p>Le <strong>nombre de vuln\u00e9rabilit\u00e9s critiques et de haute s\u00e9v\u00e9rit\u00e9 ouvertes<\/strong> est une m\u00e9trique de risque de base. Elle devrait \u00eatre suivie comme une tendance dans le temps \u2014 un nombre stable ou en baisse indique un programme efficace ; un nombre en hausse indique que les constats sont g\u00e9n\u00e9r\u00e9s plus vite qu&rsquo;ils ne sont rem\u00e9di\u00e9s.<\/p>\n<p><strong>Le vieillissement des vuln\u00e9rabilit\u00e9s<\/strong> mesure la dur\u00e9e pendant laquelle les vuln\u00e9rabilit\u00e9s restent ouvertes. Le 90e percentile est plus utile que la moyenne car les moyennes peuvent \u00eatre fauss\u00e9es par un grand nombre de constats de faible s\u00e9v\u00e9rit\u00e9 rapidement r\u00e9solus. Si le P90 d\u00e9passe le SLA, l&rsquo;organisation ne respecte pas ses propres engagements de rem\u00e9diation pour une part significative des constats.<\/p>\n<p><strong>Les nombres d&rsquo;exceptions et de suppressions<\/strong> r\u00e9v\u00e8lent comment l&rsquo;organisation g\u00e8re les constats qu&rsquo;elle choisit de ne pas corriger. Chaque exception devrait avoir une approbation document\u00e9e, un contr\u00f4le compensatoire et une date de revue. Un nombre croissant d&rsquo;exceptions sans justification correspondante indique que le processus d&rsquo;exception est utilis\u00e9 pour \u00e9viter la rem\u00e9diation plut\u00f4t que pour g\u00e9rer un risque r\u00e9el.<\/p>\n<p><strong>L&rsquo;arri\u00e9r\u00e9 d&rsquo;acceptation de risques<\/strong> suit les risques formellement accept\u00e9s. Les auditeurs devraient v\u00e9rifier que chaque risque accept\u00e9 a un propri\u00e9taire, une justification document\u00e9e, un contr\u00f4le compensatoire et une date de revue \u2014 et que les revues en retard sont escalad\u00e9es.<\/p>\n<h2>M\u00e9triques de conformit\u00e9 en d\u00e9tail<\/h2>\n<p>Les m\u00e9triques de conformit\u00e9 r\u00e9pondent \u00e0 la question : <strong>l&rsquo;organisation suit-elle ses propres politiques et respecte-t-elle les exigences r\u00e9glementaires ?<\/strong><\/p>\n<p><strong>Le taux de passage des portes de politique<\/strong> mesure la fr\u00e9quence \u00e0 laquelle les releases passent les portes de s\u00e9curit\u00e9 au premier essai. Un taux tr\u00e8s faible peut indiquer que les exigences de s\u00e9curit\u00e9 ne sont pas claires ou que les \u00e9quipes de d\u00e9veloppement ne re\u00e7oivent pas de retour suffisamment t\u00f4t. Un taux suspectemment \u00e9lev\u00e9 (approchant les 100%) peut indiquer que les portes sont trop permissives.<\/p>\n<p><strong>Le taux de contournement d&rsquo;approbation<\/strong> est une m\u00e9trique de contr\u00f4le critique. Dans les environnements r\u00e9glement\u00e9s, chaque contournement devrait \u00eatre document\u00e9 avec une approbation d&rsquo;exception. Un taux de contournement sup\u00e9rieur \u00e0 2% \u2014 ou tout contournement sans approbation document\u00e9e \u2014 est un constat significatif.<\/p>\n<p><strong>Le taux de conformit\u00e9 aux SLA<\/strong> mesure si les vuln\u00e9rabilit\u00e9s sont rem\u00e9di\u00e9es dans les d\u00e9lais d\u00e9finis dans la politique de gestion des vuln\u00e9rabilit\u00e9s. Cela devrait \u00eatre suivi par s\u00e9v\u00e9rit\u00e9 et par niveau. Les organisations qui manquent syst\u00e9matiquement les SLA pour les constats critiques dans les applications de Tier 1 pr\u00e9sentent une faiblesse mat\u00e9rielle de contr\u00f4le.<\/p>\n<p><strong>Le score de compl\u00e9tude des preuves<\/strong> mesure l&rsquo;\u00e9tat de pr\u00e9paration de l&rsquo;organisation \u00e0 l&rsquo;audit en suivant le pourcentage d&rsquo;artefacts de preuves requis qui sont disponibles, \u00e0 jour et correctement stock\u00e9s. C&rsquo;est une m\u00e9ta-m\u00e9trique qui indique la maturit\u00e9 de la gouvernance.<\/p>\n<h2>Ce qui rend une m\u00e9trique fiable pour les auditeurs<\/h2>\n<p>Toutes les m\u00e9triques ne sont pas \u00e9galement fiables. Les auditeurs devraient \u00e9valuer la fiabilit\u00e9 des m\u00e9triques rapport\u00e9es selon les crit\u00e8res suivants :<\/p>\n<ul>\n<li><strong>G\u00e9n\u00e9r\u00e9e par le syst\u00e8me :<\/strong> La m\u00e9trique est produite automatiquement par un outil ou une plateforme de s\u00e9curit\u00e9, et non compil\u00e9e manuellement dans un tableur. La compilation manuelle introduit \u00e0 la fois des erreurs et des risques de manipulation.<\/li>\n<li><strong>R\u00e9sistante \u00e0 la falsification :<\/strong> La source de donn\u00e9es dispose de contr\u00f4les d&rsquo;acc\u00e8s et de journaux d&rsquo;audit qui emp\u00eachent toute modification non autoris\u00e9e. Les m\u00e9triques issues d&rsquo;un tableau de bord en lecture seule connect\u00e9 \u00e0 une source de donn\u00e9es contr\u00f4l\u00e9e sont plus fiables que des rapports export\u00e9s.<\/li>\n<li><strong>M\u00e9thodologie coh\u00e9rente :<\/strong> La m\u00e9trique est calcul\u00e9e de la m\u00eame mani\u00e8re \u00e0 chaque p\u00e9riode de reporting. Les changements de m\u00e9thodologie (par exemple, modifier le calcul du MTTR en cours d&rsquo;ann\u00e9e) doivent \u00eatre document\u00e9s et justifi\u00e9s.<\/li>\n<li><strong>Historiques de tendances disponibles :<\/strong> Au moins 12 mois de donn\u00e9es historiques sont disponibles pour identifier les tendances. Un seul point de donn\u00e9es est une mesure, pas une m\u00e9trique \u2014 les tendances r\u00e9v\u00e8lent si les contr\u00f4les s&rsquo;am\u00e9liorent, sont stables ou se d\u00e9gradent.<\/li>\n<li><strong>Segment\u00e9e par niveau de risque :<\/strong> Les m\u00e9triques agr\u00e9g\u00e9es masquent des variations importantes. Les m\u00e9triques devraient \u00eatre disponibles par niveau d&rsquo;application, par unit\u00e9 m\u00e9tier ou par s\u00e9v\u00e9rit\u00e9 pour permettre une analyse significative.<\/li>\n<li><strong>R\u00e9conciliable :<\/strong> La m\u00e9trique peut \u00eatre retrac\u00e9e jusqu&rsquo;aux donn\u00e9es sous-jacentes. Si le MTTR est rapport\u00e9 \u00e0 12 jours, les auditeurs devraient pouvoir consulter les enregistrements individuels de rem\u00e9diation qui produisent cette moyenne.<\/li>\n<\/ul>\n<h2>M\u00e9triques manipulables \u2014 et comment les auditeurs peuvent le d\u00e9tecter<\/h2>\n<p>Les m\u00e9triques ne sont utiles que si elles refl\u00e8tent la r\u00e9alit\u00e9. Voici les techniques de manipulation les plus courantes et les proc\u00e9dures d&rsquo;audit pour les d\u00e9tecter :<\/p>\n<h3>Abaissement de la s\u00e9v\u00e9rit\u00e9<\/h3>\n<p>Les vuln\u00e9rabilit\u00e9s sont r\u00e9trograd\u00e9es de critique \u00e0 \u00e9lev\u00e9, ou d&rsquo;\u00e9lev\u00e9 \u00e0 moyen, pour \u00e9viter de d\u00e9clencher les exigences de SLA ou les seuils de reporting ex\u00e9cutif.<\/p>\n<p><strong>D\u00e9tection :<\/strong> Comparer les distributions de s\u00e9v\u00e9rit\u00e9 dans le temps. Une diminution soudaine des constats critiques avec une augmentation correspondante des constats \u00e9lev\u00e9s est suspecte. \u00c9chantillonner les constats r\u00e9trograd\u00e9s et \u00e9valuer si le changement de s\u00e9v\u00e9rit\u00e9 \u00e9tait justifi\u00e9 et approuv\u00e9.<\/p>\n<h3>Fermetures en masse avant l&rsquo;audit<\/h3>\n<p>Un grand nombre de vuln\u00e9rabilit\u00e9s sont ferm\u00e9es juste avant une p\u00e9riode d&rsquo;audit, soit par acceptation massive du risque, soit en marquant les constats comme r\u00e9solus sans v\u00e9rification.<\/p>\n<p><strong>D\u00e9tection :<\/strong> Tracer les dates de fermeture des vuln\u00e9rabilit\u00e9s sur une chronologie. Le regroupement des fermetures avant les p\u00e9riodes d&rsquo;audit est un indicateur clair. Demander des preuves de retest pour un \u00e9chantillon de constats r\u00e9cemment ferm\u00e9s.<\/p>\n<h3>Exclusion d&rsquo;applications du p\u00e9rim\u00e8tre<\/h3>\n<p>Des applications sont retir\u00e9es de l&rsquo;inventaire ou exclues du scanning pour am\u00e9liorer les pourcentages de couverture et r\u00e9duire le nombre total de vuln\u00e9rabilit\u00e9s.<\/p>\n<p><strong>D\u00e9tection :<\/strong> Comparer l&rsquo;inventaire des applications utilis\u00e9 pour les m\u00e9triques avec d&rsquo;autres sources faisant autorit\u00e9 (inventaires de comptes cloud, enregistrements de plateforme de d\u00e9ploiement, scans r\u00e9seau). Tout \u00e9cart n\u00e9cessite une explication.<\/p>\n<h3>R\u00e9initialisation des dates de d\u00e9couverte<\/h3>\n<p>Les vuln\u00e9rabilit\u00e9s sont ferm\u00e9es puis rouvertes (ou de nouveaux tickets sont cr\u00e9\u00e9s pour le m\u00eame constat) pour r\u00e9initialiser le compteur des m\u00e9triques de vieillissement.<\/p>\n<p><strong>D\u00e9tection :<\/strong> Rechercher des constats avec des descriptions identiques et des dates de cr\u00e9ation diff\u00e9rentes. V\u00e9rifier si la plateforme de gestion des vuln\u00e9rabilit\u00e9s suit la date de d\u00e9couverte originale s\u00e9par\u00e9ment de la date de cr\u00e9ation du ticket.<\/p>\n<h3>Affaiblissement des crit\u00e8res des portes<\/h3>\n<p>Les seuils des portes de politique sont assouplis (par exemple, passer le seuil de blocage de \u00ab aucun \u00e9lev\u00e9 ou critique \u00bb \u00e0 \u00ab aucun critique uniquement \u00bb) pour am\u00e9liorer les taux de passage sans am\u00e9liorer la s\u00e9curit\u00e9 r\u00e9elle.<\/p>\n<p><strong>D\u00e9tection :<\/strong> Demander l&rsquo;historique des modifications des configurations des portes de politique. Tout changement de seuil devrait \u00eatre approuv\u00e9 par le processus de gouvernance et document\u00e9 avec une justification.<\/p>\n<h2>Cadence de reporting recommand\u00e9e<\/h2>\n<p>Les diff\u00e9rentes parties prenantes ont besoin de diff\u00e9rents niveaux de d\u00e9tail \u00e0 diff\u00e9rentes fr\u00e9quences. La cadence suivante \u00e9quilibre les besoins op\u00e9rationnels et les exigences de gouvernance :<\/p>\n<table>\n<thead>\n<tr>\n<th>Niveau de reporting<\/th>\n<th>Fr\u00e9quence<\/th>\n<th>Audience<\/th>\n<th>Contenu<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Op\u00e9rationnel<\/strong><\/td>\n<td>Hebdomadaire<\/td>\n<td>\u00c9quipe AppSec, Security Champions, responsables d&rsquo;\u00e9quipes de d\u00e9veloppement<\/td>\n<td>Nouveaux constats, progr\u00e8s de rem\u00e9diation, \u00e9l\u00e9ments en retard, \u00e9checs de scan, actions imm\u00e9diates<\/td>\n<\/tr>\n<tr>\n<td><strong>Management<\/strong><\/td>\n<td>Mensuel<\/td>\n<td>CISO, responsable AppSec, directeurs du d\u00e9veloppement, responsable conformit\u00e9<\/td>\n<td>Analyse de tendances, MTTR par s\u00e9v\u00e9rit\u00e9\/niveau, \u00e9volution de la couverture, conformit\u00e9 aux SLA, synth\u00e8se des exceptions, risques \u00e9mergents<\/td>\n<\/tr>\n<tr>\n<td><strong>Ex\u00e9cutif \/ Audit<\/strong><\/td>\n<td>Trimestriel<\/td>\n<td>Conseil \/ Comit\u00e9 des risques, auditeurs externes, r\u00e9gulateurs<\/td>\n<td>Synth\u00e8se de la posture de risque, \u00e9valuation de la maturit\u00e9 du programme, tendances des m\u00e9triques cl\u00e9s (vue sur 12 mois), constats significatifs, \u00e9tat de conformit\u00e9 r\u00e9glementaire, ad\u00e9quation des ressources<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Pour les organisations r\u00e9glement\u00e9es soumises \u00e0 DORA, le reporting trimestriel \u00e0 l&rsquo;organe de direction sur le risque ICT \u2014 y compris la s\u00e9curit\u00e9 applicative \u2014 est une attente r\u00e9glementaire, pas une simple recommandation de bonne pratique.<\/p>\n<h2>Lectures compl\u00e9mentaires<\/h2>\n<p>Pour des conseils connexes sur les contr\u00f4les de s\u00e9curit\u00e9 applicative et l&rsquo;\u00e9valuation d&rsquo;audit, voir :<\/p>\n<ul>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/application-security\/\">Vue d&rsquo;ensemble de la s\u00e9curit\u00e9 applicative<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/how-auditors-assess-application-security-controls\/\">Comment les auditeurs \u00e9valuent les contr\u00f4les de s\u00e9curit\u00e9 applicative<\/a><\/li>\n<\/ul>\n<hr\/>\n<h3>Ressources connexes pour les auditeurs<\/h3>\n<ul>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/\">Glossaire<\/a> \u2014 D\u00e9finitions en langage clair des termes techniques<\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/executive-audit-briefing-ci-cd-pipelines-in-regulated-environments\/\">Briefing d&rsquo;audit ex\u00e9cutif<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/before-the-auditor-arrives-ci-cd-audit-readiness-checklist\/\">Checklist de pr\u00e9paration \u00e0 l&rsquo;audit<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/continuous-compliance-via-ci-cd\/\">Conformit\u00e9 continue via CI\/CD<\/a><\/li>\n<\/ul>\n<p><em>Nouveau dans l&rsquo;audit CI\/CD ? Commencez par notre <a href=\"https:\/\/regulated-devsecops.com\/fr\/start-here\/\">Guide de l&rsquo;auditeur<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Pourquoi les m\u00e9triques sont essentielles pour l&rsquo;assurance d&rsquo;audit Les contr\u00f4les fonctionnent ou ne fonctionnent pas \u2014 mais le d\u00e9terminer n\u00e9cessite plus qu&rsquo;une v\u00e9rification ponctuelle. Les m\u00e9triques fournissent les preuves longitudinales dont les auditeurs ont besoin pour \u00e9valuer si les contr\u00f4les de s\u00e9curit\u00e9 fonctionnent efficacement dans le temps, pas seulement le jour de l&rsquo;audit. Une organisation &#8230; <a title=\"M\u00e9triques de s\u00e9curit\u00e9 applicative auxquelles les auditeurs peuvent se fier\" class=\"read-more\" href=\"https:\/\/regulated-devsecops.com\/fr\/application-security-governance\/application-security-metrics-auditors\/\" aria-label=\"En savoir plus sur M\u00e9triques de s\u00e9curit\u00e9 applicative auxquelles les auditeurs peuvent se fier\">Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[122,121],"tags":[],"post_folder":[],"class_list":["post-1299","post","type-post","status-publish","format-standard","hentry","category-audit-evidence","category-application-security-governance"],"_links":{"self":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/posts\/1299","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/comments?post=1299"}],"version-history":[{"count":0,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/posts\/1299\/revisions"}],"wp:attachment":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/media?parent=1299"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/categories?post=1299"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/tags?post=1299"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/post_folder?post=1299"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}