Métriques DevSecOps : KPI pour la maturité sécurité

Votre RSSI vous demande un rapport sur l'état de la sécurité applicative. Vous n'avez que deux chiffres : le nombre de vulnérabilités ouvertes (827) et le nombre d'incidents de sécurité cette année (2). Ces chiffres ne racontent rien. 827 vulnérabilités, c'est beaucoup ou peu ? Par rapport à quoi ? Est-ce en hausse ou en baisse ? Quelles équipes progressent et lesquelles stagnent ? Sans métriques structurées, votre programme DevSecOps fonctionne à l'aveugle. Vous investissez dans des outils, des formations, des processus — mais vous ne savez pas si cet investissement produit des résultats. Les métriques DevSecOps transforment cette intuition en données. Le MTTR (Mean Time To Remediate) mesure la réactivité de vos équipes. Le taux de détection pre-prod évalue l'efficacité de votre shift-left. La densité de vulnérabilités par ligne de code ou par composant identifie les points chauds. Ce guide vous fournit le framework complet pour bâtir un tableau de bord DevSecOps actionnable, avec les formules de calcul, les cibles réalistes et les pièges à éviter.

Les 5 KPI essentiels du DevSecOps

Trop de métriques tue la métrique. Commencez par ces cinq indicateurs qui couvrent les trois dimensions de la sécurité applicative (prévention, détection, réponse) :

MTTR : la métrique reine de la réactivité

Le Mean Time To Remediate mesure le temps moyen entre la détection d'une vulnérabilité et sa correction en production. C'est le KPI le plus révélateur de la maturité DevSecOps. Calculez-le par sévérité :

MTTR_critical = somme(date_fix - date_detection) / nombre_vulns_critiques

Les benchmarks sectoriels (données Veracode State of Software Security 2024) :

Si votre MTTR critique est supérieur à 30 jours, concentrez-vous sur ce KPI avant tous les autres. Les leviers : automatisation du triage (cf. notre guide sur la gestion des vulnérabilités), SLA clairs par sévérité, et responsabilisation des équipes de développement.

Taux de détection pre-production

Ce KPI mesure le pourcentage de vulnérabilités trouvées avant le déploiement en production par rapport au total des vulnérabilités (pre-prod + production). C'est l'indicateur direct de l'efficacité de votre shift-left.

taux_preprod = vulns_trouvées_en_CI / (vulns_trouvées_en_CI + vulns_trouvées_en_prod) * 100

Un taux de 30% est typique d'une organisation qui démarre le DevSecOps. La cible à 12 mois : 80%. Le moyen d'y arriver : scanner plus tôt (SAST en pre-commit), scanner plus large (SCA sur toutes les dépendances), et scanner plus souvent (DAST hebdomadaire sur staging). Notre article sur le shift-left et la culture sécurité détaille les leviers humains et organisationnels pour atteindre cet objectif.

Densité de vulnérabilités et couverture de scan

La densité de vulnérabilités (nombre de vulns par millier de lignes de code, ou vulns/KLOC) permet de comparer la qualité sécurité entre les composants et entre les équipes. C'est une métrique normalisée qui ne pénalise pas les grands projets.

La couverture de scan mesure le pourcentage de vos applications et dépôts qui sont couverts par au moins un scanner de sécurité dans le pipeline CI. Un scan qui ne couvre que 40% de vos applications laisse 60% dans l'ombre. Cible : 95% en 6 mois.

Deux autres métriques complètent ce tableau :

• Taux de faux positifs — % des findings fermés comme "faux positif" ou "non applicable". Au-dessus de 30%, vos outils sont mal configurés. Cible : moins de 15%. Consultez notre comparatif des outils de test pour optimiser la configuration.
• Taux de réouverture — % des vulnérabilités corrigées puis réintroduites. Au-dessus de 10%, le problème est systémique (absence de tests de régression sécurité).

Modèle de maturité DevSecOps en 5 niveaux

Les métriques prennent leur sens dans un modèle de maturité qui définit les jalons de progression :

Chaque niveau prend 6-12 mois à atteindre. Visez une progression d'un niveau par an. Le passage du niveau 2 au niveau 3 est le plus difficile car il nécessite le changement culturel décrit dans notre article sur le shift-left security. Pour la conformité réglementaire associée, consultez notre guide NIS2 et ISO 27017.

Construire le tableau de bord

L'outil n'a pas d'importance — Grafana, Datadog, un Google Sheet, peu importe. Ce qui compte : la fréquence de mise à jour (hebdomadaire minimum), l'audience (partagé avec les tech leads et le management), et l'actionnabilité (chaque KPI dégradé déclenche une action identifiée).

Les sources de données typiques :

• DefectDojo / Dependency-Track — MTTR, densité, volume par sévérité
• Pipeline CI — Couverture de scan, taux d'échec des gates sécurité
• Git — Taux d'adoption des pre-commit hooks, nombre de secrets détectés
• LMS / plateforme de formation — Taux de complétion des formations sécurité

Automatisez l'extraction avec des scripts qui interrogent les APIs. Le rapport Veracode State of Software Security et le NIST Cybersecurity Framework fournissent les benchmarks pour contextualiser vos chiffres.