Métriques de sécurité applicative auxquelles les auditeurs peuvent se fier

par

Pourquoi les métriques sont essentielles pour l’assurance d’audit

Les contrôles fonctionnent ou ne fonctionnent pas — mais le déterminer nécessite plus qu’une vérification ponctuelle. Les métriques fournissent les preuves longitudinales dont les auditeurs ont besoin pour évaluer si les contrôles de sécurité fonctionnent efficacement dans le temps, pas seulement le jour de l’audit.

Une organisation capable de produire des métriques de sécurité applicative cohérentes et générées par le système démontre une maturité opérationnelle. Une organisation qui ne peut pas produire de métriques — ou qui ne produit que des chiffres compilés manuellement — révèle une lacune fondamentale dans son environnement de contrôle.

Pour les responsables conformité, les métriques servent un double objectif : elles satisfont les exigences de reporting réglementaire (DORA, NIS2 et les mandats sectoriels exigent de plus en plus un reporting quantitatif de la sécurité) et fournissent une alerte précoce lorsque les contrôles se dégradent. Un temps moyen de remédiation en hausse ou un pourcentage de couverture des tests en baisse signale des problèmes avant qu’ils ne deviennent des constats d’audit.

Ce guide définit les métriques qui comptent, explique comment les auditeurs peuvent évaluer leur fiabilité et identifie les moyens les plus courants de manipulation des métriques.

Catégories de métriques AppSec

Les métriques de sécurité applicative se répartissent en quatre catégories, chacune servant un objectif d’assurance différent :

  • Métriques de couverture : Mesurent l’étendue du programme de sécurité — quel pourcentage du portefeuille applicatif est testé et surveillé
  • Métriques d’efficience : Mesurent la qualité de la réponse de l’organisation aux constats — la rapidité de remédiation des vulnérabilités et l’utilisation efficace des ressources
  • Métriques de risque : Mesurent l’exposition actuelle aux risques — combien de vulnérabilités sont ouvertes, depuis combien de temps et combien ont été acceptées
  • Métriques de conformité : Mesurent le respect des politiques internes et des exigences réglementaires externes — si les portes sont appliquées, les SLA respectés et les preuves complètes

Référentiel des métriques clés

Le tableau suivant fournit un référentiel complet des métriques de sécurité applicative les plus importantes. Pour chaque métrique, les auditeurs devraient comprendre ce qu’elle mesure, à quoi ressemble un objectif raisonnable, d’où les données devraient provenir et comment elle peut être manipulée.

