Soixante-dix mille. C’est le nombre de CVE que la communauté de la sécurité aura enregistré d’ici la fin 2026 — soit près de 200 nouvelles vulnérabilités chaque jour, week-ends compris. Pendant que vous lisiez cette phrase, trois nouvelles entrées viennent probablement d’être ajoutées au NVD. Pour les équipes SecOps qui opèrent avec des ressources humaines figées depuis deux ans, ce chiffre n’est pas une statistique : c’est une sentence.

La bonne nouvelle — si tant est qu’il y en ait une — c’est que survivre à cette avalanche est possible. Pas en travaillant plus, mais en travaillant radicalement autrement. Voici comment les équipes qui s’en sortent ont reconfiguré leurs processus, leurs outils et leur culture.

L’inflation des CVE : comprendre pourquoi la digue a cédé

La croissance exponentielle du nombre de CVE n’est pas un accident. Elle résulte de plusieurs forces convergentes. D’abord, la multiplication des CNA (CVE Numbering Authorities) : en 2026, plus de 400 organisations dans le monde ont le droit d’émettre des identifiants CVE, là où elles n’étaient qu’une centaine en 2020. Chaque fournisseur de cloud, chaque éditeur de logiciel embarqué, chaque grand groupe industriel est désormais son propre émetteur.

Ensuite, la surface d’attaque elle-même a explosé. La prolifération des dépendances open source dans les chaînes de build — phénomène amplifié par la généralisation des architectures microservices — signifie qu’une seule vulnérabilité dans une bibliothèque partagée peut générer des dizaines d’entrées CVE distinctes selon les contextes d’intégration. Log4Shell a montré la voie en 2021 ; depuis, chaque découverte majeure dans une librairie de bas niveau produit une cascade.

Enfin, les programmes de bug bounty se sont professionnalisés. Des milliers de chercheurs indépendants vivent aujourd’hui de la découverte de vulnérabilités, avec des plateformes qui indexent, revendent et divulguent de manière coordonnée. Le volume est structurellement en hausse permanente.

Le mirage du CVSS : pourquoi le score seul vous condamne

Le réflexe conditionné de toute équipe SecOps face à une CVE, c’est de regarder le score CVSS. Un 9.8 critique ? Alerte rouge. Un 3.2 ? File d’attente basse priorité. Cette logique, rassurante dans sa simplicité, est aussi l’une des causes principales de l’épuisement des équipes — et paradoxalement, de leur exposition réelle.

Le CVSS mesure la sévérité intrinsèque d’une vulnérabilité dans des conditions théoriques. Il ne dit rien de votre contexte. Une CVE notée 9.8 dans un composant que vous n’avez pas déployé vaut strictement zéro dans votre périmètre. À l’inverse, une CVE à 5.4 dans un service exposé sur Internet, sans authentification, avec des données clients derrière, mérite votre attention immédiate.

Les équipes qui survivent ont intégré des métriques contextuelles complémentaires : l’exploitation active dans la nature (suivi via EPSS — Exploit Prediction Scoring System), la présence dans le catalogue KEV (Known Exploited Vulnerabilities) de la CISA, et surtout la criticité de l’actif concerné dans leur propre topologie.

Automatiser le triage : le script qui change tout

La priorisation manuelle à 70 000 CVE par an est mathématiquement impossible. L’automatisation n’est plus un luxe — c’est la condition de survie. Voici un exemple de script Python qui croise les données NVD avec le score EPSS et le catalogue KEV pour produire une liste de vulnérabilités réellement prioritaires pour votre parc :

#!/usr/bin/env python3
"""
CVE Triage Automatisé — croisement NVD + EPSS + KEV
Usage : python3 cve_triage.py --assets assets.txt --output rapport.csv
"""

import requests
import csv
import json
import argparse
from datetime import datetime, timedelta

NVD_API = "https://services.nvd.nist.gov/rest/json/cves/2.0"
EPSS_API = "https://api.first.org/data/v1/epss"
KEV_URL  = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"

CVSS_SEUIL   = 7.0
EPSS_SEUIL   = 0.10
JOURS_FENETRES = 30

