KPIs sécurité DevSecOps : mesurer sa posture de sécurité

Q: Qu'est-ce qu'un KPI de sécurité en DevSecOps ?

Un KPI de sécurité est un indicateur chiffré, comme le MTTD, le MTTR ou le Risk Score, qui mesure l'efficacité réelle d'une démarche de sécurité. Il transforme une impression subjective en preuve mesurable et pilotable dans le temps.

Q: Quelle est la différence entre MTTD et MTTR ?

Le MTTD (Mean Time To Detect) mesure le délai entre l'introduction d'une vulnérabilité et sa découverte. Le MTTR (Mean Time To Remediate) mesure le délai entre la détection et la correction vérifiée : deux étapes distinctes du même processus.

Q: Comment calculer le Risk Score en sécurité ?

Le Risk Score se calcule ainsi : (Critical x10 + High x5 + Medium x2 + Low x0.5) divisé par le nombre total d'assets. Un score sous 1.0 est excellent, au-dessus de 5.0 il signale un risque critique nécessitant une remédiation urgente.

Q: Quel est un bon MTTR pour une vulnérabilité critique ?

Le SLA recommandé pour une vulnérabilité critique est un MTTR inférieur à 24 heures, avec escalade immédiate en cas de dépassement, car ce niveau de sévérité présente un risque d'exploitation active élevé.

Q: Combien de KPIs de sécurité faut-il suivre au maximum ?

Il est recommandé de se limiter à 10 à 15 KPIs de sécurité maximum, avec une hiérarchie entre indicateurs quotidiens et mensuels. Trop d'indicateurs noient l'information : mieux vaut commencer par 3 à 4 KPIs essentiels puis élargir.

