Les indicateurs pour piloter la sécurité du développement

Rendre visible la dette de sécurité

Sans métriques, la sécurité applicative est une réalité invisible pour la direction. Un RSSI qui déclare "nous avons une bonne sécurité applicative" sans données ne fournit pas d'information décisionnelle. Un RSSI qui présente "nous avons 47 vulnérabilités critiques en backlog, dont 12 ont plus de 30 jours, dans des applications qui traitent des données financières" donne à la direction une information sur laquelle elle peut agir — budget, priorisation, recrutement.

Les métriques de sécurité du développement remplissent cette fonction de visibilité. Elles transforment une propriété complexe et abstraite (le niveau de sécurité d'une codebase) en indicateurs concrets qui permettent le suivi dans le temps, la comparaison entre équipes ou applications, et la prise de décision d'investissement informée.

Les métriques opérationnelles clés

Le délai de remédiation par sévérité mesure le temps entre l'identification d'une vulnérabilité (via SAST, DAST, ou pentest) et sa correction validée. C'est l'indicateur qui traduit directement l'efficacité du programme de sécurité applicatif en termes de risque réel. La densité de vulnérabilités (vulnérabilités par millier de lignes de code) permet de comparer des applications de tailles différentes et de suivre l'amélioration dans le temps. Le taux de couverture des tests de sécurité (quelle proportion du code est couverte par des tests incluant des assertions de sécurité) mesure la qualité du filet de sécurité automatisé. L'âge moyen des dépendances vulnérables connues mesure la réactivité du processus de mise à jour.

Ces métriques doivent être collectées automatiquement par les outils intégrés dans le pipeline CI/CD — la collecte manuelle n'est pas scalable et crée des biais de sélection.

La corrélation sécurité-performance en DevSecOps

Une idée reçue persistante est que la sécurité et la vitesse de développement sont en opposition — qu'investir dans la sécurité ralentit les livraisons. Les recherches du programme DORA (DevOps Research and Assessment) réfutent ce mythe avec des données : les organisations à haute performance DevOps présentent simultanément de meilleures métriques de livraison (fréquence de déploiement, délai de changement) et de meilleures métriques de sécurité (délai de remédiation, taux de disponibilité).

Cette corrélation s'explique par le fait que les pratiques qui améliorent la qualité logicielle (intégration continue, tests automatisés, revues de code) bénéficient également à la sécurité. Le DevSecOps n'ajoute pas de friction au développement — il intègre les contrôles de sécurité dans les flux existants, rendant la sécurité une propriété émergente du processus plutôt qu'une phase distincte.

Présenter les métriques à la direction

Les métriques techniques de sécurité du développement doivent être traduites en termes de risque business pour être compréhensibles et actionnables par la direction. "47 vulnérabilités critiques non patchées depuis plus de 30 jours dans l'application de gestion des contrats clients" est plus percutant que "notre DAST score est de 73/100". La traduction implique d'identifier quelles applications traitent quelles catégories de données, et de mapper les vulnérabilités sur les risques métier correspondants.

Un tableau de bord de sécurité applicative présenté trimestriellement au CODIR, avec des tendances (progression ou régression depuis le trimestre précédent), des comparaisons sectorielles si disponibles, et des recommandations d'investissement hiérarchisées, est le format qui transforme les métriques techniques en outil de gouvernance.