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

Les KPIs de sécurité (indicateurs clés de performance) transforment les rapports de vos scanners en réponses chiffrées : combien de temps pour détecter une faille (MTTD), pour la corriger (MTTR), quel risque global, quelle part du parc est réellement scannée. Cette leçon s'adresse au DevOps ou au RSSI qui a déjà des scans dans son pipeline CI/CD et veut en faire un tableau de bord qui déclenche des décisions.

Les formules sont données en PromQL et vérifiées avec promtool, l'outil de test de Prometheus 3.15.0 : sur un jeu de séries de test, le Risk Score de l'exemple vaut bien 2,45, et la version naïve de la même requête disparaît dès qu'aucune vulnérabilité critique n'est ouverte, c'est-à-dire précisément quand tout va bien.

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
• Tester des règles d'alerte Prometheus avant de les déployer
• Éviter les pièges courants : métriques de vanité, effet Cobra, surcharge d'indicateurs

Prérequis

Avant de commencer, vérifiez que les briques suivantes sont déjà en place. Cette leçon ne couvre ni l'installation d'un scanner de vulnérabilités ni la mise en place d'un pipeline CI/CD : elle part du principe que la détection existe et se concentre sur sa mesure.

• Outils de scan : Trivy, Grype ou équivalent, branchés sur les pipelines
• Pipeline CI/CD : GitLab CI, GitHub Actions ou Jenkins, avec des étapes de sécurité
• Observabilité : Prometheus et Grafana, ou équivalent, pour collecter et afficher
• Processus de triage : la leçon Gestion des vulnérabilités fixe les délais repris ici

Pourquoi mesurer la sécurité ?

Une équipe qui « fait de la sécurité » sans la mesurer ne peut ni prouver son efficacité, ni repérer où elle perd du terrain. Imaginez la question d'un directeur technique : « combien de temps nous faut-il pour corriger une vulnérabilité critique ? ». Sans indicateur, la seule réponse honnête est une estimation floue ; avec un MTTR suivi par criticité, c'est un chiffre, et une tendance.

Les KPIs sécurité répondent à quatre questions. Détectons-nous assez vite ? Une faille publiée lundi et découverte vendredi laisse une fenêtre d'attaque de quatre jours. Corrigeons-nous assez vite ? Le délai entre détection et correction détermine l'exposition réelle. La posture s'améliore-t-elle ? Sans tendance historique, impossible de le savoir. Où investir ? Des métriques par équipe et par application désignent les zones à risque.

Le piège du « tout va bien »

Sans métriques, l'absence d'incident visible passe pour une preuve de sécurité. En réalité, on ne sait pas si l'on est protégé ou si l'on ignore ses failles. Les KPIs ne garantissent rien, mais ils remplacent une impression par une mesure que l'on peut discuter.

Les 5 catégories de KPIs sécurité

Les indicateurs se regroupent en cinq familles, chacune répondant à une question différente. Les séparer évite de comparer des chiffres qui n'ont pas le même sens, un piège fréquent au démarrage. Le schéma résume la famille et son indicateur phare ; le tableau donne la question et des exemples.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Catégorie	Question clé	Exemples d'indicateurs
Détection	À quelle vitesse trouvons-nous les problèmes ?	MTTD, nouvelles CVE par jour
Remédiation	À quelle vitesse corrigeons-nous ?	MTTR par sévérité, conformité SLA, dette de vulnérabilités
Posture	Quel est notre niveau de risque global ?	Risk Score, densité de vulnérabilités, tendance mensuelle
Couverture	Quelle part du SI est analysée ?	% d'actifs scannés, adoption dans les pipelines
Efficacité	Nos outils fonctionnent-ils bien ?	Taux de faux positifs, coût par vulnérabilité traitée

Glissez pour voir

Métriques de détection

La détection mesure la capacité à identifier les vulnérabilités avant qu'elles ne soient exploitées. Plus elle est rapide, plus la fenêtre d'exposition est courte : c'est le premier chiffre qu'un attaquant met à profit.

MTTD, Mean Time To Detect

Le MTTD (Mean Time To Detect, temps moyen de détection) mesure le délai entre l'apparition d'une vulnérabilité et sa découverte par vos outils. Pour une faille connue, le point de départ est la publication de la CVE ; pour une faille de code, la date du commit qui l'introduit.

MTTD = date de détection - date d'apparition de la vulnérabilité