def charger_kev():
    r = requests.get(KEV_URL, timeout=30)
    r.raise_for_status()
    data = r.json()
    return {v["cveID"] for v in data.get("vulnerabilities", [])}

def recuperer_cves_recentes():
    date_fin   = datetime.utcnow()
    date_debut = date_fin - timedelta(days=JOURS_FENETRES)
    params = {
        "pubStartDate": date_debut.strftime("%Y-%m-%dT00:00:00.000"),
        "pubEndDate":   date_fin.strftime("%Y-%m-%dT23:59:59.999"),
        "resultsPerPage": 2000,
    }
    r = requests.get(NVD_API, params=params, timeout=60)
    r.raise_for_status()
    return r.json().get("vulnerabilities", [])

def enrichir_epss(cve_ids):
    chunks = [cve_ids[i:i+100] for i in range(0, len(cve_ids), 100)]
    scores = {}
    for chunk in chunks:
        params = {"cve": ",".join(chunk)}
        r = requests.get(EPSS_API, params=params, timeout=30)
        if r.ok:
            for item in r.json().get("data", []):
                scores[item["cve"]] = float(item.get("epss", 0))
    return scores

def trier_et_scorer(cves_raw, kev_set, epss_map):
    resultats = []
    for item in cves_raw:
        cve   = item["cve"]
        cve_id = cve["id"]
        cvss = 0.0
        metrics = cve.get("metrics", {})
        if "cvssMetricV31" in metrics:
            cvss = metrics["cvssMetricV31"][0]["cvssData"]["baseScore"]
        elif "cvssMetricV30" in metrics:
            cvss = metrics["cvssMetricV30"][0]["cvssData"]["baseScore"]
        elif "cvssMetricV2" in metrics:
            cvss = metrics["cvssMetricV2"][0]["cvssData"]["baseScore"]

        if cvss < CVSS_SEUIL:
            continue

        epss  = epss_map.get(cve_id, 0.0)
        in_kev = cve_id in kev_set
        score_composite = cvss * 10
        if in_kev:         score_composite += 40
        if epss > EPSS_SEUIL: score_composite += epss * 20

        description = ""
        for d in cve.get("descriptions", []):
            if d["lang"] == "en":
                description = d["value"][:200]
                break

        resultats.append({
            "cve_id":    cve_id,
            "cvss":      cvss,
            "epss":      round(epss, 4),
            "kev":       in_kev,
            "score":     round(score_composite, 1),
            "desc":      description,
        })

    return sorted(resultats, key=lambda x: x["score"], reverse=True)

def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("--output", default="rapport_triage.csv")
    args = parser.parse_args()

    print("[*] Chargement du catalogue KEV (CISA)...")
    kev = charger_kev()
    print(f"    {len(kev)} CVE exploitées activement répertoriées.")

    print("[*] Récupération des CVE récentes (NVD)...")
    cves_raw = recuperer_cves_recentes()
    print(f"    {len(cves_raw)} CVE dans la fenêtre de {JOURS_FENETRES} jours.")

    ids = [v["cve"]["id"] for v in cves_raw]
    print("[*] Enrichissement EPSS...")
    epss = enrichir_epss(ids)

    print("[*] Tri et scoring composite...")
    resultats = trier_et_scorer(cves_raw, kev, epss)

    with open(args.output, "w", newline="", encoding="utf-8") as f:
        writer = csv.DictWriter(f, fieldnames=["cve_id","cvss","epss","kev","score","desc"])
        writer.writeheader()
        writer.writerows(resultats)

    print(f"[+] Rapport généré : {args.output} ({len(resultats)} CVE retenues)")

if __name__ == "__main__":
    main()

Patch management : arrêter de vouloir tout corriger

L’une des ruptures mentales les plus difficiles à opérer pour une équipe SecOps est d’accepter que patcher 100 % des CVE est non seulement impossible, mais contre-productif. Concentrer les ressources sur l’exhaustivité dilue l’effort là où il compte et génère une fatigue opérationnelle qui finit par tuer la vigilance sur les vrais risques.

