risque360 — Modélisation STRIDE, Risques Fournisseurs & Recalibration par Incidents
Registre des risques unifié qui réunit trois sources sous un même moteur de notation probabilité × impact : modélisation STRIDE par composant applicatif, risque fournisseur noté par une heuristique transparente, et journal d'incidents qui propose un recalibrage de la probabilité sur 12 mois glissants — jamais appliqué sans validation explicite.
Contexte
J'ai construit risque360 en complément de mon registre risk-assessment-matrix (ISO/IEC 27005, EBIOS RM) : un registre de risques classique capture mal les menaces propres à une architecture applicative, les risques portés par les fournisseurs/tiers, et la façon dont un historique d'incidents devrait faire évoluer une probabilité déclarée « à froid ». J'ai réuni ces trois angles dans un registre unique, avec un mécanisme de recalibration de probabilité piloté par les données — la partie la plus différenciante du projet.
Les 4 modules
- Registre de risques organisationnels — dans l'esprit de risk-assessment-matrix (formulaire manuel, catégories métier)
- Modélisation de menaces applicatives (STRIDE) — pour un composant donné (API Gateway, service d'auth, base de données...), génère un risque par catégorie STRIDE : Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
- Registre des risques fournisseurs/tiers — un fournisseur (niveau d'accès, statut du questionnaire de sécurité, incident connu) génère automatiquement un risque, avec une probabilité initiale estimée par une heuristique transparente, jamais imposée, toujours modifiable
- Journal d'incidents & recalibration — chaque risque porte une clé de corrélation ; les incidents journalisés partageant cette clé permettent de calculer une probabilité suggérée sur une fenêtre glissante de 12 mois. La suggestion n'est jamais appliquée automatiquement : un bouton « Appliquer » explicite est requis
Algorithme de recalibration
- 0-2 incidents / 12 mois glissants
- Aucun ajustement
- 3-5 incidents
- Probabilité +1 (plafonné à 5)
- 6+ incidents
- Probabilité +2 (plafonné à 5)
- Exemple validé par les tests
- « Hameçonnage — vol d'identifiants » (probabilité déclarée 2/5) : 4 incidents liés sur 12 mois → suggestion 3/5, affichée avec un bouton « Appliquer » explicite
Heuristique fournisseur (transparente, éditable)
- Base
- Accès élevé : 3 · moyen : 2 · faible : 1
- +1
- Si questionnaire de sécurité non réalisé
- +1
- Si questionnaire conforme avec réserves
- +1
- Si incident connu dans les 12 derniers mois
- Plafond
- 5
Bug détecté et corrigé pendant le développement
La génération automatique de clé de corrélation (à partir du nom d'un fournisseur ou d'un composant STRIDE) ne retirait pas la ponctuation — par exemple « PayGateway Inc. » générait la clé fournisseur-paygateway-inc. avec un point final, ce qui aurait cassé silencieusement le lien avec les incidents journalisés partageant cette clé. Je l'ai corrigé avec une fonction slugifier() partagée qui retire diacritiques et ponctuation avant de générer la clé, et j'ai vérifié le correctif par un test direct du module en isolation (import avec cache-busting) pour écarter tout effet de cache de module ES pendant le débogage.
Résultats
- Stack
- HTML/CSS/JS vanilla (ES modules, sans dépendance) + CLI Python (argparse, Jinja2, pytest)
- Tests
- 6 tests pytest — bornes de niveaux, heuristique fournisseur, fenêtre 12 mois, paliers de recalibration, non-mutation de l'aperçu, validation du jeu d'exemple combiné
- Parité JS ↔ Python
- Logique de recalibration dupliquée à l'identique côté CLI Python (recalibration.py), testée séparément
- Interface
- App à onglets : Tableau de bord (heatmap + registre global), Registre, STRIDE, Fournisseurs, Incidents