Les cibles suivantes sont des repères courants, pas une norme. Elles supposent un scan programmé fréquent et des contrôles en amont du commit.

Contexte	MTTD cible	Justification
Vulnérabilités critiques (CVE)	< 1 heure	Scans programmés toutes les heures sur le registre
Vulnérabilités dans le code (SAST)	< 24 heures	Au plus tard au prochain build
Secrets exposés	< 15 minutes	Hooks pre-commit et surveillance continue

Glissez pour voir

Le MTTD ne compte pas les inconnues

Le MTTD ne mesure que ce que vous finissez par détecter. Les failles jamais découvertes, comme une 0-day, n'y entrent pas : un MTTD excellent sur 10 % du parc ne vaut rien. Il se lit toujours avec la couverture de scan.

Implémentation Prometheus pour le MTTD

Pour collecter le MTTD automatiquement, un petit exporter (programme qui expose des métriques sur HTTP) traduit les résultats de vos scanners au format d'exposition de Prometheus. Le nommage suit les conventions du projet : le suffixe _total est réservé aux compteurs, l'unité figure dans le nom.

# Format d'exposition Prometheus (pas du YAML)
# TYPE security_vulnerability_mttd_hours gauge
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="grype", team="frontend"} 0.8

La requête PromQL (le langage de requête de Prometheus) qui donne le MTTD moyen par sévérité sur sept jours est la suivante :

avg by (severity) (avg_over_time(security_vulnerability_mttd_hours[7d]))

Métriques de remédiation

La remédiation mesure la capacité à corriger une fois la faille détectée. C'est souvent là que les équipes ont la plus grande marge de progression, et là que les SLA prennent leur sens.

MTTR, Mean Time To Remediate

Le MTTR (Mean Time To Remediate, temps moyen de remédiation) mesure le délai entre la détection et la correction vérifiée, c'est-à-dire le scan qui confirme la disparition. Le schéma suit une vulnérabilité de la détection à la clôture, avec le délai cible de chaque criticité.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Si l'exporter publie la durée de chaque correction comme un summary Prometheus (_sum et _count), le MTTR en heures se calcule par criticité :

sum by (severity) (rate(security_remediation_duration_seconds_sum[7d]))
/
sum by (severity) (rate(security_remediation_duration_seconds_count[7d]))
/ 3600

SLA par niveau de sévérité

Le MTTR n'a de sens que rapporté à la criticité : une faille critique n'attend pas le même délai qu'une faille mineure. Les SLA (Service Level Agreement, engagement de délai maximal) ci-dessous sont les mêmes que dans la leçon Gestion des vulnérabilités, où la priorité vient du triage par exposition, KEV, EPSS et CVSS.

Sévérité	SLA MTTR	Justification	Action si dépassement
Critical	< 24 heures	Exploitation probable ou confirmée	Escalade immédiate, correctif en production
High	< 7 jours	Risque élevé d'exploitation	Priorité dans le sprint en cours
Medium	< 30 jours	Risque modéré	Planification normale du backlog
Low	< 90 jours	Impact limité	Au mieux, souvent acceptée comme dette

Glissez pour voir

Un SLA n'est pas une moyenne

Le SLA fixe un maximum, pas une moyenne. Un MTTR moyen de 12 heures peut cacher des cas à 48 heures qui dépassent le délai. Suivez toujours le pourcentage de conformité au SLA en plus du MTTR.

Dette de vulnérabilités

La dette de vulnérabilités compte les failles encore ouvertes au-delà de leur SLA. Comme la dette technique, elle produit des « intérêts » : plus elle vieillit, plus elle coûte à résorber. Avec un gauge qui expose l'âge de chaque vulnérabilité ouverte et un autre qui expose le SLA par sévérité, la requête compare les deux séries sur le label severity :

count by (severity) (
  security_vulnerability_open_age_seconds
    > on (severity) group_left ()
  security_sla_seconds
)

Testé avec promtool sur trois vulnérabilités, deux critiques ouvertes depuis 48 heures et 1 heure, une haute depuis 24 heures : la requête rend 1 pour critical et rien pour high, dont le SLA est de sept jours.

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

Glissez pour voir

Métriques de posture de sécurité

Ces indicateurs donnent une vue du risque au-delà des failles une à une. L'OWASP Top 10:2025, publié dans sa version finale en janvier 2026, compte deux catégories inédites : A03 Software Supply Chain Failures et A10 Mishandling of Exceptional Conditions. Un indicateur qui ignore la chaîne d'approvisionnement (dépendances, images de base, pipelines) sous-estime donc une part du risque réel ; le détail du classement est dans la leçon OWASP Top 10.

