Comment écrire un rapport de vulnérabilité corrigé

Comment écrire un rapport de vulnérabilité corrigé

Un rapport de vulnérabilité ne sert pas à prouver qu’une faiblesse existe. Il sert à obtenir une décision de correction, puis à vérifier que cette correction retire réellement le chemin d’attaque. La différence tient dans les détails : une preuve exploitable, un impact borné, un propriétaire désigné et un critère de fermeture testable.

Explication de la marmotte

Un rapport de vulnérabilité ressemble à un signalement précis sur un danger dans un bâtiment : dire seulement qu’une porte ferme mal ne suffit pas. Il faut montrer où elle se trouve, ce qui peut arriver, qui peut la réparer et comment vérifier que le problème a disparu.

→ Lire l’explication complète de la marmotte

Le rapport de vulnérabilité comme contrat de correction

Le compromis central est brutal : plus un rapport contient de détails exploitables, plus il accélère la correction, mais plus sa diffusion devient dangereuse. La recommandation est de documenter une preuve minimale suffisante dans le ticket opérationnel, puis de placer les secrets, données personnelles et charges d’exploitation complètes dans une pièce jointe à accès restreint. Un rapport vague ne protège rien, il diffuse juste l’incertitude.

Chaque constat doit répondre à cinq questions, dans cet ordre :

1. Quel actif est atteint ? Nom d’hôte, environnement, composant, version, chemin exposé et propriétaire technique.
2. Quelle condition permet l’attaque ? Accès anonyme, compte standard, position réseau, jeton compromis ou interaction nécessaire.
3. Quel est le résultat observable ? Lecture d’un secret, élévation de privilège, exécution de code, contournement d’authentification ou indisponibilité.
4. Quelle correction retire cette condition ? Changement de configuration, mise à jour, suppression d’un droit, rotation de secret ou isolation réseau.
5. Comment vérifier la fermeture ? Commande, test automatisé, journal attendu et condition d’échec explicite.

Le score CVSS (Common Vulnerability Scoring System) peut compléter la priorisation, mais ne doit pas la diriger seul. Un CVSS élevé sur un actif de démonstration isolé passe après une exposition Internet authentifiée par un compte ordinaire, même avec un score inférieur. Le contexte d’exposition, la valeur des données et l’existence d’une exploitation active comptent davantage que le thermomètre universel vendu dans les tableurs.

Un bon rapport distingue aussi la vulnérabilité de sa cause racine. « Version obsolète » décrit rarement une cause. L’absence d’inventaire, une dépendance non maintenue, un pipeline de déploiement sans contrôle de version ou une exception réseau permanente sont des causes racines. Corriger le paquet sans fermer la source de réapparition transforme le patch management en hamster administratif.

Pour les catégories de défauts récurrentes, associer la faiblesse à une entrée CWE (Common Weakness Enumeration) permet de consolider les tendances. Une injection de commande et une validation insuffisante d’entrée ne sont pas deux univers parallèles : la seconde explique souvent la première. Cette distinction donne une action d’architecture, pas seulement une tâche de maintenance.

Les pages sur les failles et sur l’architecture cybersécurité servent à relier un défaut ponctuel à une décision de conception. Un ticket ne remplace pas cet exercice. Il le déclenche.

Preuve d’exploitation, impact et critères de fermeture

La preuve doit être reproductible par l’équipe qui corrige, avec les droits minimaux nécessaires. Une capture d’écran sans URL, horodatage, requête ni réponse est un souvenir, pas une preuve. Une charge d’exploitation complète incluant un secret de production est une fuite organisée avec mise en page.

Documenter les prérequis exacts de reproduction : système concerné, version du composant, identité utilisée, emplacement réseau, paramètres et état attendu. Si l’exploitation dépend d’une session existante, préciser sa durée, son mode de création et la révocation attendue. La révocation d’un certificat ou d’un jeton ne détruit pas rétroactivement les sessions déjà établies : le rapport doit donc vérifier la prochaine authentification et, si nécessaire, l’invalidation des sessions actives.

L’impact doit être formulé comme une capacité obtenue, jamais comme une hypothèse dramatique. Écrire « lecture du fichier de configuration contenant les identifiants de base de données » est vérifiable. Écrire « compromission totale possible » ne l’est pas tant que la chaîne d’élévation, les droits du compte et les contrôles intermédiaires ne sont pas démontrés.

Un identifiant CVE (Common Vulnerabilities and Exposures) est utile lorsqu’un produit vulnérable est concerné, mais il ne décrit pas l’exposition locale. Deux instances affectées par le même CVE peuvent présenter des risques opposés selon que l’interface est privée, filtrée, exposée ou protégée par une authentification forte. Copier le bulletin éditeur dans un ticket ne produit pas un rapport. Cela produit un miroir, et les miroirs ne patchent rien.