Ce guide vous apprend à définir, calculer et exploiter les KPIs de sécurité (indicateurs de performance) dans une démarche DevSecOps : MTTD (délai de détection), MTTR (délai de correction), Risk Score et taux de couverture des scans. Il s'adresse aux équipes sécurité, RSSI et ingénieurs DevOps qui disposent déjà d'outils de scan sur leur pipeline CI/CD et veulent transformer ces données brutes en tableaux de bord actionnables. Vous verrez comment fixer des seuils SLA (Service Level Agreement, l'engagement de délai maximal de correction) réalistes, construire des dashboards Grafana par audience et éviter les pièges classiques comme l'effet Cobra (une métrique qu'on optimise au détriment du problème qu'elle est censée résoudre).

Ce que vous allez apprendre

Définir les cinq catégories de KPIs sécurité (détection, remédiation, posture, couverture, efficacité)
Calculer le MTTD, le MTTR et le Risk Score avec des formules et des exemples chiffrés
Fixer des SLA de correction réalistes par niveau de sévérité
Construire des dashboards Grafana adaptés à trois audiences (exécutif, opérationnel, équipe)
Automatiser les alertes Prometheus sur les dépassements de seuils critiques
Éviter les pièges courants : métriques de vanité, effet Cobra, surcharge d'indicateurs

Prérequis

Avant de vous lancer, vérifiez que les briques suivantes sont déjà en place. Ce guide ne couvre pas l'installation d'un scanner de vulnérabilités ni la mise en place d'un pipeline CI/CD : il part du principe que la détection existe et se concentre sur sa mesure et son exploitation via des tableaux de bord.

Outils de scan

Trivy, Grype, Snyk ou équivalent déployé sur vos pipelines CI/CD

Pipeline CI/CD

GitLab CI, GitHub Actions ou Jenkins avec stages de sécurité intégrés

Observabilité

Prometheus/Grafana ou équivalent pour la collecte et visualisation des métriques

Contexte DevSecOps

Lecture recommandée : Introduction au DevSecOps

Pourquoi mesurer la sécurité ?

Avant de plonger dans les métriques, comprenons pourquoi elles sont indispensables au pilotage d'une démarche sécurité.

Lors d'un audit de sécurité dans une scale-up fintech, le directeur technique pose une question simple au RSSI : « Combien de temps nous faut-il pour corriger une vulnérabilité critique ? » Silence gêné, personne ne peut répondre avec certitude. Après la mise en place des KPIs décrits dans ce guide, l'équipe peut enfin affirmer : MTTR Critical inférieur à 18 heures, contre une estimation floue de « quelques jours » auparavant. La direction dispose désormais de données concrètes pour arbitrer ses investissements.

Imaginez piloter un avion sans instruments de bord. Vous savez que vous volez, mais impossible de connaître votre altitude, votre vitesse, ou votre niveau de carburant. C'est exactement la situation de nombreuses équipes sécurité : elles « font de la sécurité », mais ne peuvent pas prouver leur efficacité ni identifier où elles perdent du terrain.

Les KPIs sécurité répondent à quatre questions fondamentales :

Détectons-nous les menaces assez vite ? Si une vulnérabilité critique est publiée lundi et que vous la découvrez vendredi, vous avez laissé une fenêtre d'attaque de quatre jours.
Corrigeons-nous assez rapidement ? Détecter un problème ne suffit pas. Le temps entre la détection et la correction (MTTR) détermine votre exposition réelle.
Notre posture s'améliore-t-elle ? Sans tendance historique, impossible de savoir si vos efforts portent leurs fruits ou si vous courez après les problèmes.
Où investir nos ressources ? Avec des métriques par équipe, par type de vulnérabilité, par application, vous identifiez les zones à risque qui nécessitent attention.

Les 5 catégories de KPIs sécurité

Les indicateurs de sécurité se regroupent en cinq familles complémentaires, chacune répondant à une question métier différente. Structurer vos métriques selon ces catégories évite de mélanger des chiffres qui n'ont pas la même signification, un piège fréquent quand on démarre.

Les 5 catégories de KPIs sécurité DevSecOps

Catégorie	Question clé	Exemples d'indicateurs
Détection	À quelle vitesse trouvons-nous les problèmes ?	MTTD, nouvelles CVE/jour, couverture des scans
Remédiation	À quelle vitesse corrigeons-nous ?	MTTR par sévérité, conformité SLA, dette vulnérabilités
Posture	Quel est notre niveau de risque global ?	Risk Score, vulnerability density, trending mensuel
Couverture	Quelle part de notre SI est protégée ?	% assets scannés, adoption pipelines, shadow IT
Efficacité	Nos outils fonctionnent-ils bien ?	Taux faux positifs, ROI outils, temps analyste

Détaillons maintenant chaque catégorie avec ses indicateurs clés et leur implémentation.

Métriques de détection

La détection mesure votre capacité à identifier les vulnérabilités avant qu'elles ne soient exploitées. Plus vous détectez tôt, plus votre fenêtre d'exposition est réduite.

MTTD, Mean Time To Detect

Le MTTD (Mean Time To Detect, ou temps moyen de détection en français) représente le délai entre l'introduction d'une vulnérabilité et sa découverte par vos outils de scan.

Comprendre cette métrique : Pensez au MTTD comme le temps de réaction d'un détecteur de fumée. Si votre détecteur met deux heures à signaler un début d'incendie, les dégâts seront bien plus importants que s'il réagit en deux minutes. Pour la sécurité, chaque heure de délai est une heure pendant laquelle un attaquant pourrait exploiter la faille.

Le calcul du MTTD s'effectue ainsi :

MTTD = Date de détection - Date d'introduction de la vulnérabilité

En pratique, la date d'introduction correspond soit à la publication de la CVE (Common Vulnerabilities and Exposures, l'identifiant public d'une vulnérabilité connue) pour les vulnérabilités connues, soit à la date du commit introduisant une faille de code.

Cibles recommandées :

Contexte	MTTD cible	Justification
Vulnérabilités critiques (CVE)	< 1 heure	Scans automatiques toutes les heures
Vulnérabilités dans le code (SAST)	< 24 heures	Au plus tard au prochain build
Secrets exposés	< 15 minutes	Pré-commit hooks + monitoring temps réel

Implémentation Prometheus pour le MTTD

Pour collecter automatiquement le MTTD, exposez ces métriques Prometheus depuis vos outils de scan :

# Métrique Prometheus pour le MTTD (format d'exposition, pas du YAML)
# Type: gauge
# Labels: severity, source, team

security_vulnerability_mttd_hours{severity="critical", source="trivy", team="platform"} 0.5
security_vulnerability_mttd_hours{severity="high", source="trivy", team="platform"} 4.2
security_vulnerability_mttd_hours{severity="critical", source="snyk", team="frontend"} 0.8

La requête PromQL (le langage de requête de Prometheus) pour calculer le MTTD moyen par sévérité :

# MTTD moyen sur les 7 derniers jours, par sévérité
avg by (severity) (
  avg_over_time(security_vulnerability_mttd_hours[7d])
)

Métriques de remédiation

La remédiation mesure votre capacité à corriger les vulnérabilités une fois détectées. C'est souvent là que les équipes ont le plus de marge de progression.

MTTR, Mean Time To Remediate

Le MTTR (Mean Time To Remediate, ou temps moyen de remédiation) représente le délai entre la détection d'une vulnérabilité et sa correction vérifiée.

Comprendre cette métrique : Le MTTR est comparable au temps de réponse des services d'urgence. Une fois l'alarme déclenchée (détection), combien de temps faut-il pour que les secours arrivent et maîtrisent la situation (correction) ? Plus ce temps est court, moins les dégâts sont importants.

Flux de remédiation et SLA par sévérité

SLA par niveau de sévérité

Le MTTR n'a de sens que contextualisé par la criticité. Une vulnérabilité critique ne peut pas attendre le même délai qu'un warning mineur. Voici les SLA (Service Level Agreement, engagements de niveau de service) recommandés, à affiner selon le processus de triage détaillé dans notre guide Gestion des vulnérabilités CVE :

Sévérité	SLA MTTR	Justification	Action si dépassement
Critical	< 24 heures	Exploitation active probable	Escalade immédiate, hotfix en production
High	< 7 jours	Risque élevé d'exploitation	Priorité sprint en cours
Medium	< 30 jours	Risque modéré	Planification backlog normal
Low	< 90 jours	Impact limité	Best effort, souvent accepté comme dette

Dette de vulnérabilités

La dette de vulnérabilités représente l'accumulation des failles non corrigées dans les délais SLA. Comme la dette technique, elle génère des « intérêts » : plus elle s'accumule, plus elle devient difficile à résorber.

# Nombre de vulnérabilités hors SLA (dette)
sum by (severity) (
  security_vulnerabilities_total{status="open"}
  and on(severity)
  (time() - security_vulnerability_detected_timestamp) > security_sla_seconds
)

Indicateurs de dette à suivre :

Indicateur	Formule	Cible
Volume dette	Vulnérabilités ouvertes hors SLA	< 5% du total
Âge moyen dette	Moyenne jours de dépassement	< 10 jours
Tendance dette	Variation semaine sur semaine	Décroissante

Métriques de posture de sécurité

Ces indicateurs donnent une vue d'ensemble de votre niveau de risque, au-delà des vulnérabilités individuelles. Depuis la publication de l'OWASP Top 10:2025 (finalisée en janvier 2026), deux nouvelles catégories doivent influencer vos pondérations : les défaillances de la chaîne d'approvisionnement logicielle et la mauvaise gestion des erreurs applicatives. Un Risk Score qui ignore la sécurité de la supply chain logicielle (dépendances, images de base, pipelines) sous-estime une part croissante du risque réel ; retrouvez le détail de ce classement dans notre page OWASP Top 10 appliqué au DevSecOps.

Risk Score, Score de risque global

Le Risk Score agrège plusieurs facteurs en un indicateur unique, facilitant la communication avec la direction et le suivi dans le temps. Il aide aussi à distinguer une menace (un attaquant potentiel), un risque (la probabilité qu'un dommage survienne) et une vulnérabilité (la faille exploitable), trois notions détaillées dans notre page Menace, risque, vulnérabilité, attaque.

Comprendre cette métrique : Le Risk Score fonctionne comme une note de crédit. Il synthétise de nombreux facteurs (vulnérabilités, couverture, conformité) en un score compréhensible par tous. Un score qui baisse indique une amélioration, un score qui monte signale une dégradation à investiguer.

Formule de calcul du Risk Score :

Risk Score = (C × 10) + (H × 5) + (M × 2) + (L × 0.5)
             ────────────────────────────────────────
                        Total Assets

Où :
- C = nombre de vulnérabilités Critical
- H = nombre de vulnérabilités High
- M = nombre de vulnérabilités Medium
- L = nombre de vulnérabilités Low

Cette formule pondère les vulnérabilités par leur criticité. Une vulnérabilité critique compte vingt fois plus qu'une low dans le score final.

Exemple concret :

Organisation avec 100 assets :
- 2 Critical, 15 High, 50 Medium, 100 Low

Risk Score = (2×10 + 15×5 + 50×2 + 100×0.5) / 100
           = (20 + 75 + 100 + 50) / 100
           = 2.45

Interprétation : Score bon mais proche du seuil d'attention (2.5), focus sur les 2 Critical et les 15 High

Échelle de référence :

Score	Niveau	Interprétation
< 1.0	Excellent	Posture de sécurité mature
1.0 - 2.5	Bon	Quelques points d'amélioration
2.5 - 5.0	Attention	Actions correctives nécessaires
> 5.0	Critique	Plan de remédiation urgent requis

Vulnerability Density, Densité de vulnérabilités

La densité de vulnérabilités rapporte le nombre de failles à la taille du code ou au nombre d'assets, permettant des comparaisons équitables entre équipes de tailles différentes.

Vulnerability Density = Vulnérabilités High+ / 1000 lignes de code
                     ou
                      = Vulnérabilités High+ / nombre de conteneurs

Pourquoi cette métrique ? Une équipe avec 5 vulnérabilités sur un projet de 10 000 lignes a un problème bien plus grave qu'une équipe avec 50 vulnérabilités sur 500 000 lignes. La densité normalise la comparaison.

# Densité de vulnérabilités par équipe (pour conteneurs)
sum by (team) (security_vulnerabilities_total{severity=~"critical|high"})
/
count by (team) (container_info)

Métriques de couverture

La couverture mesure quelle proportion de votre système d'information est effectivement analysée par vos outils de sécurité.

Couverture des scans

Une vulnérabilité non détectée dans un asset non scanné est comme un angle mort sur la route : le danger existe même si vous ne le voyez pas.

Type de couverture	Formule	Cible
Assets scannés	Repos avec scan / Total repos	100%
Images scannées	Images avec Trivy / Total images	100%
Pipelines avec sécurité	Pipelines avec stage security / Total pipelines	100%
Dépendances analysées	Deps avec SCA / Total deps	100%

Adoption des pratiques sécurité

Au-delà des outils, mesurez l'adoption des bonnes pratiques par les équipes :

# Taux d'adoption des pre-commit hooks de sécurité
sum(team_precommit_hooks_enabled) / count(team_info) * 100

# Taux de formation sécurité complétée
sum(developer_security_training_completed) / count(developer_info) * 100

Métriques d'efficacité des outils

Ces indicateurs évaluent la performance de vos investissements sécurité.

Taux de faux positifs

Les faux positifs sont des alertes signalant un problème qui n'en est pas un. Un taux élevé de faux positifs érode la confiance des équipes et conduit à ignorer les vraies alertes (l'effet « crier au loup »).

Taux FP = Alertes fermées comme faux positif / Total alertes × 100

Cibles recommandées :

Outil	Taux FP acceptable	Action si dépassement
SAST (analyse code)	< 20%	Affiner les règles, exclure les patterns connus
SCA (dépendances)	< 5%	Revoir la base de CVE, vérifier les versions
DAST (tests dynamiques)	< 15%	Calibrer les scanners, contextualiser
Secrets scanning	< 2%	Améliorer les regex, whitelist tokens test

ROI des outils de sécurité

Pour justifier les investissements, calculez le retour par outil :

ROI Outil (%) = (Vulns détectées × Coût moyen incident évité - Coût outil) / Coût outil × 100

Exemple :
- Trivy détecte 50 vulns Critical/an
- Coût moyen d'un incident Critical évité : 50 000 €
- Coût licence + maintenance Trivy : 10 000 €/an

ROI = (50 × 50 000 - 10 000) / 10 000 × 100 = 24 900%

Architecture des dashboards

Un système de KPIs n'a de valeur que s'il est consulté et exploité. L'architecture des dashboards doit s'adapter aux différentes audiences, un principe qui reprend les bases de l'observabilité appliquées spécifiquement à la sécurité.

Architecture des dashboards sécurité à trois niveaux

Niveau Exécutif (CISO/RSSI)

Les dirigeants ont besoin d'une vue synthétique, orientée décision, avec des indicateurs compréhensibles sans expertise technique.

Métriques à afficher :

Risk Score global et tendance 6 mois
Conformité SLA (% vulnérabilités corrigées dans les délais)
Comparaison objectifs vs réalisé
Top 3 des risques actuels

Fréquence de consultation : Mensuelle, rapport automatisé

Niveau Opérations (SecOps)

L'équipe sécurité opérationnelle a besoin de détails actionnables pour prioriser et suivre les remédiations.

Métriques à afficher :

MTTD et MTTR par équipe, par sévérité
Volume de vulnérabilités ouvertes avec aging
Alertes temps réel sur nouvelles Critical
Top 10 des vulnérabilités à traiter

Fréquence de consultation : Quotidienne

Niveau Équipe (Développeurs)

Les équipes de développement doivent voir leurs propres métriques pour s'auto-améliorer.

Métriques à afficher :

Vulnérabilités de mes repositories
Pipeline security status (pass/fail)
Dette technique sécurité de mon périmètre
Progression vs objectifs d'équipe

Fréquence de consultation : À chaque sprint

Implémentation Grafana

Voici un exemple de configuration Grafana pour le dashboard opérationnel :

Dashboard JSON
Requêtes PromQL

{
  "dashboard": {
    "title": "Security KPIs - Operations",
    "tags": ["security", "kpis", "operations"],
    "timezone": "browser",
    "panels": [
      {
        "title": "Risk Score Trend",
        "type": "timeseries",
        "gridPos": { "h": 8, "w": 12, "x": 0, "y": 0 },
        "targets": [
          {
            "expr": "security_risk_score",
            "legendFormat": "Risk Score"
          }
        ],
        "fieldConfig": {
          "defaults": {
            "color": { "mode": "palette-classic" },
            "custom": {
              "lineWidth": 2,
              "fillOpacity": 10
            },
            "thresholds": {
              "steps": [
                { "color": "green", "value": null },
                { "color": "yellow", "value": 2.5 },
                { "color": "red", "value": 5 }
              ]
            }
          }
        }
      },
      {
        "title": "MTTR by Severity",
        "type": "bargauge",
        "gridPos": { "h": 8, "w": 12, "x": 12, "y": 0 },
        "targets": [
          {
            "expr": "avg by (severity) (security_mttr_hours)",
            "legendFormat": "{{severity}}"
          }
        ],
        "options": {
          "orientation": "horizontal",
          "displayMode": "gradient"
        }
      },
      {
        "title": "SLA Compliance",
        "type": "stat",
        "gridPos": { "h": 4, "w": 6, "x": 0, "y": 8 },
        "targets": [
          {
            "expr": "sum(security_vulnerabilities_within_sla) / sum(security_vulnerabilities_total) * 100",
            "legendFormat": "SLA Compliance %"
          }
        ],
        "options": {
          "colorMode": "value",
          "graphMode": "area"
        },
        "fieldConfig": {
          "defaults": {
            "unit": "percent",
            "thresholds": {
              "steps": [
                { "color": "red", "value": null },
                { "color": "yellow", "value": 80 },
                { "color": "green", "value": 95 }
              ]
            }
          }
        }
      },
      {
        "title": "Vulnerabilities by Severity",
        "type": "piechart",
        "gridPos": { "h": 8, "w": 6, "x": 6, "y": 8 },
        "targets": [
          {
            "expr": "sum by (severity) (security_vulnerabilities_total{status=\"open\"})",
            "legendFormat": "{{severity}}"
          }
        ]
      },
      {
        "title": "Top 10 Vulnerable Repositories",
        "type": "table",
        "gridPos": { "h": 8, "w": 12, "x": 12, "y": 8 },
        "targets": [
          {
            "expr": "topk(10, sum by (repository) (security_vulnerabilities_total{severity=~\"critical|high\"}))",
            "format": "table"
          }
        ]
      }
    ],
    "refresh": "5m"
  }
}

# Risk Score global
(
  sum(security_vulnerabilities_total{severity="critical"}) * 10 +
  sum(security_vulnerabilities_total{severity="high"}) * 5 +
  sum(security_vulnerabilities_total{severity="medium"}) * 2 +
  sum(security_vulnerabilities_total{severity="low"}) * 0.5
) / count(security_assets_total)

# MTTR moyen par sévérité (7 derniers jours)
avg by (severity) (
  rate(security_remediation_duration_seconds_sum[7d])
  /
  rate(security_remediation_duration_seconds_count[7d])
) / 3600

# Conformité SLA
sum(security_vulnerabilities_total{within_sla="true"})
/
sum(security_vulnerabilities_total) * 100

# Tendance nouvelles vulnérabilités (semaine glissante)
increase(security_vulnerabilities_total[7d])

# Couverture de scan
sum(security_scanned_assets) / sum(security_total_assets) * 100

Rapport mensuel CISO

Pour les dirigeants, un rapport mensuel structuré est plus efficace qu'un dashboard temps réel à interpréter seul. Voici un template réutilisable :

# Rapport Sécurité - [MOIS ANNÉE]

## Résumé Exécutif

| Indicateur | Valeur | Tendance | Objectif | Status |
|------------|--------|----------|----------|--------|
| Risk Score | X.XX | ↓ 15% | < 2.0 | ✅/⚠️/❌ |
| Conformité SLA Critical | XX% | ↑ 5% | > 95% | ✅/⚠️/❌ |
| Couverture scan | XX% | → stable | 100% | ✅/⚠️/❌ |
| MTTR Critical (heures) | XX | ↓ 20% | < 24 | ✅/⚠️/❌ |

## Faits marquants

1. [Événement positif : ex. "Correction de la CVE-XXXX en 4 heures"]
2. [Point d'attention : ex. "Augmentation des vulnérabilités Medium"]
3. [Initiative en cours : ex. "Déploiement SAST sur 15 nouveaux repos"]

## Risques majeurs

| Risque | Impact | Probabilité | Mitigation |
|--------|--------|-------------|------------|
| [Description] | Élevé/Moyen/Faible | Élevée/Moyenne/Faible | [Action] |

## Actions du mois suivant

- [ ] [Action prioritaire 1]
- [ ] [Action prioritaire 2]
- [ ] [Action prioritaire 3]

## Annexes

[Détail des vulnérabilités critiques]
[Graphiques de tendance]

Alerting automatisé

Les dashboards sont consultés périodiquement, mais les situations critiques nécessitent des alertes proactives avant que quelqu'un pense à ouvrir Grafana. Ces règles sont chargées par Prometheus lui-même (via rule_files dans prometheus.yml) : c'est Prometheus qui évalue les seuils et déclenche l'alerte, Alertmanager ne fait que router et notifier ensuite (Slack, e-mail, pager) une fois l'alerte déjà déclenchée.

groups:
  - name: security-kpis
    rules:
      # Alerte si nouvelle vulnérabilité critique
      - alert: NewCriticalVulnerability
        expr: increase(security_vulnerabilities_total{severity="critical"}[1h]) > 0
        for: 5m
        labels:
          severity: critical
          team: security
        annotations:
          summary: "Nouvelle vulnérabilité critique détectée"
          description: "{{ $value }} nouvelle(s) vulnérabilité(s) critique(s) détectée(s) dans la dernière heure"
          runbook_url: "https://wiki.internal/security/critical-vuln-response"

      # Alerte si SLA Critical dépassé
      - alert: CriticalSLABreach
        expr: |
          (time() - security_vulnerability_detected_timestamp{severity="critical", status="open"})
          > 86400
        for: 0m
        labels:
          severity: critical
          team: security
        annotations:
          summary: "SLA Critical dépassé"
          description: "Vulnérabilité critique ouverte depuis plus de 24h : {{ $labels.cve_id }}"

      # Alerte si Risk Score dépasse le seuil
      - alert: RiskScoreHigh
        expr: security_risk_score > 5
        for: 1h
        labels:
          severity: warning
          team: security
        annotations:
          summary: "Risk Score élevé"
          description: "Le Risk Score global est de {{ $value }}, au-dessus du seuil de 5"

      # Alerte si couverture de scan insuffisante
      - alert: ScanCoverageLow
        expr: |
          (sum(security_scanned_assets) / sum(security_total_assets) * 100) < 95
        for: 24h
        labels:
          severity: warning
          team: security
        annotations:
          summary: "Couverture de scan insuffisante"
          description: "Seulement {{ $value | printf \"%.1f\" }}% des assets sont scannés"

      # Alerte si taux de faux positifs trop élevé
      - alert: HighFalsePositiveRate
        expr: |
          sum(rate(security_alerts_false_positive_total[7d]))
          /
          sum(rate(security_alerts_total[7d])) * 100 > 20
        for: 1d
        labels:
          severity: warning
          team: security
        annotations:
          summary: "Taux de faux positifs élevé"
          description: "{{ $value | printf \"%.1f\" }}% de faux positifs cette semaine"

Plan d'implémentation

La mise en place d'un système de KPIs sécurité complet se fait progressivement. Vouloir tout instrumenter dès la première semaine est le meilleur moyen d'abandonner le projet au bout d'un mois.

Semaine 1-2 : Instrumentation de base

Configurez l'export des métriques depuis vos outils de scan existants (Trivy, Snyk, etc.) vers Prometheus. Commencez par les métriques simples : nombre de vulnérabilités par sévérité.
Semaine 3-4 : Dashboard opérationnel

Créez un premier dashboard Grafana avec les indicateurs de base : volume de vulnérabilités, répartition par sévérité, top des repositories impactés.
Mois 2 : Métriques temporelles

Ajoutez le suivi du MTTD et MTTR. Cela nécessite de capturer les timestamps de détection et de correction, souvent via des labels GitLab/GitHub.
Mois 3 : SLA et alerting

Définissez vos SLA par sévérité et configurez les alertes. Communiquez les engagements aux équipes.
Mois 4+ : Raffinement et expansion

Ajoutez les dashboards par audience (exécutif, équipes), les métriques de couverture, et le rapport mensuel automatisé.

Pièges à éviter

L'implémentation de KPIs sécurité peut dérailler de plusieurs façons, souvent sans que l'équipe s'en rende compte avant plusieurs mois.

1. La course aux chiffres

Mesurer pour mesurer, sans action. Si un KPI ne déclenche jamais de décision, il est inutile. Chaque indicateur doit répondre à la question : « Que ferons-nous si ce chiffre dépasse tel seuil ? »

2. Les métriques de vanité

Afficher « 0 vulnérabilité critique » est gratifiant, mais si c'est parce que vous ne scannez que 10% de vos assets, c'est trompeur. Toujours contextualiser avec la couverture.

3. L'effet Cobra

Nommé d'après une anecdote coloniale où une prime aux cobras tués a conduit les gens à élever des cobras, cet effet Cobra se produit quand les équipes optimisent les métriques plutôt que la sécurité réelle. Exemple : fermer des vulnérabilités comme « accepted risk » pour améliorer le MTTR sans vraiment les corriger.

4. Surcharge d'indicateurs

Trop de KPIs noient l'information. Limitez-vous à 10 à 15 indicateurs maximum, avec une hiérarchie claire entre ceux consultés quotidiennement et ceux revus mensuellement. Pour situer ce chantier dans une trajectoire plus large, notre page Évaluer sa maturité DevSecOps propose une grille complète.

FAQ : questions fréquentes

Qu'est-ce qu'un KPI de sécurité en DevSecOps ?

Un KPI de sécurité est un indicateur chiffré, comme le MTTD, le MTTR ou le Risk Score, qui mesure l'efficacité réelle d'une démarche de sécurité. Il transforme une impression subjective en preuve mesurable et pilotable dans le temps.

Quelle est la différence entre MTTD et MTTR ?

Le MTTD (Mean Time To Detect) mesure le délai entre l'introduction d'une vulnérabilité et sa découverte. Le MTTR (Mean Time To Remediate) mesure le délai entre la détection et la correction vérifiée : deux étapes distinctes du même processus.

Comment calculer le Risk Score en sécurité ?

Le Risk Score se calcule ainsi : (Critical x10 + High x5 + Medium x2 + Low x0.5) divisé par le nombre total d'assets. Un score sous 1.0 est excellent, au-dessus de 5.0 il signale un risque critique nécessitant une remédiation urgente.

Quel est un bon MTTR pour une vulnérabilité critique ?

Le SLA recommandé pour une vulnérabilité critique est un MTTR inférieur à 24 heures, avec escalade immédiate en cas de dépassement, car ce niveau de sévérité présente un risque d'exploitation active élevé.

Pourquoi suivre le taux de faux positifs des outils de sécurité ?

Un taux élevé de faux positifs érode la confiance des équipes et conduit à ignorer les vraies alertes. Cibles recommandées : moins de 20% en SAST, moins de 5% en SCA sur les dépendances, moins de 2% pour le scan de secrets.

Combien de KPIs de sécurité faut-il suivre au maximum ?

Il est recommandé de se limiter à 10 à 15 KPIs de sécurité maximum, avec une hiérarchie entre indicateurs quotidiens et mensuels. Trop d'indicateurs noient l'information : mieux vaut commencer par 3 à 4 KPIs essentiels puis élargir.

Pour aller plus loin

Les KPIs sécurité prennent tout leur sens une fois articulés avec les autres piliers d'une démarche DevSecOps. Les ressources suivantes permettent d'aller plus loin, que ce soit sur la mesure de la performance globale, la sécurisation des pipelines ou la gestion opérationnelle des vulnérabilités.

Métriques DORA Implémenter les métriques DORA pour mesurer votre performance globale DevOps

Pipelines sécurisés Pipeline CI/CD sécurisé intégrant ces métriques

Formation équipes Security Champions pour améliorer les KPIs humains

Analyse de code Analyse de code et vulnérabilités pour optimiser le MTTR

Gestion des CVE Gestion des vulnérabilités CVE : du triage au patch

Maturité DevSecOps Évaluer sa maturité DevSecOps pour situer votre trajectoire

Ressources complémentaires

Ces ressources font autorité sur le sujet et permettent d'approfondir la théorie derrière les indicateurs présentés dans ce guide. Elles sont utiles pour justifier vos choix de seuils auprès d'un auditeur ou d'un comité de risque.

Ressource	Description	Lien
OWASP Top 10:2025	Classement des risques applicatifs, avec deux nouvelles catégories liées à la supply chain logicielle	owasp.org
NIST Cybersecurity Framework 2.0	Référentiel de maturité en six fonctions, dont la fonction Govern (pilotage)	nist.gov
IBM Cost of a Data Breach 2025	Étude annuelle sur le coût moyen d'une violation de données, utile pour vos calculs de ROI	ibm.com
Grafana Security Dashboards	Templates de dashboards sécurité	grafana.com
Prometheus Best Practices	Bonnes pratiques d'instrumentation	prometheus.io

À retenir

La mise en place de KPIs sécurité transforme la sécurité d'une discipline réactive et opaque en une fonction mesurable et pilotable. Les points essentiels à retenir :

MTTD et MTTR sont vos indicateurs de réactivité : visez moins d'une heure pour la détection des critiques, moins de 24 heures pour leur correction
Le Risk Score synthétise votre posture pour la communication dirigeante, un score inférieur à 2.0 indique une maturité satisfaisante
Depuis l'OWASP Top 10:2025, intégrez la supply chain logicielle dans vos pondérations de risque, ce n'est plus une catégorie annexe
La couverture de scan à 100% est non négociable : un asset non scanné est une faille invisible
Les SLA par sévérité créent de la prévisibilité et permettent de prioriser objectivement
Trois niveaux de dashboards (exécutif, opérationnel, équipe) servent des audiences aux besoins différents
L'alerting automatisé complète les dashboards pour les situations critiques
Commencez par 3 à 4 KPIs essentiels avant d'élargir : mieux vaut peu d'indicateurs exploités que beaucoup ignorés