Risk Score, Score de risque global

Le Risk Score agrège les vulnérabilités ouvertes, pondérées par criticité, en un seul chiffre rapporté à la taille du parc. Il sert à communiquer avec la direction et à suivre une tendance : un score qui baisse signale une amélioration, un score qui monte une dégradation à expliquer.

Risk Score = (C × 10) + (H × 5) + (M × 2) + (L × 0,5)
             ──────────────────────────────────────────
                       nombre d'actifs

C, H, M, L = vulnérabilités ouvertes Critical, High, Medium, Low

La pondération fait peser une critique vingt fois plus qu'une faible. Avec 100 actifs portant 2 Critical, 15 High, 50 Medium et 100 Low :

Risk Score = (2×10 + 15×5 + 50×2 + 100×0,5) / 100
           = (20 + 75 + 100 + 50) / 100
           = 2,45

Le score tombe dans la zone Bon, juste sous le seuil d'attention de 2,5 : l'effort porte sur les 2 Critical et les 15 High. L'échelle ci-dessous est une convention interne à fixer en équipe, pas un standard.

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

Glissez pour voir

Calculer le Risk Score en PromQL, sans trou

La traduction directe en PromQL cache un piège mesuré. Une somme sur une sévérité qui n'a aucune série (zéro critique ouverte, donc aucune ligne exposée) ne rend pas 0 : elle ne rend rien, et toute l'addition disparaît. Testé avec promtool, la version naïve rend nil sur un parc sans vulnérabilité critique, là où la version corrigée rend 1,25. Le tableau de bord se vide exactement quand la posture est bonne.

security-kpis.rules.yml (extrait)

groups:
  - name: security-kpis-records
    rules:
      - record: security:risk_score
        expr: |
          (
              (sum(security_vulnerabilities_open{severity="critical"}) or vector(0)) * 10
            + (sum(security_vulnerabilities_open{severity="high"}) or vector(0)) * 5
            + (sum(security_vulnerabilities_open{severity="medium"}) or vector(0)) * 2
            + (sum(security_vulnerabilities_open{severity="low"}) or vector(0)) * 0.5
          ) / sum(security_assets_total)

Le motif or vector(0) remplace l'absence de série par un zéro. Sur le jeu de test qui reprend l'exemple (2, 15, 50 et 100 vulnérabilités, 100 actifs), promtool test rules confirme la valeur 2,45.

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'actifs, pour comparer équitablement des équipes de tailles différentes. Cinq failles graves sur 10 000 lignes sont plus inquiétantes que cinquante sur 500 000.

Densité = vulnérabilités High et Critical / 1 000 lignes de code
        ou
        = vulnérabilités High et Critical / nombre de conteneurs

sum by (team) (security_vulnerabilities_open{severity=~"critical|high"})
/
count by (team) (container_info)

Métriques de couverture

La couverture mesure la part du système d'information réellement analysée par vos outils. Une vulnérabilité dans un actif non scanné est un angle mort : le danger existe, mais aucun indicateur ne le montre.

Couverture des scans

Chaque type d'actif a son ratio. La cible est de 100 %, parce qu'un seul actif oublié peut être celui que l'attaquant utilise ; le shadow IT (les systèmes que personne n'a référencés) est l'ennemi principal de cet indicateur.

Type de couverture	Formule	Cible
Dépôts scannés	Dépôts avec scan / total des dépôts	100 %
Images scannées	Images scannées / total des images du registre	100 %
Pipelines avec sécurité	Pipelines avec étape de sécurité / total	100 %
Dépendances analysées	Dépendances couvertes par la SCA / total	100 %

Glissez pour voir

sum(security_assets_scanned) / sum(security_assets_total) * 100

Adoption des pratiques sécurité

Au-delà des outils, mesurez l'adoption des bonnes pratiques par les équipes : part des dépôts équipés de hooks pre-commit de détection de secrets, part des développeurs formés. Ces taux se calculent comme la couverture, à partir de métriques exposées par votre outillage interne.

sum(team_precommit_hooks_enabled) / count(team_info) * 100
sum(developer_security_training_completed) / count(developer_info) * 100

Métriques d'efficacité des outils

Ces indicateurs évaluent ce que rapportent vos investissements sécurité : un outil qui noie l'équipe sous les alertes coûte plus qu'il ne protège.

