Dette de sécurité : identifier, mesurer, résorber

Une vulnérabilité non corrigée aujourd’hui sera toujours là demain. Une configuration temporaire devient permanente. Un contournement de sécurité “provisoire” s’installe dans la durée. La dette de sécurité désigne l’accumulation de ces compromis, failles et raccourcis qui fragilisent progressivement un système.

En résumé : La dette de sécurité est l’ensemble des vulnérabilités, configurations obsolètes et compromis techniques accumulés au fil du temps. Comme la dette financière, elle génère des intérêts : plus on attend, plus le coût de remédiation augmente.

L’erreur de l’urgence permanente

Une erreur fréquente consiste à repousser systématiquement les corrections de sécurité au profit des fonctionnalités.

Exemples de raisonnements dangereux :

• “On corrigera cette CVE après la release”
• “Ce compte de service temporaire, on le sécurisera plus tard”
• “Les tests de sécurité ralentissent le pipeline, on les désactive pour cette fois”
• “Cette configuration est vulnérable mais personne ne l’exploite”
• “On a toujours fait comme ça et on n’a jamais eu de problème”

Chaque report génère :

• Une vulnérabilité active que les attaquants peuvent exploiter
• Un coût croissant de remédiation (le contexte s’oublie, le code évolue)
• Une normalisation du risque (on s’habitue à vivre avec)
• Un effet boule de neige (une dette en cache souvent d’autres)

Erreur fréquente

Confondre “pas encore exploité” avec “pas exploitable”. L’absence d’incident visible ne signifie pas l’absence de risque. Les attaquants prennent leur temps pour repérer et exploiter les failles.

Anatomie de la dette de sécurité

La dette de sécurité prend plusieurs formes, souvent interconnectées.

Dette de vulnérabilités

Les failles connues non corrigées :

Type	Exemple	Risque
CVE non patchées	Log4Shell sur un serveur interne	Exploitation connue
Dépendances obsolètes	npm packages avec vulnérabilités	Supply chain
Configurations par défaut	Credentials admin/admin	Accès trivial
Protocoles dépréciés	TLS 1.0, SSHv1	Interception

Dette de conception

Les choix architecturaux qui créent des risques structurels :

• Absence de segmentation réseau
• Authentification centralisée sans MFA
• Secrets en dur dans le code
• Logs insuffisants ou inexistants
• Absence de chiffrement des données au repos

Dette de processus

Les pratiques qui accumulent les risques :

• Pas de revue de code sécurité
• Déploiements manuels sans validation
• Accès privilégiés non révoqués après départ
• Documentation de sécurité absente ou obsolète
• Tests de sécurité désactivés “temporairement”

Dette de connaissance

L’expertise non documentée qui part avec les équipes :

• Un seul expert connaît l’architecture de sécurité
• Pas de documentation des exceptions et dérogations
• Historique des incidents non capitalisé
• Procédures de réponse non testées

Comment la dette s’accumule

Le cycle de l’urgence

Nouvelle fonctionnalité urgente
        ↓
Raccourci de sécurité "temporaire"
        ↓
Release livrée à temps
        ↓
Équipe passe au projet suivant
        ↓
Le "temporaire" devient permanent
        ↓
Nouvelle urgence → nouveau raccourci
        ↓
Dette qui s'accumule

Les facteurs aggravants

Facteur	Impact sur la dette
Pression time-to-market	Raccourcis fréquents
Turnover élevé	Perte de contexte
Silos organisationnels	Personne ne voit l’ensemble
Absence de métriques	Dette invisible
Budget sécurité insuffisant	Remédiation reportée

Mesurer la dette de sécurité

On ne peut pas réduire ce qu’on ne mesure pas. Voici les indicateurs clés.

Métriques de vulnérabilités

Indicateur	Mesure	Cible
MTTR (Mean Time To Remediate)	Temps moyen de correction	< 30 jours critique
Âge moyen des CVE ouvertes	Ancienneté des failles	< 90 jours
Ratio CVE critiques/total	Proportion de failles graves	< 5%
Couverture des scans	% d’assets analysés	> 95%

Métriques de configuration

Indicateur	Mesure	Cible
Conformité aux baselines	% de configs conformes	> 90%
Dérive de configuration	Écarts post-déploiement	< 5%
Secrets exposés	Credentials dans le code	0
Certificats expirés	% de certificats valides	100%

Métriques de processus

Indicateur	Mesure	Cible
Couverture SAST/DAST	% de code analysé	> 80%
Taux de faux positifs	% d’alertes non pertinentes	< 20%
Temps de réponse incidents	Délai de première réponse	< 1h
Accès orphelins	Comptes inactifs avec droits	0

Scénario 1 : La CVE oubliée

Une équipe découvre une CVE critique dans une dépendance.

Accumulation de dette :

1. Semaine 1 : “On patche après le sprint”
2. Semaine 3 : “Le patch casse des tests, on reporte”
3. Mois 2 : “L’équipe est sur un autre projet”
4. Mois 4 : “Plus personne ne se souvient du contexte”
5. Mois 6 : Incident de sécurité, la CVE est exploitée
6. Post-mortem : 3 semaines pour comprendre et corriger

Coût réel :

