risque360 — Modélisation STRIDE, Risques Fournisseurs & Recalibration par Incidents
Registre de risques unifié combinant trois sources sous un même moteur de scoring Probabilité × Impact : modélisation de menaces STRIDE par composant applicatif, risques fournisseurs/tiers scorés par une heuristique transparente, et un journal d'incidents qui suggère une recalibration de probabilité sur une fenêtre glissante de 12 mois — jamais appliquée sans un clic explicite.
Contexte
risque360 étend matrice-risques (elle-même une reconstruction française du projet open source risk-assessment-matrix) : 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 ». risque360 réunit 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 — identique dans l'esprit à matrice-risques (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é. Corrigé par une fonction slugifier() partagée qui retire diacritiques et ponctuation avant de générer la clé, vérifiée 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