Richard Hofrance Bankouezi · Consultant cyberdéfense MÉRIDIEN 002 · 47.0°N // 2.3°E · UTC+2 Disponible · missions T3 2027
Richard Hofrance Bankouezi
← Études de cas / Vulnerability Operations Center · étude 01
Étude 01 · Vulnerability Operations Center

Un moteur de scoring de risque qui vit avec le SI

Une plateforme de gestion des vulnérabilités où le score de risque n’est plus une note de CVE figée. Il croise la criticité réelle des actifs, leur exposition et la menace effective (EPSS, CISA KEV), puis se recalcule dès que le SI bouge. Concevoir la priorisation, puis la laisser se tenir à jour toute seule.

Rôle
Conception & développement
Domaine
Gestion des vulnérabilités
Cœur
Moteur de scoring · Python
Statut
En construction active
01Le problème

Le problème est bête et universel : le scanner note hors contexte. Un CVSS 9 sur un actif marginal passe devant un 7 au cœur du SI, et on court toute la journée après la mauvaise alerte. La priorisation se grippe · et l’infra sans agent, elle, ne remonte nulle part · angle mort intégral.

Couvrir tout le SI, y compris l’infrastructure sans agent.
Garder le référentiel de criticité indépendant des couches de scoring.
Pondérer par la menace réelle · exploitabilité (EPSS) et exploitation active connue (CISA KEV) · pas seulement le CVSS.
Contextualiser chaque vulnérabilité dans le SI : un même CVE n’a pas le même poids selon l’actif et son exposition.
Évaluer la criticité d’un actif avec des modèles qui collent au contexte de l’entreprise, à ses priorités et à la conception de l’architecture SI. Une formule unique ne tient jamais sur deux SI différents.
02Le modèle
Agrégation de signaux · architecture événementielle
Ingestion · scans & inventaireevents
Moteur de scoring · Pythoncompute
Signaux agrégés : criticité actif · exposition · EPSS · CISA KEV · contexte SI
→ score de risque contextualisé 742 /900
Référentiel de criticité · découplé
Modèles enfichables, adaptés au contexte de l’entreprise.
Priorisation & remédiationconsole de risque
03L'exécution
Architecture
Monorepo hexagonal, architecture événementielle. Le score réagit à chaque changement d’actif ou de vulnérabilité · fini le batch nocturne qui découvre l’exposition d’aujourd’hui avec un jour de retard.
Référentiel de criticité
Plusieurs modèles d’évaluation enfichables : la criticité d’un actif dépend du contexte de l’entreprise, de ses priorités métier et de la conception de son architecture SI. Le référentiel reste la source de vérité, indépendante des scores.
Moteur
Cœur de scoring en Python, isolé derrière des ports applicatifs. Je remplace le modèle de risque ou j’ajoute un signal sans toucher à ce qui tourne autour · c’est tout l’intérêt d’avoir tracé cette frontière.
Sources de menace
Flux EPSS et CISA KEV branchés sur le moteur : on quitte la note statique de CVE pour une probabilité d’exploitation réelle, recroisée avec la criticité de l’actif touché. Ce n’est plus ce qui fait peur qui remonte, c’est ce qui menace vraiment.
Données
Schéma structuré séparant le référentiel de criticité des résultats de scan et des signaux de menace, pour ajouter une couche de score sans réécrire la criticité.
04Le résultat
SI complet
Actifs couverts, infra sans agent incluse
1 réf.
Référentiel de criticité, découplé des scores
EPSS + KEV
Menace réelle agrégée, au-delà du CVSS
Temps réel
Recalcul piloté par les événements
Pythonevent-drivenmonorepo hexagonalPostgreSQLEPSSCISA KEVconsole de risque
Richard Hofrance Bankouezi
Concevoir la défense.
La tenir.
Me contacter
MÉRIDIEN 002 · 47.0°N // 2.3°E · UTC+2
Disponible T3 2027 · réponse < 48 h
© 2026 Richard Hofrance Bankouezi
Mentions légales · Conditions · Confidentialité