Le critère de fermeture doit attaquer le correctif, pas seulement constater qu’un changement a été déployé. Après une règle de proxy, rejouer la requête bloquée depuis le même segment réseau. Après une rotation de secret, vérifier que l’ancien secret échoue et que le nouveau fonctionne uniquement depuis les services autorisés. Après une mise à jour, vérifier la version effective au démarrage et l’absence de régression fonctionnelle. Une fermeture fondée sur « changement livré » est une promesse. Une fermeture fondée sur une preuve négative est un contrôle.

Exemple de preuve reproductible pour une exposition de dépôt

L’exemple suivant construit un laboratoire local où un serveur expose par erreur le fichier HEAD d’un répertoire Git. Git est un gestionnaire de versions. La preuve montre l’exposition sans télécharger l’intégralité du dépôt, ce qui limite les données manipulées dans le rapport.

# Créer un répertoire de test contenant une métadonnée Git exposée.
mkdir -p /tmp/rapport-vuln/.git
printf 'ref: refs/heads/main\n' > /tmp/rapport-vuln/.git/HEAD

# Démarrer un serveur local dans un terminal séparé.
python3 -m http.server 8080 --directory /tmp/rapport-vuln

# Dans un second terminal, reproduire la lecture non authentifiée.
curl --fail --silent http://127.0.0.1:8080/.git/HEAD

# Résultat attendu : "ref: refs/heads/main".
# Critère de fermeture : après correction, cette requête doit retourner 403 ou 404.

Le rapport associé doit indiquer que la lecture de HEAD seule ne donne pas automatiquement accès au code. Elle établit néanmoins que les métadonnées du dépôt sont accessibles. L’impact dépend ensuite de l’accès à d’autres objets Git, des secrets présents dans l’historique et des protections du serveur web.

La correction prioritaire consiste à retirer le répertoire publié de la racine servie par le serveur. Bloquer seulement /.git/HEAD est insuffisant : les chemins alternatifs, les fichiers d’objets et les fichiers de configuration restent à examiner. Une règle de refus générique sur /.git réduit l’exposition, mais ne remplace pas la séparation entre artefact déployé et arbre de travail. Les dépôts ne sont pas des répertoires de livraison, même si une démonstration de plateforme prétend faire de chaque dossier une expérience collaborative.

Surface d’attaque du rapport et protection des preuves

Un rapport de vulnérabilité est lui-même un actif sensible. Il peut contenir des adresses internes, versions précises, chemins d’administration, jetons, données d’utilisateurs et procédures d’exploitation. L’attaquant apprécie ce niveau de documentation. Les défenseurs aussi, ce qui explique le problème.

Le système de suivi doit imposer une authentification multifacteur, c’est-à-dire une connexion fondée sur au moins deux preuves distinctes d’identité. Les droits doivent suivre un modèle RBAC (Role-Based Access Control), où l’accès dépend d’un rôle défini, et non d’une liste de personnes entretenue à la main jusqu’à la prochaine extinction du Soleil. Les groupes d’accès aux rapports critiques doivent être séparés des groupes de développement ordinaires.

Ne jamais inscrire un mot de passe, une clé privée, un jeton d’accès ou une chaîne de connexion complète dans le corps du ticket. Fournir un identifiant de secret, son emplacement dans le gestionnaire de secrets et une empreinte cryptographique si une vérification est nécessaire. Si un secret a été exposé pendant la démonstration, le rapport doit exiger sa rotation même si aucune utilisation malveillante n’est connue. L’absence de trace n’est pas la preuve d’une absence d’accès.

Conserver les preuves brutes avec une durée de rétention définie : réponse réseau, journaux, captures, versions et empreintes de fichiers. Chiffrer les archives, journaliser leurs accès et tester leur restauration. Une sauvegarde de rapports inutilisable lors d’un audit ou d’un incident vaut une armoire verrouillée dont la clé a été archivée dans la même armoire. Le RPO (Recovery Point Objective) fixe la perte de données acceptable, le RTO (Recovery Time Objective) fixe le délai acceptable de remise à disposition. Ces objectifs doivent être compatibles avec la gravité des rapports stockés.

Circuit de remédiation, supervision et réouverture

Attribuer le rapport à un propriétaire technique nommé et à un propriétaire de risque distinct lorsque nécessaire. Le premier réalise le changement, le second accepte explicitement un report ou un risque résiduel. Sans cette séparation, une équipe peut déclarer son propre compromis acceptable, ce qui est pratique jusqu’au jour où cela ne l’est plus.

