Mars 2024, salle de réunion d’une scale-up fintech. Le RSSI présente les résultats du dernier audit de sécurité. La question du directeur technique tombe, implacable : « Combien de temps nous faut-il pour corriger une vulnérabilité critique ? » Silence gêné. Personne ne peut répondre avec certitude. Trois mois plus tard, après avoir mis en place les KPIs décrits dans ce guide, l’équipe peut affirmer : MTTR Critical < 18 heures, contre une estimation floue de « quelques jours » auparavant. La direction peut enfin prendre des décisions basées sur des données concrètes.

Mesurer la sécurité semble paradoxal : comment quantifier l’absence de catastrophe ? Pourtant, sans métriques objectives, impossible de savoir si vos investissements sécurité sont efficaces, si votre posture s’améliore ou se dégrade, et où concentrer vos efforts. Ce guide vous accompagne dans la définition et l’exploitation des indicateurs qui transforment la sécurité d’un centre de coûts obscur en un avantage compétitif mesurable.

Prérequis

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.

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 4 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 courrez 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 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.

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 2 heures à signaler un début d’incendie, les dégâts seront bien plus importants que s’il réagit en 2 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 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 depuis vos outils de scan :

# Métrique Prometheus pour le MTTD
# 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 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 :

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.

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.

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 20 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 modéré, 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

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 = 249 000%

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.

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. Voici un template :

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

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.

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 :

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 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 aller plus loin

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

Gestion des vulnérabilités

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

Ressources complémentaires

Ressource	Description	Lien
OWASP Security Metrics	Guide de référence sur les métriques sécurité applicative	owasp.org
NIST Cybersecurity Framework	Framework de mesure de maturité sécurité	nist.gov
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
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
Chaque métrique doit déclencher une action concrète si elle dépasse un seuil, sinon elle est inutile

KPIs Sécurité DevSecOps : mesurer votre posture de sécurité

Prérequis

Pourquoi mesurer la sécurité ?

Les 5 catégories de KPIs sécurité

Métriques de détection

MTTD — Mean Time To Detect

Implémentation Prometheus pour le MTTD

Métriques de remédiation

MTTR — Mean Time To Remediate

SLA par niveau de sévérité

Dette de vulnérabilités

Métriques de posture de sécurité

Risk Score — Score de risque global

Vulnerability Density — Densité de vulnérabilités

Métriques de couverture

Couverture des scans

Adoption des pratiques sécurité

Métriques d’efficacité des outils

Taux de faux positifs

ROI des outils de sécurité

Architecture des dashboards

Niveau Exécutif (CISO/RSSI)

Niveau Opérations (SecOps)

Niveau Équipe (Développeurs)

Implémentation Grafana

Rapport mensuel CISO

Alerting automatisé

Plan d’implémentation

Pièges à éviter

1. La course aux chiffres

2. Les métriques de vanité

3. L’effet Cobra

4. Surcharge d’indicateurs

Pour aller plus loin

Ressources complémentaires

À retenir