Taux de faux positifs

Un faux positif est une alerte sur un problème qui n'en est pas un. Un taux élevé érode la confiance des équipes, qui finissent par ignorer les vraies alertes : c'est l'effet « crier au loup ».

Taux FP = alertes fermées comme faux positif / total des alertes × 100

Les seuils suivants sont des repères de départ : ils dépendent de la technologie analysée et de la maturité des règles.

Outil	Taux FP acceptable	Action si dépassement
SAST (analyse de code)	< 20 %	Affiner les règles, exclure les motifs connus
SCA (dépendances)	< 5 %	Vérifier les versions détectées, écrire des VEX
DAST (tests dynamiques)	< 15 %	Calibrer les scans, contextualiser
Détection de secrets	< 2 %	Affiner les règles, lister les jetons de test

Glissez pour voir

Retour sur investissement des outils

Le ROI (retour sur investissement) d'un outil se calcule à partir du coût des incidents évités, une valeur toujours estimée. Toute formule repose donc sur une hypothèse, à écrire noir sur blanc : une vulnérabilité détectée n'est pas un incident évité.

ROI (%) = (incidents évités estimés × coût moyen d'un incident - coût total de l'outil)
          / coût total de l'outil × 100

Le coût total d'un outil open source comme Trivy n'est pas nul : c'est le temps d'intégration, de maintenance et de triage de ses alertes. Pour le coût d'un incident, le rapport IBM Cost of a Data Breach 2026 chiffre la moyenne mondiale d'une violation de données à 4,99 millions de dollars, en hausse de 12 % sur un an ; votre propre estimation (temps de réponse, perte de revenu, sanctions RGPD) reste plus parlante pour la direction.

Architecture des dashboards

Un système de KPIs ne vaut que s'il est consulté. Les tableaux de bord se découpent par audience, chacune avec son rythme : les données remontent de l'équipe vers la direction, les décisions et les alertes redescendent. Le principe reprend celui de l'observabilité, appliqué à la sécurité.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Niveau Exécutif (CISO/RSSI)

La direction a besoin d'une vue synthétique, orientée décision, lisible sans expertise technique, et consultée chaque mois sous forme de rapport automatisé. On y affiche le Risk Score et sa tendance sur six mois, la conformité SLA, l'écart entre objectifs et réalisé, et les trois risques principaux du moment.

Niveau Opérations (SecOps)

L'équipe sécurité opérationnelle a besoin de détails actionnables, chaque jour : MTTD et MTTR par équipe et par sévérité, volume de vulnérabilités ouvertes avec leur ancienneté, alertes en temps réel sur les nouvelles critiques, et la liste des dix vulnérabilités à traiter en premier.

Niveau Équipe (Développeurs)

Les équipes de développement doivent voir leurs propres métriques, revues à chaque sprint : vulnérabilités de leurs dépôts, état des contrôles de sécurité de leurs pipelines, dette de leur périmètre et progression par rapport à leurs objectifs.

Implémentation Grafana

Voici un exemple de configuration Grafana pour le tableau de bord opérationnel, au format d'import JSON, avec les requêtes PromQL utilisées. Les noms de métriques sont ceux des sections précédentes ; adaptez-les à ce qu'expose votre exporter.

Dashboard JSON

{
  "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": {
            "thresholds": {
              "steps": [
                { "color": "green", "value": null },
                { "color": "yellow", "value": 2.5 },
                { "color": "red", "value": 5 }
              ]
            }
          }
        }
      },
      {
        "title": "MTTR by Severity (hours)",
        "type": "bargauge",
        "gridPos": { "h": 8, "w": 12, "x": 12, "y": 0 },
        "targets": [
          { "expr": "security:mttr_hours:7d", "legendFormat": "{{severity}}" }
        ],
        "options": { "orientation": "horizontal", "displayMode": "gradient" }
      },
      {
        "title": "Open vulnerabilities over SLA",
        "type": "stat",
        "gridPos": { "h": 4, "w": 6, "x": 0, "y": 8 },
        "targets": [
          { "expr": "sum(security:vulnerabilities_over_sla:count) or vector(0)", "legendFormat": "over SLA" }
        ]
      },
      {
        "title": "Open vulnerabilities by Severity",
        "type": "piechart",
        "gridPos": { "h": 8, "w": 6, "x": 6, "y": 8 },
        "targets": [
          { "expr": "sum by (severity) (security_vulnerabilities_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_open{severity=~\"critical|high\"}))", "format": "table" }
        ]
      }
    ],
    "refresh": "5m"
  }
}