Fixer une échéance selon l’exploitabilité, l’exposition et la criticité métier. Un accord de niveau de service, ou SLA (Service Level Agreement), peut mesurer ce délai, mais ne doit pas devenir une permission d’attendre la dernière heure. Une vulnérabilité activement exploitée sur un service exposé exige une mesure compensatoire immédiate : filtrage, désactivation de fonction, restriction d’accès ou rotation de crédential. Le correctif durable peut suivre, pas l’inverse.

Superviser la correction dans le temps. Une règle de pare-feu peut disparaître après une refonte réseau, une image corrigée peut être remplacée par une ancienne version, un compte supprimé peut être recréé par synchronisation. Ajouter un contrôle de configuration, une détection de version ou un test de régression au cycle de livraison. La correction qui dépend d’un souvenir humain a déjà commencé à se dégrader.

Un rapport ne garantit pas l’absence de vulnérabilités voisines, la détection d’une exploitation passée, la conformité réglementaire ou la continuité de service. Ces garanties viennent respectivement de la revue d’architecture, de la journalisation et de l’investigation, de la gouvernance, puis des plans de reprise. Le rapport relie ces mécanismes, il ne les remplace pas.

🐝 Ce qui arrive si on s’en passe

Sans rapport structuré, la porte reste entrouverte sur plusieurs plans. Un constat sans actif nommé ni version circule d’équipe en équipe sans propriétaire, et se referme sur un simple commentaire de bonne volonté : la date de correction n’est plus démontrable lors d’un audit ou d’une investigation postérieure. Les constats se dupliquent, se contredisent, et l’arbitrage entre deux faiblesses devient une question d’ordre d’arrivée plutôt que d’exposition réelle. Sans rattachement à une catégorie de faiblesse, aucune tendance ne se consolide : le même défaut réapparaît sous un autre nom à chaque livraison, sans qu’aucun signal ne l’indique. Un suivi laissé libre accumule aussi jetons, chemins d’administration et adresses internes dans des tickets lisibles par tous, offrant à toute lecture non autorisée une cartographie prête à l’emploi des chemins encore ouverts.

🦫 Explication de la marmotte 🍫

Un rapport de vulnérabilité sert à faire corriger un défaut de sécurité de façon contrôlable. Il commence par identifier précisément le système touché, la version concernée et les conditions nécessaires pour reproduire le problème. Il montre ensuite un résultat observable : par exemple lire une information qui devrait être cachée, contourner une connexion ou obtenir un droit interdit.

Le rapport doit expliquer les conséquences réelles de ce résultat. Il faut éviter les phrases alarmistes sans preuve. Si le défaut permet de lire un fichier, il faut dire quel fichier peut être lu et ce qu’il contient, sans recopier des mots de passe ou des clés secrètes dans le document.

La correction demandée doit supprimer la condition qui permettait l’attaque. Après le changement, une personne différente doit rejouer le test initial et constater que l’accès échoue. Vérifier seulement qu’une mise à jour a été installée ne suffit pas : la mauvaise configuration peut rester présente.

Le document doit aussi être protégé, car il contient parfois des informations qui aideraient un attaquant. Son accès est limité, les preuves sont conservées de manière chiffrée, et les secrets découverts sont remplacés. Enfin, un responsable suit le délai de correction et un contrôle régulier vérifie que le problème ne revient pas après une modification future.

À lire aussi

• Comment capitaliser et payer la dette de sécuritéLa dette de sécurité se capitalise par l'exposition, la dépendance et la perte de capacité de correction, puis se paie par des travaux d'architecture, d'exploitation et de réduction du risque.
• Mot de passe partagé en équipe et risques réelsLe mot de passe partagé oppose la continuité opérationnelle d'une équipe à la perte de traçabilité, de révocation et de contrôle.
• Laisser une équipe se tromper sans casser la productionLaisser une équipe se tromper est un risque pédagogique à encadrer par des limites techniques, des données contrôlées et une exploitation préparée.
• Mettre en place une gestion récurrente des vulnérabilitésGuide pratique pour inventorier les actifs, scanner les vulnérabilités, prioriser les correctifs et organiser un cycle de patch management récurrent.

Pages voisines

La citent

• Intégrer SAST, DAST et IAST dans une CI/CD

Comment écrire un rapport de vulnérabilité corrigé

Elle cite

• ⇄Lien dans les deux sens :PSIRT et divulgation coordonnée des vulnérabilités produit sous CRA
• Patch management d’un parc de postes hétérogène
• Prioriser les vulnérabilités avec CVSS 4.0, EPSS, KEV et exposition

⇄ : les deux pages se citent l’une l’autre.