Le Trust Score : un chiffre pour le conseil, six composantes pour l'opérateur
Un chiffre entre 0-100, mis à jour toutes les 30 minutes sur base de données live. Formule transparente, reproductible via inputs_hash, prêt pour votre reporting trimestriel. Pas de chiffre marketing black-box.
La sécurité est difficile à rapporter à un conseil d'administration. « Nous avons eu 247 alertes ce trimestre » ne dit rien. « Nous sommes conformes NIS2 » est une affirmation sans mesurabilité. « Nous avons corrigé trois CVE critiques » manque de contexte.
Ce qu'un administrateur veut savoir est simple : sommes-nous mieux ou moins bien sécurisés que le mois dernier ? Et comment je le sais ?
Le Trust Score monsys donne une réponse à cette question : un chiffre entre 0 et 100, mis à jour toutes les 30 minutes sur base de données techniques live. Pas une évaluation annuelle, pas un assessment subjectif — un chiffre reproductible avec une formule transparente.
Le Trust Score est la première chose que vous voyez — un chiffre, évolution 7j/30j, breakdown par composante.
Ce que mesure le Trust Score
Le score est une moyenne pondérée sur six composantes :
| Composante | Poids | Ce qu'elle mesure |
|---|---|---|
| Patch hygiene | 30 % | CVE ouvertes, pondérées par EPSS et âge |
| Agent health | 20 % | Tous les serveurs sont-ils actifs et à jour ? |
| Secrets exposure | 15 % | Findings sécurité ouvertes (SUID, world-writable, configs SSH faibles) |
| Configuration drift | 15 % | Changements de binaires (process DNA) et déviations config |
| EAT discipline | 10 % | Les Emergency Actions s'exécutent-elles avec succès ? |
| Evidence continuity | 10 % | Y a-t-il une preuve d'audit ininterrompue sur 12 mois ? |
Pourquoi la transparence compte
Certains produits « security score » utilisent un algorithme black-box. Vous obtenez un chiffre mais vous ne savez pas comment il a été calculé. Cela rend l'amélioration impossible — vous ne savez pas où travailler.
La formule monsys est entièrement documentée. Vous pouvez calculer exactement pourquoi votre score est 73 et pas 85. Cela en fait un outil de management, pas un chiffre marketing.
Exemple : votre Trust Score chute de 81 à 74 sur deux semaines. Vous ouvrez le breakdown :
- Patch hygiene : -9 points (trois nouvelles CVE Critical sur dépendances npm, EPSS > 0.3)
- Evidence continuity : stable
- Configuration drift : -2 points (un mismatch process DNA sur un serveur staging, 48h non résolu)
Votre action : corriger les trois dépendances npm et investiguer le serveur staging. Le score remonte ensuite.
Trust Score par agent : voir où ça déraille
Le total tenant est pour la salle du conseil. Pour l'opérateur vous voulez savoir : quel serveur fait baisser le score ? Cliquez sur un hôte pour voir son Trust Score individuel :
Par agent vous voyez les six composantes + les top 3 issues qui font baisser le score. Directement actionnable.
Pondération par centralité : tous les serveurs ne comptent pas pareil
Un contrôle en échec sur un load balancer qui traite tout le trafic prod est plus dangereux que le même contrôle sur un serveur de test que personne n'utilise.
Le Trust Score en tient compte via la betweenness centrality — un concept de théorie des graphes mesurant la centralité d'un nœud dans le réseau. Le CentralityRefreshWorker recalcule cela toutes les heures sur le graphe topologique :
- Un serveur chokepoint (load balancer, VPN gateway, database) avec haute centralité compte jusqu'à 2× plus dans le score
- Un serveur de test isolé avec faible centralité compte moins
Blast Radius par serveur : combien d'autres systèmes sont touchés si celui-ci est compromis ? Cette même centralité pondère le Trust Score.
Mode bootstrap : honnête pour les nouveaux tenants
Un nouveau tenant n'a par définition pas 12 mois de continuité d'audit. Cela ferait baisser artificiellement son score.
Le modèle bootstrap redistribue le poids de l'evidence continuity dans les trois premiers mois :
| Âge tenant | Poids evidence-continuity | Redistribué vers |
|---|---|---|
| < 30 jours | 0 % | Patch hygiene +5 %, agent health +5 % |
| 30-90 jours | 5 % | Réparti sur les autres composantes |
| ≥ 90 jours | 10 % (complet) | — |
Le dashboard affiche une bannière bleue tant que le mode bootstrap est actif.
Maintenance-aware : un downtime planifié n'est pas une faiblesse
Si vous planifiez une mise à jour kernel et qu'un serveur passe temporairement offline, vous ne voulez pas une chute de score. La composante agent health exclut explicitement les serveurs dans une fenêtre de maintenance active.
Downtime planifié ≠ malade. Votre reporting NIS2 ne baisse pas parce que vous avez fait une mise à jour.
Compliance-erosion : détecter la dégradation silencieuse
La conformité n'est pas statique. Un worker de backup qui crashe, un scanner de certificats qui échoue, un pipeline de logs qui se vide — ils ne génèrent pas d'alerte mais dégradent silencieusement votre posture conformité.
Le worker compliance-erosion prend un snapshot quotidien du compte d'evidence par contrôle. Quand un contrôle perd plus de 50 % de son evidence vs sept jours avant, une alerte est levée en catégorie compliance.erosion.
Par framework — NIS2, ISO 27001, CRA — vous voyez quels contrôles sont passing, partial ou failing. Le compliance-erosion est flaggé séparément.
Comment utiliser le Trust Score en salle de conseil
Le Trust Score n'est pas un verdict sécurité — c'est un KPI opérationnel. Vous l'utilisez comme MTTA/MTTR : comme point de mesure indiquant si vous bougez dans la bonne direction.
Reporting trimestriel : « Notre Trust Score est passé de 68 à 79 ce trimestre, porté par une amélioration en patch hygiene (+11 points) via l'implémentation d'auto-updates OS. Evidence continuity est maintenant à 100 % après 12 mois de monitoring ininterrompu. »
Contexte incident : « Après l'incident sécurité du 14 mars, notre Trust Score est tombé de 74 à 61. Nous avons corrigé les CVE ouvertes et résolu le configuration drift dans les deux semaines suivantes. Le score est maintenant à 78, plus haut qu'avant l'incident. »
Comparaison peer-to-peer (anonyme) : Non disponible dans monsys — nous ne publions pas de benchmarks. Mais l'échelle absolue (0-100) donne une référence interne : un score sous 60 signifie des manquements structurels nécessitant attention.
Reproductible via inputs_hash
Chaque snapshot Trust Score a un inputs_hash — un SHA256 sur toutes les mesures qui ont nourri le score. Cela rend le score reproductible : étant donné les mêmes inputs, la formule produit toujours le même chiffre. Un auditeur peut recalculer pourquoi le score était X un jour précis.
Ce que le Trust Score n'est pas
Pas une certification. Un score de 85 ne signifie pas que vous êtes conforme NIS2.
Pas un chiffre benchmark externe. Nous ne comparons pas votre score avec d'autres organisations.
Pas un verdict statique. Le score change toutes les 30 minutes.
Pas un remplacement d'analyse de risques. Le Trust Score est un KPI opérationnel, pas une analyse de risques stratégique.
Le Trust Score est documenté dans docs.monsys.ai/fr/security/trust-score. Cinq premiers serveurs gratuits : monsys.ai/fr/signup.