Cybersécurité : les CVE s’accumulent. La vraie maturité, c’est de savoir lesquelles traiter, quand et comment.

GitLab, PHP, Node.js, NGINX, Python… Les alertes de sécurité rappellent que la surface d’attaque ne se limite ni au code métier ni aux infrastructures exposées sur Internet.

Elle englobe également les dépendances open source, les chaînes CI/CD, les images de conteneurs, les certificats TLS et jusqu’aux outils utilisés pour détecter les vulnérabilités.

Le véritable enjeu pour une DSI n’est pas de compter les CVE. C’est de maîtriser le risque réel et de démontrer sa capacité à le réduire.

Cinq principes pour passer d’une gestion réactive des alertes à une véritable stratégie de vulnérabilités.

1️⃣ Distinguer CVE, CVSS, EPSS et KEV : quatre indicateurs, des rôles différents.

• CVE : identifier et référencer une vulnérabilité.
• CVSS : évaluer sa sévérité technique selon différents scénarios d’impact.
• EPSS : estimer la probabilité qu’elle soit exploitée dans les 30 prochains jours.
• KEV : signaler les vulnérabilités dont l’exploitation réelle est connue.

Ces indicateurs ne répondent pas à la même question et aucun ne suffit isolément. Une vulnérabilité avec un CVSS élevé n’est pas automatiquement la priorité absolue. À l’inverse, une vulnérabilité moins sévère, mais activement exploitée sur un actif exposé et critique, peut représenter un risque immédiat.

La décision doit donc croiser l’exploitation connue, l’exposition, la criticité métier, la facilité d’exploitation, les mesures de protection existantes et l’impact potentiel.

2️⃣ Industrialiser le triage en cinq étapes reproductibles.

Une gestion efficace commence par un inventaire fiable des actifs et des composants. Il faut ensuite identifier les versions réellement déployées, qualifier l’exposition, évaluer le risque, puis corriger et vérifier.

Cette démarche doit être automatisée autant que possible, mais elle ne peut pas être entièrement déléguée à un outil. Les résultats doivent être contextualisés par les équipes d’architecture, de développement, d’exploitation et de sécurité.

Chaque alerte doit déboucher sur une décision traçable : correction, mise à niveau, mesure compensatoire, surveillance renforcée ou exception formellement acceptée.

3️⃣ Fixer des délais de correction et assumer les exceptions.

Une politique de gestion des vulnérabilités doit définir des SLA par niveau de risque, avec des échéances adaptées à la criticité de l’actif, à son exposition et à l’exploitation effective de la vulnérabilité.

Ces délais doivent être réalistes, mesurables et suivis dans le temps. Ils doivent également prévoir des mécanismes d’escalade lorsque la remédiation n’est pas engagée ou lorsqu’un risque dépasse le niveau accepté par l’organisation.

Une exception ne doit jamais être un oubli. Elle doit avoir un responsable clairement identifié, une justification documentée, des mesures compensatoires, une échéance et une date de réexamen. Accepter un risque peut être une décision légitime ; l’accepter sans le formaliser ne l’est pas.

4️⃣ Répondre rapidement à la question essentielle : « Sommes-nous concernés ? »

Lorsqu’une nouvelle vulnérabilité est publiée, la première question n’est pas toujours « Quel est son score ? », mais bien : « Où sommes-nous exposés ? »

Le SBOM (Software Bill of Materials) permet de connaître les composants réellement embarqués dans une application, leurs versions et leurs relations de dépendance.

Le VEX (Vulnerability Exploitability eXchange) permet de documenter si une vulnérabilité est exploitable, non exploitable ou encore en cours d’analyse dans un produit donné, avec les justifications nécessaires.

Ensemble, ils accélèrent l’analyse d’impact, évitent les investigations inutiles et facilitent la priorisation des remédiations. Ils améliorent également la qualité des échanges entre éditeurs, intégrateurs, équipes de développement et responsables de la sécurité.

5️⃣ Renforcer la détection et sécuriser toute la chaîne.

La réduction ou l’évolution de la couverture du NVD depuis avril 2026 impose de diversifier les sources : CERT-FR, avis éditeurs, GitLab, bases de données de vulnérabilités et catalogue KEV de la CISA.

Cette diversification ne doit toutefois pas conduire à empiler les outils sans gouvernance. Les sources doivent être qualifiées, comparées et intégrées dans un processus commun de veille, de validation et de décision.

Enfin, les scanners, leurs règles, leurs bases de données, leurs jetons d’accès et leurs pipelines doivent eux-mêmes être protégés, mis à jour et contrôlés. Leur couverture doit être régulièrement évaluée, tout comme la qualité de leurs résultats.

Un outil de sécurité compromis, mal configuré ou obsolète peut devenir un angle mort majeur et donner une illusion de protection. La chaîne de détection doit donc être considérée comme un actif critique à part entière.

Par Aghilas AZZOUG