5 min de lecture
CVSS vous dit qu’une vulnérabilité est grave. EPSS vous dit qu’elle a des chances d’être exploitée. KEV vous dit qu’elle l’est déjà. Aucun des trois ne vous dit quoi faire lundi matin. SSVC, la méthodologie du CERT/CC, comble exactement ce trou : elle ne note rien, elle décide.
Ce que je constate
J’avais déjà posé les bases de CVE, CVSS, EPSS et KEV dans la matrice de priorisation que j’avais construite en janvier. Elle tenait debout, et elle tient toujours.
Mais on constate qu’elle a un angle mort : elle produit un classement, pas une décision. Une fois que vous savez que la CVE-2026-XXXX a un CVSS de 9.8, un EPSS à 0.87 et qu’elle est dans le catalogue KEV, il vous reste encore à répondre à la vraie question : est-ce qu’on patche ce soir, cette semaine, ou au prochain cycle de maintenance ?
C’est précisément pour cela que SSVC a été conçu => pour trancher. Pas un score de plus à empiler sur les trois autres, un arbre de décision qui absorbe ces signaux et en sort une action.
Le CERT/CC et CISA l’ont co-développé, et CISA l’utilise désormais pour sa propre réponse aux vulnérabilités.
Un CVSS de 9.8 sur un environnement de dev isolé et un CVSS de 9.8 sur une API exposée qui traite des paiements ne méritent pas la même nuit blanche. CVSS ne fait pas cette différence. SSVC, si.
SSVC face aux autres référentiels
Ici quatre familles d’outils qui se complètent plus qu’elles ne se concurrencent, même si le marketing des vendeurs les présente souvent comme interchangeables.
| Référentiel | Sortie | Organisme | Force principale | Faiblesse principale |
|---|---|---|---|---|
| CVSS | Score 0-10 | FIRST | Standard universel, interopérable partout | Sévérité intrinsèque du composant ; ignore exploitation réelle et contexte métier |
| OWASP Risk Rating | Niveau qualitatif (Faible→Critique) | OWASP | Pensé pour l'AppSec, intègre des facteurs métier dès le départ | Manuel, subjectif, peut etre difficile à automatiser à l'échelle d'un parc |
| EPSS | Probabilité 0-1 | FIRST | Prédictif, basé ML, recalculé chaque jour | Ne dit rien de l'impact ni du contexte métier de l'actif touché |
| CISA KEV | Liste binaire (exploitée ou non) | CISA | Signal vérifié, appuyé par une obligation réglementaire (BOD 22-01) | Rétrospectif par nature ; ne couvre qu'une fraction des CVE |
| SSVC | Décision actionnable (Track/Attend/Act...) | CERT/CC + CISA | Orchestre les signaux précédents + contexte métier en une action par partie prenante | Exige une maturité de gouvernance (impact mission, impact sécurité des personnes) que peu d'organisations ont déjà |
Note du PandaRedacteur : j’ai vu trop de RSSI demander “le score CVSS” d’une CVE et décider juste avec cela….C’est justement le point que tente de combler SSVC. Par contre le score SSVC universel n’existe pas. Si un outil vous sort un chiffre unique appelé “score SSVC”, il a mal compris la méthode ou il vous vend autre chose sous ce nom, ou Jean-Kevin le stagiaire a mal tapé sur son clavier…
Avantages, inconvénients, limites
Je trouve trois avantages à SSVC. Tout d’abord, il force à documenter pourquoi une décision a été prise, arbre de décision à l’appui ; utile face à un auditeur qui demande de justifier un délai de remédiation. Ensuite, il sépare explicitement les rôles : la décision d’un éditeur de logiciel (dois-je publier un correctif en urgence ?) n’a rien à voir avec celle d’un client final (dois-je l’appliquer en urgence ?), et SSVC leur donne à chacun leur propre arbre plutôt qu’un score générique. Enfin, il consomme naturellement KEV et EPSS comme entrées du point de décision Exploitation plutôt que de les ignorer.
Mais il y a aussi des inconvénients… La documentation officielle du CERT/CC l’admet elle-même : supprimer le score numérique élimine la fausse précision, mais crée un inconfort chez les équipes qui trouvent un chiffre rassurant, même faux. Sur le plan opérationnel, remplir les points de décision Mission Impact et Well-being Impact exige de savoir ce que fait l’actif touché dans votre organisation ; beaucoup d’équipes sécurité n’ont tout simplement pas cette cartographie à jour.
La limite n’est pas dans l’arbre de décision. Elle est dans les données d’entrées qu’on a, ou qu’on n’a pas, pour le remplir.
C’est là que se loge la vraie limite de SSVC à grande échelle : chaque vulnérabilité, sur chaque actif, nécessite en théorie un passage dans l’arbre. Sur un parc cloud avec des milliers de composants scannés chaque jour, ce chaînage manuel devient vite le goulot d’étranglement du processus entier.
Et donc comment l’appliquer ?
Distinguons ici deux couches bien différentes dans l’arbre SSVC, et c’est cette distinction qui détermine ce qu’on peut automatiser sans risque.
La première couche, ce sont les points de décision qui se déduisent de données techniques objectives : Exploitation se lit directement dans un flux KEV et un score EPSS au-dessus d’un seuil ; Automatable se déduit de la nature de la vulnérabilité (accès réseau, absence d’interaction utilisateur) ; Technical Impact recoupe le CVSS existant et, en environnement cloud-native, la position du composant dans le graphe d’exposition ; un SBOM qui dit qu’un package vulnérable tourne dans un pod exposé publiquement vaut plus qu’un CVSS isolé. Cette couche est mécanisable : un pipeline DevSecOps qui croise SBOM (Syft/cdxgen), scanner de vulnérabilités, flux CISA KEV et API EPSS peut préremplir ces trois points de décision sans intervention humaine, à chaque scan.
La seconde couche, Mission Impact et Well-being Impact, reste fondamentalement un jugement métier : quel service dépend de cet actif, quelles conséquences en cas d’indisponibilité ou de compromission, y a-t-il un risque pour des personnes. Rien dans un scanner ne sait répondre à ça tout seul.
flowchart LR
SBOM["SBOM (Syft/cdxgen)"] --> AGG["Agrégateur de contexte"]
SCAN["Scanner de vulnérabilités"] --> AGG
KEV["Flux CISA KEV"] --> AGG
EPSS["API EPSS"] --> AGG
EXPO["Graphe d'exposition cloud<br/>(exposé / interne / air-gap)"] --> AGG
AGG --> AGENT["Agent IA : prérempli Exploitation,<br/>Automatable, Technical Impact"]
CMDB["Cartographie métier<br/>(criticité, safety)"] --> HUMAN["Revue humaine :<br/>Mission Impact, Well-being Impact"]
AGENT --> DECISION{"Arbre de décision SSVC"}
HUMAN --> DECISION
DECISION -->|"Track / Attend"| TICKET["Ticket automatique, SLA standard"]
DECISION -->|"Act"| GATE["Porte humaine obligatoire<br/>avant remediation d'urgence"]
style GATE fill:#dc3545,color:#fff
style HUMAN fill:#fd7e14,color:#fff
C’est exactement le même principe que je décris dans l’analyse de la position d’Amazon sur le human-in-the-loop : un agent qui préremplit un maximum de signaux objectifs fait gagner un temps réel, mais la décision Act, celle qui déclenche un correctif d’urgence en production, doit rester derrière une porte humaine.
Laisser un agent conclure seul qu’une vulnérabilité a un Mission Impact faible, sur la base d’une cartographie métier incomplète ou périmée, c’est reproduire silencieusement le même biais de normalisation de la déviance que pour n’importe quelle autre décision automatisée à fort enjeu.
Je détaille dans la version complète le mapping précis des points de décision SSVC vers des sources de données cloud concrètes, un exemple de pipeline GitHub Actions/GitLab CI qui préremplit l’arbre, et la checklist pour éviter qu’un agent surconfiant ne dérive silencieusement vos décisions Act vers du Track.
inkedIn</a></strong> en mentionnant cet article pour plus d'informations.</span>