Requêtes PromQL

# Risk Score global (règle d'enregistrement de la section posture)
security:risk_score

# MTTR moyen par sévérité, en heures, sur 7 jours
sum by (severity) (rate(security_remediation_duration_seconds_sum[7d]))
/
sum by (severity) (rate(security_remediation_duration_seconds_count[7d]))
/ 3600

# Conformité SLA : part des corrections faites dans les délais, sur 30 jours
sum(increase(security_remediations_total{within_sla="true"}[30d]))
/
sum(increase(security_remediations_total[30d])) * 100

# Nouvelles vulnérabilités détectées sur une semaine glissante
sum(increase(security_vulnerabilities_detected_total[7d]))

# Couverture de scan
sum(security_assets_scanned) / sum(security_assets_total) * 100

Rapport mensuel CISO

Pour la direction, un rapport mensuel structuré vaut mieux qu'un tableau de bord temps réel à interpréter seul. Le gabarit ci-dessous reprend les indicateurs de l'audience exécutive ; les colonnes tendance et objectif comptent plus que la valeur brute.

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

## Résumé exécutif

| Indicateur | Valeur | Tendance | Objectif | Statut |
|------------|--------|----------|----------|--------|
| Risk Score | X,XX | en baisse de 15 % | < 2,0 | OK / attention / hors cible |
| Conformité SLA Critical | XX % | en hausse de 5 % | > 95 % | OK / attention / hors cible |
| Couverture de scan | XX % | stable | 100 % | OK / attention / hors cible |
| MTTR Critical (heures) | XX | en baisse de 20 % | < 24 | OK / attention / hors cible |

## Faits marquants

1. [Événement positif : ex. « Correction de la CVE-XXXX en 4 heures »]
2. [Point d'attention : ex. « Hausse des vulnérabilités Medium »]
3. [Initiative en cours : ex. « SAST déployé sur 15 nouveaux dépôts »]

## 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]

Alerting automatisé

Les tableaux de bord se consultent de temps en temps ; les situations critiques demandent des alertes qui partent seules. Ces règles sont chargées par Prometheus lui-même, via rule_files dans prometheus.yml : c'est Prometheus qui évalue les seuils, Alertmanager ne fait que router et notifier ensuite (messagerie, e-mail, astreinte).

security-kpis.rules.yml (suite)

  - name: security-kpis-alerts
    rules:
      - alert: NewCriticalVulnerability
        expr: increase(security_vulnerabilities_detected_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) en une heure"
      - alert: CriticalSLABreach
        expr: security_vulnerability_open_age_seconds{severity="critical"} > 86400
        labels:
          severity: critical
          team: security
        annotations:
          summary: "SLA Critical dépassé"
          description: "Vulnérabilité critique ouverte depuis plus de 24 h : {{ $labels.cve_id }}"
      - 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"
      - alert: ScanCoverageLow
        expr: security:scan_coverage:percent < 95
        for: 24h
        labels:
          severity: warning
          team: security
        annotations:
          summary: "Couverture de scan insuffisante"
          description: "Seulement {{ $value | printf \"%.1f\" }} % des actifs sont scannés"

Une règle d'alerte se teste avant d'être déployée. promtool check rules vérifie la syntaxe, et promtool test rules rejoue des séries de test pour vérifier qu'une alerte part, ou ne part pas. Mesuré avec Prometheus 3.15.0 : le fichier complet (quatre règles d'enregistrement, quatre alertes) passe les deux, et CriticalSLABreach se déclenche bien pour la seule vulnérabilité critique ouverte depuis 48 heures.

promtool check rules security-kpis.rules.yml
#   SUCCESS: 8 rules found
promtool test rules security-kpis.test.yml
#   SUCCESS

Plan d'implémentation

Un système de KPIs se met en place progressivement. Vouloir tout instrumenter la première semaine est le meilleur moyen d'abandonner au bout d'un mois ; les étapes ci-dessous ajoutent un niveau de mesure à la fois.

1. Semaines 1-2 : instrumentation de base

   Exportez vers Prometheus le nombre de vulnérabilités ouvertes par sévérité, depuis les scanners existants. C'est la matière première de tout le reste.

2. Semaines 3-4 : tableau de bord opérationnel

   Un premier tableau Grafana : volume par sévérité, répartition, dépôts les plus touchés.