Les meilleures équipes ont adopté une logique de « patch intelligents » structurée en trois niveaux. Niveau 1 : les CVE présentes dans le catalogue KEV ou avec un score EPSS supérieur à 0,4 — elles obtiennent un SLA de 24 à 72 heures, sans exception. Niveau 2 : les CVE critiques (CVSS ≥ 9) sur des actifs exposés — SLA de 7 jours. Niveau 3 : tout le reste, traité dans les cycles de maintenance habituels, mensuels ou trimestriels.

Outillage : construire un pipeline CVE à la place d’une pile d’alertes

La transformation la plus structurante que les équipes SecOps performantes ont réalisée, c’est de passer d’un empilement d’outils déconnectés à un pipeline cohérent. Dans l’architecture cible, les flux de données CVE (NVD, OSV, flux propriétaires des éditeurs) arrivent dans un agrégateur central — souvent un SOAR ou un outil dédié comme Nucleus ou Vulcan Cyber — qui enrichit automatiquement chaque entrée avec les données EPSS, KEV, et l’inventaire d’actifs issu de la CMDB.

La sortie de ce pipeline n’est pas une liste de CVE : c’est un backlog priorisé, assigné aux équipes responsables, avec des tickets déjà créés dans Jira ou ServiceNow, un SLA calculé automatiquement, et une traçabilité complète pour l’audit. Le rôle de l’analyste SecOps n’est plus de trier manuellement — il devient celui d’un superviseur de pipeline, qui intervient sur les exceptions et affine les règles de priorisation.

La dimension humaine : prévenir le burnout de l’analyste SecOps

Derrière les chiffres et les pipelines, il y a des humains. L’inflation des CVE a un coût psychologique réel sur les équipes de sécurité. Le sentiment permanent d’être en retard, de courir après un horizon qui recule, d’essuyer des reproches lors de chaque incident alors que le backlog est structurellement impossible à vider — c’est le terreau du burnout.

Les organisations qui retiennent leurs talents SecOps ont compris qu’il ne suffit pas d’automatiser le triage : il faut aussi recadrer le succès. Le KPI pertinent n’est pas « combien de CVE avons-nous patchées ce mois » mais « avons-nous traité toutes les CVE de niveau 1 dans le SLA convenu ». Le premier indicateur garantit l’échec permanent ; le second permet la fierté d’un travail bien fait, dans des limites réalistes.

Ce que 2027 va imposer : anticiper la prochaine vague

Si 2026 marque le seuil des 70 000 CVE annuelles, rien n’indique que la courbe va s’inverser. L’émergence de l’IA générative dans les outils de découverte de vulnérabilités — des chercheurs utilisent désormais des LLM pour fuzzer du code à une échelle inédite — laisse présager une nouvelle accélération.

Les équipes qui anticipent travaillent déjà sur deux axes. D’abord, le shift-left radical : intégrer l’analyse de vulnérabilités dès la phase de développement, dans les pipelines CI/CD, avec des outils comme Trivy, Grype ou Semgrep, pour intercepter les CVE avant qu’elles n’atteignent la production. Ensuite, la participation active à la communauté threat intelligence : partager ses IOC, consommer des flux sectoriels (ISACs), et contribuer aux bases de données partagées.

Conclusion : trois actions à lancer dès cette semaine

L’avalanche des CVE ne ralentira pas. Mais elle est navigable, à condition d’arrêter de la traiter comme un problème de volume et de la traiter comme un problème de priorisation. Voici trois actions concrètes à lancer sans attendre :

1. Adoptez le catalogue KEV comme ligne rouge absolue. Toute CVE listée par la CISA comme activement exploitée doit avoir un SLA de 72 heures maximum dans votre organisation, documenté et mesuré.

2. Déployez le scoring EPSS en complément du CVSS. L’API FIRST.org est gratuite et documentée. Intégrez-la dans votre pipeline de triage dès cette semaine.

3. Formalisez votre politique de patch en trois niveaux. Rédigez un document d’une page, faites-le valider par votre RSSI, et partagez-le avec les équipes métier.

Sources :

G
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.