Moins de bruit, plus d'impact : corriger les vraies menaces

Introduction

Dans la pratique de la gestion des vulnérabilités, il n’est pas rare de retrouver dans le tableau de bord de son scanneur de vulnérabilités un volume considérable de CVE et la sempiternelle question : Je commence par où ?

Dans mon [billet précédent] , j’ai présenté le VOC (Vulnerability Operations Center) : une approche RBVM qui priorise selon le risque réel, en s’appuyant sur le catalogue CISA KEV, l’EPSS et l’arbre de décision SSVC.

Ce billet s’inscrit dans la continuité du premier et il montre comment on peut réduire le bruit à l’aide du SBOM, du VEX et des informations en provenance de la CMDB.

L’objectif : filtrer l’inutile avant de prioriser l’urgence.

Quels intrants pour une priorisation efficace ?

L’efficacité d’un programme RBVM repose sur la qualité de ses intrants, qui permettent de réduire le bruit, d’identifier les vulnérabilités réellement exploitables et d’en mesurer le risque pour l’organisation.

Ces cinq intrants permettent à une organisation d’obtenir une visibilité sur ce qu’elle possède, ce qui la touche, ce qui est ciblé et ce qu’elle risque.

SBOM pour savoir ce qui tourne, VEX pour savoir quoi corriger

Alors que le [SBOM] dresse l’inventaire des composants logiciels, le [VEX] indique si les CVE détectées sont réellement exploitables dans les produits utilisés par l’organisation.

Les différents statuts du VEX

Le VEX attribue à chaque CVE l’un des quatre statuts, et chacun appelle une action VOC.

Par convention, le statut not_affected doit toujours s’appuyer sur une analyse de risques avec une justification consignée à des fins de traçabilité.

Avec le statut under_investigation, la vulnérabilité est considérée comme affectée jusqu’à la fin de l’analyse, réalisée dans un délai acceptable.

Le parcours d’une CVE dans le VOC

Pour être efficace et défendable lors d’un audit, la gestion des vulnérabilités doit suivre un processus formel, documenté et répétable. Le schéma ci-dessous présente le processus que je recommande.

Exemple avec des outils libres

Arch Linux propose dans ses dépôts officiels (core, extra) Trivy (scanner de vulnérabilités), Go (langage de programmation), jq (processeur de données JSON) et curl (transfert de données).

Cet ensemble de paquets permet de déployer un environnement local d’automatisation et de gestion des vulnérabilités.

# 1. Installation des outils en provenance des dépôts officiels sans AUR
sudo pacman -S --needed trivy go jq curl

# 2. vexctl, compilé depuis les sources officielles d'OpenVEX
go install github.com/openvex/vexctl@latest

# 3. Rendre vexctl accessible dans le PATH 
echo 'export PATH="$PATH:$HOME/go/bin"' >> ~/.bashrc
source ~/.bashrc

# 4. SBOM de l'hôte
trivy rootfs / --format cyclonedx --output hote.cdx.json

# 5. Récupérer le PURL du paquet concerné
PURL=$(jq -r '.components[] | select(.name=="openssl") | .purl' hote.cdx.json)

# 6. Déclaration VEX après analyse
vexctl create --product="$PURL" --vuln="CVE-AAAA-NNNNN" \
  --status="not_affected" --justification="vulnerable_code_not_in_execute_path" \
  > voc.openvex.json

# 7. Scan filtré par le VEX
trivy sbom hote.cdx.json --vex voc.openvex.json

Conclusion

👉 La gestion moderne des vulnérabilités ne consiste plus à tout corriger, mais à corriger ce qui compte. Elle repose sur la connaissance précise de ses actifs, sur le contexte et sur la menace réelle.

👉 La méthode présentée ici, avec le SBOM pour l’inventaire, le VEX pour la pertinence, KEV et EPSS pour la menace et SSVC pour la décision, est celle que je recommande pour optimiser vos efforts. Elle s’aligne sur les orientations de la CISA et sur l’approche CTEM.