3. Mois 2 : métriques temporelles

   Ajoutez MTTD et MTTR, ce qui suppose d'horodater détection et correction, souvent via les tickets ou les labels GitLab et GitHub.

4. Mois 3 : SLA et alerting

   Fixez les SLA par sévérité, écrivez les alertes et leurs tests, et communiquez les engagements aux équipes.

5. Mois 4 et suivants : extension

   Tableaux par audience, couverture, rapport mensuel automatisé.

Commencez petit

Ne lancez pas tous les KPIs à la fois. Commencez par trois ou quatre indicateurs critiques pour votre contexte, vérifiez qu'ils sont lus et qu'ils déclenchent des décisions, puis élargissez.

Pièges à éviter

Un système de KPIs peut dérailler sans que personne ne s'en aperçoive pendant des mois. Les quatre pièges suivants sont les plus fréquents, et chacun a son contre-poison.

1. La course aux chiffres

Mesurer pour mesurer, sans action. Un KPI qui ne déclenche jamais de décision est inutile. Chaque indicateur doit répondre à la question : « que ferons-nous si ce chiffre dépasse tel seuil ? ». Sans réponse, retirez-le du tableau de bord.

2. Les métriques de vanité

Afficher « 0 vulnérabilité critique » est gratifiant, mais trompeur si l'on ne scanne que 10 % du parc. Une métrique de vanité flatte sans informer : contextualisez toujours avec la couverture, et méfiez-vous d'un indicateur qui ne baisse jamais.

3. L'effet Cobra

L'effet Cobra tient son nom d'une anecdote coloniale : une prime aux cobras tués aurait poussé des habitants à en élever. Il survient quand les équipes optimisent la métrique plutôt que la sécurité, par exemple en fermant des vulnérabilités comme « risque accepté » pour améliorer le MTTR sans rien corriger. Suivez les acceptations à part.

4. Surcharge d'indicateurs

Trop de KPIs noient l'information. Limitez-vous à 10 à 15 indicateurs, avec une hiérarchie claire entre ceux de la revue quotidienne et ceux de la revue mensuelle. Pour situer ce chantier dans une trajectoire plus large, la leçon Évaluer sa maturité avec OWASP DSOMM propose une grille complète.

Ressources complémentaires

Ces ressources font autorité sur le sujet et servent à justifier vos choix de seuils devant un auditeur ou un comité des risques. Elles ont été vérifiées le 1er octobre 2026.

Ressource	Description	Lien
OWASP Top 10:2025	Classement des risques applicatifs, dont la catégorie A03 sur la chaîne d'approvisionnement	owasp.org
NIST Cybersecurity Framework 2.0	Cadre en six fonctions, dont la fonction Govern (pilotage)	nist.gov
IBM Cost of a Data Breach 2026	Étude annuelle sur le coût moyen d'une violation de données	ibm.com
Prometheus, nommage des métriques	Conventions de nommage, dont le suffixe _total des compteurs	prometheus.io
Prometheus, tests unitaires des règles	Format des fichiers de test de promtool test rules	prometheus.io

Glissez pour voir

À retenir

• MTTD et MTTR mesurent la réactivité : moins d'une heure pour détecter une critique, moins de 24 heures pour la corriger.
• Les SLA (24 h, 7 j, 30 j, 90 j) sont des maximums : suivez le taux de conformité, pas seulement la moyenne.
• Le Risk Score pondère les vulnérabilités ouvertes par criticité ; l'exemple de la leçon vaut 2,45, zone Bon.
• En PromQL, une somme sur une série absente ne vaut pas 0 : sans or vector(0), le Risk Score disparaît quand il n'y a aucune critique.
• La couverture de scan se vise à 100 % : un actif non scanné est une faille invisible.
• Trois niveaux de tableaux de bord (exécutif, opérations, équipe) servent trois rythmes de décision.
• Une règle d'alerte se teste avec promtool test rules avant d'être déployée.
• Commencez par 3 à 4 KPIs qui déclenchent des décisions, puis élargissez.

Contrôle de connaissances

Vérifiez que l'essentiel de cette leçon est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

FAQ : questions fréquentes

Les questions ci-dessous reprennent les doutes les plus courants sur les KPIs sécurité : différence entre MTTD et MTTR, choix des seuils, calcul du Risk Score et outillage.

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

Quelle est la différence entre MTTD et MTTR ?

Comment calculer le Risk Score en sécurité ?

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

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

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

×

📖 Voir la documentation →