Nom de la métrique Ce qu’elle mesure Objectif / Seuil Source de données Risque de manipulation
Taux de couverture SAST % d’applications avec un scan SAST actif 100% pour Tier 1-3 ; basé sur le risque pour Tier 4 Plateforme SAST, enregistrements du pipeline CI/CD Exclure des applications du périmètre pour gonfler le pourcentage
Taux de couverture DAST % d’applications avec un scan DAST à la fréquence requise 100% pour Tier 1-2 ; 100% annuellement pour Tier 3 Plateforme DAST, enregistrements du calendrier de scan Exécuter les scans avec un périmètre limité ou des chemins authentifiés
Taux de couverture SCA % d’applications avec un scan actif des dépendances 100% pour Tier 1-3 Plateforme SCA, journaux du pipeline de build Exclure des dépôts ou des configurations de build
Couverture des modèles de menaces % d’applications Tier 1-2 avec des modèles de menaces à jour 100% pour Tier 1 ; 100% pour Tier 2 Outil de modélisation des menaces ou dépôt documentaire Créer des modèles superficiels ne reflétant pas l’architecture réelle
Temps moyen de remédiation (Critique) Jours moyens de l’identification de la vulnérabilité à la correction vérifiée pour la sévérité critique ≤15 jours Plateforme de gestion des vulnérabilités Abaisser la sévérité pour éviter le SLA ; fermer sans vérification
Temps moyen de remédiation (Élevé) Jours moyens de l’identification à la correction vérifiée pour la sévérité élevée ≤30 jours Plateforme de gestion des vulnérabilités Idem
Taux de réouverture des vulnérabilités % de vulnérabilités fermées puis réapparues <5% Plateforme de gestion des vulnérabilités Redéfinir les critères de réouverture ; créer de nouveaux tickets au lieu de rouvrir
Taux de faux positifs % de constats marqués comme faux positifs après triage <20% (varie selon l’outil) Outils de tests de sécurité, enregistrements de triage Classifier des vrais positifs comme faux pour réduire la charge de travail
Vulnérabilités critiques/élevées ouvertes Nombre de vulnérabilités critiques et de haute sévérité non résolues Tendance à la baisse ; zéro critique dans les apps Tier 1 Plateforme de gestion des vulnérabilités Abaisser la sévérité ; passer en acceptation de risque sans approbation adéquate
Âge des vulnérabilités (P90) 90e percentile de l’âge des vulnérabilités ouvertes Dans le SLA pour chaque niveau de sévérité Plateforme de gestion des vulnérabilités Réinitialiser la date de découverte ; fermer et rouvrir
Nombre d’exceptions/suppressions Nombre d’exceptions ou suppressions actives de vulnérabilités Tendance stable ou à la baisse ; chacune avec approbation documentée Registre des exceptions, plateforme de vulnérabilités Suppression informelle en dehors des systèmes suivis
Arriéré d’acceptation de risques Nombre de risques formellement acceptés avec dates de revue ouvertes Tous dans la période de revue ; aucun en retard Registre des risques Fixer des dates de revue lointaines pour éviter la réévaluation
Taux de passage des portes de politique % de releases passant toutes les portes de politique de sécurité au premier essai >80% (en amélioration) Pipeline CI/CD, journaux du moteur de politique Affaiblir les critères des portes pour augmenter le taux de passage
Taux de contournement d’approbation % de releases ayant contourné les approbations de sécurité requises <2% ; tous avec exception documentée Système de gestion des changements, journaux du pipeline Utiliser les procédures d’urgence de manière routinière
Taux de conformité aux SLA % de vulnérabilités remédiées dans le SLA défini >90% Plateforme de gestion des vulnérabilités Ajuster les définitions de SLA ; mettre en pause les compteurs de SLA
Score de complétude des preuves % d’artefacts de preuves d’audit requis qui sont disponibles et à jour >95% Dépôt de preuves, plateforme GRC Générer les preuves rétrospectivement avant l’audit

Métriques de couverture en détail

Les métriques de couverture répondent à la question : l’organisation teste-t-elle ce qu’elle devrait tester ?

La métrique de couverture la plus fondamentale est le pourcentage d’applications bénéficiant de tests de sécurité actifs par rapport à l’inventaire total des applications. Cela devrait être segmenté par niveau d’application, car un taux de couverture global de 90% pourrait masquer le fait que plusieurs applications critiques de Tier 1 ne sont pas testées.

Les auditeurs devraient demander les données de couverture ventilées comme suit :

  • Couverture SAST par niveau d’application
  • Couverture DAST par niveau d’application, avec vérification de la fréquence
  • Couverture SCA par niveau d’application
  • Pourcentage d’applications critiques avec des modèles de menaces à jour
  • Couverture des tests de sécurité par niveau d’application comparée à la fréquence requise définie dans le cadre de classification

Une métrique de couverture n’est significative que si le dénominateur est exact. Si l’inventaire des applications est incomplet, les pourcentages de couverture sont trompeurs. Les auditeurs devraient recouper l’inventaire des applications utilisé pour les calculs de couverture avec d’autres sources (CMDB, plateformes de déploiement, inventaires de comptes cloud) pour vérifier la complétude.

Métriques d’efficience en détail

Les métriques d’efficience répondent à la question : lorsque l’organisation trouve des vulnérabilités, les corrige-t-elle efficacement ?

Le temps moyen de remédiation (MTTR) est la métrique d’efficience la plus importante. Elle devrait être suivie par niveau de sévérité et par niveau d’application, car un MTTR moyen de 30 jours est acceptable pour les constats de haute sévérité mais pas pour les constats critiques dans les applications de Tier 1.

Le MTTR devrait être mesuré de la date d’identification (lorsque le constat a été signalé pour la première fois par un outil de scan ou un testeur) à la date de remédiation vérifiée (lorsqu’un re-scan ou un retest confirme l’efficacité de la correction). Les organisations qui mesurent jusqu’à la date où le développeur ferme le ticket — sans vérification — rapportent une métrique incomplète.

Le taux de réouverture des vulnérabilités indique la qualité des corrections. Un taux supérieur à 5% suggère que les remédiations sont superficielles ou que les causes racines ne sont pas traitées.