• Correction initiale estimée : 2 jours
• Correction après 6 mois : 3 semaines
• Impact de l’incident : indisponibilité, données exposées, réputation
• Coût total : 50x l’estimation initiale

Avec gestion de la dette :

• CVE identifiée et priorisée automatiquement
• SLA de correction : 7 jours pour critique
• Blocage du déploiement si SLA dépassé
• Correction effectuée en 2 jours comme prévu

Scénario 2 : Le compte de service immortel

Un compte de service est créé pour un projet temporaire.

Accumulation de dette :

1. Création avec droits larges “pour aller vite”
2. Projet terminé, compte oublié
3. Équipe change, personne ne sait à quoi il sert
4. Mot de passe jamais roté (pas dans la politique)
5. 3 ans plus tard : compte toujours actif avec droits admin
6. Attaquant le découvre et l’utilise pour pivoter

Coût réel :

• Temps de création sécurisée : 1 heure
• Temps d’investigation post-incident : 2 semaines
• Remediation et durcissement : 1 mois
• Impact business : accès aux données clients

Avec gestion de la dette :

• Comptes de service avec expiration automatique
• Revue trimestrielle des accès
• Alerte sur comptes inactifs avec privilèges
• Rotation automatique des credentials

Stratégies de réduction

Rendre la dette visible

La dette cachée ne sera jamais traitée :

• Dashboard de sécurité : vulnérabilités, conformité, métriques en temps réel
• Rapports réguliers : état de la dette présenté au management
• Étiquetage explicite : marquer le code et les configs avec dette connue
• Coût estimé : chiffrer la dette en jours de travail

Intégrer la réduction dans le flux

Ne pas traiter la dette comme un projet séparé :

• Boy Scout Rule : laisser le code plus sûr qu’on ne l’a trouvé
• Budget dédié : 20% du temps pour la dette technique et sécurité
• Sprint de sécurité : un sprint sur quatre focalisé sur la remédiation
• Definition of Done : inclure les critères de sécurité

Prioriser intelligemment

Toute la dette ne se vaut pas :

Priorité	Critères	Action
Critique	Exploitable, exposé, données sensibles	Immédiat (< 7 jours)
Haute	CVE connue, système important	Court terme (< 30 jours)
Moyenne	Risque modéré, peu exposé	Planifié (< 90 jours)
Basse	Risque faible, amélioration	Opportuniste

Prévenir l’accumulation

La meilleure dette est celle qu’on ne crée pas :

• Shift-left : sécurité dès la conception
• Guardrails automatisés : bloquer les configurations non conformes
• Templates sécurisés : fournir des bases saines
• Formation continue : développeurs sensibilisés à la sécurité

Pièges courants

Le grand rattrapage

Vouloir tout corriger d’un coup. Résultat : projet pharaonique qui n’aboutit jamais. Préférer une réduction continue et mesurée.

La dette cachée volontairement

Ne pas remonter les problèmes par peur des conséquences. Créer une culture où signaler la dette est valorisé, pas puni.

Les métriques de vanité

Se féliciter du nombre de CVE corrigées sans regarder leur criticité ou leur âge. Une CVE critique de 6 mois vaut plus que dix CVE basses d’une semaine.

L’outillage sans processus

Déployer des scanners sans définir qui traite les alertes, dans quel délai, avec quelle priorisation. Les alertes s’accumulent, personne n’agit.

La dette transférée

Externaliser un composant sans vérifier la dette du fournisseur. La dette existe toujours, elle est juste invisible.

Indicateurs de dette critique

Signaux d’alarme qui indiquent une dette devenue dangereuse :

• CVE critiques de plus de 90 jours : fenêtre d’exploitation large
• Systèmes non patchés depuis 1 an : dette structurelle
• Secrets dans le code : risque de fuite à chaque commit
• Comptes privilégiés sans MFA : compromission facile
• Logs inexistants : impossible de détecter ou investiguer
• Documentation absente : personne ne sait ce qui est vulnérable
• Tests de sécurité désactivés : nouvelles dettes créées à chaque release

À retenir

1. La dette de sécurité génère des intérêts — plus on attend, plus le coût de correction augmente. Une CVE corrigée en 1 semaine coûte 10x moins qu’en 6 mois.

2. Rendre la dette visible — un dashboard, des métriques, des rapports réguliers. Ce qui n’est pas mesuré n’est pas traité.

3. Intégrer la réduction dans le quotidien — budget dédié, Boy Scout Rule, critères de sécurité dans la Definition of Done.

4. Prioriser par risque réel — exploitabilité, exposition, sensibilité des données. Pas par ancienneté ou volume.

5. Prévenir vaut mieux que guérir — shift-left, guardrails automatisés, templates sécurisés. La meilleure dette est celle qu’on ne crée pas.

6. Créer une culture de transparence — signaler la dette doit être valorisé. La dette cachée est la plus dangereuse.

Liens utiles

• Défense en profondeur — Plusieurs couches pour compenser les failles résiduelles
• Surface d’attaque — Réduire l’exposition limite la dette exploitable
• Moindre privilège — Limiter les droits réduit l’impact de la dette
• Zero Trust — Ne pas faire confiance aux composants potentiellement endettés