Le taux de faux positifs indique l’efficacité de l’outil et la qualité du triage. Un taux de faux positifs anormalement élevé peut indiquer que les constats sont rejetés comme faux positifs plutôt qu’investigués — les auditeurs devraient échantillonner les classifications de faux positifs pour vérifier leur légitimité.

Le temps de cycle scan-à-correction mesure le temps écoulé de bout en bout entre la fin d’un scan et la résolution de tous les constats de ce scan. Cela capture les retards de triage et d’assignation que le MTTR seul peut ne pas révéler.

Métriques de risque en détail

Les métriques de risque répondent à la question : quelle est l’exposition actuelle aux vulnérabilités et est-elle gérée ?

Le nombre de vulnérabilités critiques et de haute sévérité ouvertes est une métrique de risque de base. Elle devrait être suivie comme une tendance dans le temps — un nombre stable ou en baisse indique un programme efficace ; un nombre en hausse indique que les constats sont générés plus vite qu’ils ne sont remédiés.

Le vieillissement des vulnérabilités mesure la durée pendant laquelle les vulnérabilités restent ouvertes. Le 90e percentile est plus utile que la moyenne car les moyennes peuvent être faussées par un grand nombre de constats de faible sévérité rapidement résolus. Si le P90 dépasse le SLA, l’organisation ne respecte pas ses propres engagements de remédiation pour une part significative des constats.

Les nombres d’exceptions et de suppressions révèlent comment l’organisation gère les constats qu’elle choisit de ne pas corriger. Chaque exception devrait avoir une approbation documentée, un contrôle compensatoire et une date de revue. Un nombre croissant d’exceptions sans justification correspondante indique que le processus d’exception est utilisé pour éviter la remédiation plutôt que pour gérer un risque réel.

L’arriéré d’acceptation de risques suit les risques formellement acceptés. Les auditeurs devraient vérifier que chaque risque accepté a un propriétaire, une justification documentée, un contrôle compensatoire et une date de revue — et que les revues en retard sont escaladées.

Métriques de conformité en détail

Les métriques de conformité répondent à la question : l’organisation suit-elle ses propres politiques et respecte-t-elle les exigences réglementaires ?

Le taux de passage des portes de politique mesure la fréquence à laquelle les releases passent les portes de sécurité au premier essai. Un taux très faible peut indiquer que les exigences de sécurité ne sont pas claires ou que les équipes de développement ne reçoivent pas de retour suffisamment tôt. Un taux suspectemment élevé (approchant les 100%) peut indiquer que les portes sont trop permissives.

Le taux de contournement d’approbation est une métrique de contrôle critique. Dans les environnements réglementés, chaque contournement devrait être documenté avec une approbation d’exception. Un taux de contournement supérieur à 2% — ou tout contournement sans approbation documentée — est un constat significatif.

Le taux de conformité aux SLA mesure si les vulnérabilités sont remédiées dans les délais définis dans la politique de gestion des vulnérabilités. Cela devrait être suivi par sévérité et par niveau. Les organisations qui manquent systématiquement les SLA pour les constats critiques dans les applications de Tier 1 présentent une faiblesse matérielle de contrôle.

Le score de complétude des preuves mesure l’état de préparation de l’organisation à l’audit en suivant le pourcentage d’artefacts de preuves requis qui sont disponibles, à jour et correctement stockés. C’est une méta-métrique qui indique la maturité de la gouvernance.

Ce qui rend une métrique fiable pour les auditeurs

Toutes les métriques ne sont pas également fiables. Les auditeurs devraient évaluer la fiabilité des métriques rapportées selon les critères suivants :

  • Générée par le système : La métrique est produite automatiquement par un outil ou une plateforme de sécurité, et non compilée manuellement dans un tableur. La compilation manuelle introduit à la fois des erreurs et des risques de manipulation.
  • Résistante à la falsification : La source de données dispose de contrôles d’accès et de journaux d’audit qui empêchent toute modification non autorisée. Les métriques issues d’un tableau de bord en lecture seule connecté à une source de données contrôlée sont plus fiables que des rapports exportés.
  • Méthodologie cohérente : La métrique est calculée de la même manière à chaque période de reporting. Les changements de méthodologie (par exemple, modifier le calcul du MTTR en cours d’année) doivent être documentés et justifiés.
  • Historiques de tendances disponibles : Au moins 12 mois de données historiques sont disponibles pour identifier les tendances. Un seul point de données est une mesure, pas une métrique — les tendances révèlent si les contrôles s’améliorent, sont stables ou se dégradent.
  • Segmentée par niveau de risque : Les métriques agrégées masquent des variations importantes. Les métriques devraient être disponibles par niveau d’application, par unité métier ou par sévérité pour permettre une analyse significative.
  • Réconciliable : La métrique peut être retracée jusqu’aux données sous-jacentes. Si le MTTR est rapporté à 12 jours, les auditeurs devraient pouvoir consulter les enregistrements individuels de remédiation qui produisent cette moyenne.

Métriques manipulables — et comment les auditeurs peuvent le détecter

Les métriques ne sont utiles que si elles reflètent la réalité. Voici les techniques de manipulation les plus courantes et les procédures d’audit pour les détecter :

Abaissement de la sévérité

Les vulnérabilités sont rétrogradées de critique à élevé, ou d’élevé à moyen, pour éviter de déclencher les exigences de SLA ou les seuils de reporting exécutif.

Détection : Comparer les distributions de sévérité dans le temps. Une diminution soudaine des constats critiques avec une augmentation correspondante des constats élevés est suspecte. Échantillonner les constats rétrogradés et évaluer si le changement de sévérité était justifié et approuvé.

Fermetures en masse avant l’audit

Un grand nombre de vulnérabilités sont fermées juste avant une période d’audit, soit par acceptation massive du risque, soit en marquant les constats comme résolus sans vérification.

Détection : Tracer les dates de fermeture des vulnérabilités sur une chronologie. Le regroupement des fermetures avant les périodes d’audit est un indicateur clair. Demander des preuves de retest pour un échantillon de constats récemment fermés.

Exclusion d’applications du périmètre

Des applications sont retirées de l’inventaire ou exclues du scanning pour améliorer les pourcentages de couverture et réduire le nombre total de vulnérabilités.

Détection : Comparer l’inventaire des applications utilisé pour les métriques avec d’autres sources faisant autorité (inventaires de comptes cloud, enregistrements de plateforme de déploiement, scans réseau). Tout écart nécessite une explication.

Réinitialisation des dates de découverte

Les vulnérabilités sont fermées puis rouvertes (ou de nouveaux tickets sont créés pour le même constat) pour réinitialiser le compteur des métriques de vieillissement.

Détection : Rechercher des constats avec des descriptions identiques et des dates de création différentes. Vérifier si la plateforme de gestion des vulnérabilités suit la date de découverte originale séparément de la date de création du ticket.

Affaiblissement des critères des portes

Les seuils des portes de politique sont assouplis (par exemple, passer le seuil de blocage de « aucun élevé ou critique » à « aucun critique uniquement ») pour améliorer les taux de passage sans améliorer la sécurité réelle.

Détection : Demander l’historique des modifications des configurations des portes de politique. Tout changement de seuil devrait être approuvé par le processus de gouvernance et documenté avec une justification.

Cadence de reporting recommandée

Les différentes parties prenantes ont besoin de différents niveaux de détail à différentes fréquences. La cadence suivante équilibre les besoins opérationnels et les exigences de gouvernance :

Niveau de reporting Fréquence Audience Contenu
Opérationnel Hebdomadaire Équipe AppSec, Security Champions, responsables d’équipes de développement Nouveaux constats, progrès de remédiation, éléments en retard, échecs de scan, actions immédiates
Management Mensuel CISO, responsable AppSec, directeurs du développement, responsable conformité Analyse de tendances, MTTR par sévérité/niveau, évolution de la couverture, conformité aux SLA, synthèse des exceptions, risques émergents
Exécutif / Audit Trimestriel Conseil / Comité des risques, auditeurs externes, régulateurs Synthèse de la posture de risque, évaluation de la maturité du programme, tendances des métriques clés (vue sur 12 mois), constats significatifs, état de conformité réglementaire, adéquation des ressources

Pour les organisations réglementées soumises à DORA, le reporting trimestriel à l’organe de direction sur le risque ICT — y compris la sécurité applicative — est une attente réglementaire, pas une simple recommandation de bonne pratique.

Lectures complémentaires

Pour des conseils connexes sur les contrôles de sécurité applicative et l’évaluation d’audit, voir :

Ressources connexes pour les auditeurs

Nouveau dans l’audit CI/CD ? Commencez par notre Guide de l’auditeur.