Comment la note A-E est calculée

Une lettre A-E est une affirmation forte, et une affirmation forte doit être auditable. Une note qui reste verte alors qu'un contrôle critique échoue est pire que pas de note. Pavois publie donc sa formule en entier, la calcule à l'identique dans le binaire CLI et dans le rapport HTML, et la fige derrière un test (go/internal/audit/audit_test.go + tools/validate_grade.py gardent les deux moteurs synchrones).

La formule

La note ne porte que sur les contrôles comptabilisés : tout ce qui est skipped ou non applicable sur la cible est exclu du numérateur comme du dénominateur, donc un contrôle qui ne s'applique pas n'aide ni ne pénalise jamais la note.

On part de 100 points et on retranche une pénalité par contrôle en échec, pondérée par la sévérité :

• critique : 25 points chacun
• haute : 15 points chacun
• moyenne : 6 points chacun
• basse : 3 points chacun

La perte de chaque bande de sévérité est plafonnée, pour qu'une longue traîne de findings de faible sévérité ne coule pas la note à elle seule :

• perte haute plafonnée à 60
• perte moyenne plafonnée à 20
• perte basse plafonnée à 10
• la perte critique n'est jamais plafonnée

La règle d'échec critique

C'est elle qui défait l'objection « un B à 82 % cache un désastre ». Tout échec critique, même unique, plafonne le score à 30 points (note E), quel que soit le nombre d'autres contrôles réussis. Un hôte avec une faille critique n'est pas un hôte B, quel que soit son pourcentage.

Les bandes

Exemples chiffrés

1, un hôte presque propre. 2 moyens en échec, 1 bas en échec, le reste passe : 100 - (2x6 + 1x3) = 85, note B.

2, l'attaque du critique caché. 1 critique échoue (login root réactivé par un drop-in) tandis que 120 contrôles de faible sévérité passent. Un taux de réussite naïf afficherait ~99 % et parlerait de A. Pavois ne score pas un taux de réussite : le score soustractif est déjà 100 - 25 = 75, puis la règle d'échec critique le plafonne à 30, note E. Deux raisons indépendantes pour lesquelles la faille critique ne peut pas se cacher derrière un mur de vert.

3, la mort par les hauts. 5 contrôles de sévérité haute échouent, rien de critique : perte brute 5x15 = 75, plafonnée à 60, score 40, note D.

La note en JSON

--format json émet la note et les comptes qui l'ont produite, pour que la CI puisse s'en servir comme garde-fou et que vous puissiez la recalculer. Un scan avec un critique et trois échecs moindres (score soustractif 100 - 25 - 12 - 3 = 60, puis le plafond critique le ramène à 30) :

pavois scan local --profile profiles/linux/debian12 --format json --sudo

{
  "grade": "E",
  "points": 30,
  "passed": 146,
  "total": 150,
  "runtime_qualified": false,
  "qualified_passes": 0,
  "counts": { "critical": 1, "high": 0, "medium": 2, "low": 1 },
  "posture": { "remediable_grade": "C", "remediable_passed": 130, "remediable_total": 138 }
}

Les mêmes nombres pilotent la ligne de synthèse du terminal et le rapport HTML, et alimentent l'export de preuves JSON (l'OSCAL assessment-results est en roadmap).

Ce que la note n'encode PAS encore

L'honnêteté va dans les deux sens. Deux limites à garder en tête :

• La sévérité commande le plafond, donc la cotation d'un contrôle compte. Pavois note aujourd'hui 13 contrôles en critique (login root distant, mots de passe SSH vides). La sévérité est dérivée de l'impact de chaque contrôle (impact >= 0.9 vaut critique), et les sévérités sont ouvertes à la revue : si vous estimez qu'un contrôle mérite, dans votre contexte, de forcer un E (par exemple la journalisation d'audit désactivée sur un hôte régulé), sa cotation est le levier.
• La note score la preuve que chaque contrôle collecte, avec les réserves de son type de preuve. Un contrôle effective-runtime réussi prouve l'état en cours d'exécution, pas que le réglage survit à un redémarrage. Chaque fiche affiche une matrice « un PASS prouve » par contrôle (actif maintenant / sur disque / survit au reboot) dérivée du type de preuve et exportée dans le catalogue OSCAL (proves-running, proves-persistent, proves-reboot-survivable). La note pondère cela : un PASS runtime-only dont la persistance n'est pas prouvée ne compte pas comme un PASS plein, il plafonne donc la lettre (un A net est refusé et la note est affichée runtime-qualifiée, c'est-à-dire plafonnée à B), sans changer les points pilotés par les échecs. pavois harden apply --reboot --scan re-scanne après un vrai redémarrage : un PASS y est alors reboot-proven. Voir le verdict qualifié pour le modèle complet.

La formule est volontairement simple et publique. Si elle change un jour, le test figé casse exprès et le changement est tracé : une note qu'on peut recalculer à la main est la seule digne de confiance.

Posture par classe de remédiation

La note traite chaque contrôle applicable de la même façon, mais tout échec n'est pas corrigeable sur un hôte en cours d'exécution : une partition /var séparée exige une réinstallation, et un CONFIG_* noyau durci exige un noyau recompilé. Chaque scan publie donc une ventilation par classe de remédiation, auto, manual, dangerous, install-time et kernel-build, plus une note de posture remédiable : la même formule A-E recalculée sur les seuls contrôles corrigeables sur cet hôte (elle exclut install-time et kernel-build).

Cela recadre un résultat honnêtement. Sur une Debian 12 fraîchement durcie, sur 68 échecs restants 46 sont install-time (24) plus kernel-build (22) : seuls 22 sont réellement remédiables sans réinstaller ni recompiler le noyau. La ventilation est affichée sous la note, émise dans --format json sous posture, et consignée dans le manifeste du bundle de preuve.

FAQ

Un hôte avec un seul échec critique peut-il avoir un B ? Non. Un seul échec critique plafonne le score à 30 points, note E, quel que soit le nombre d'autres contrôles réussis. C'est tout l'objet de la règle d'échec critique.

Pourquoi un PASS runtime-only est-il plafonné à B ? Parce qu'il prouve que la valeur est en vigueur maintenant, pas qu'elle survit à un redémarrage. Un A net exige une preuve de persistance ; un scan runtime-qualifié est plafonné à B jusqu'à ce qu'un re-scan après redémarrage le confirme.

Puis-je recalculer la note moi-même ? Oui. Partez de 100, retranchez les pénalités par sévérité plafonnées, appliquez le plafond d'échec critique, lisez la bande. La formule est figée derrière un test pour que CLI et HTML ne divergent jamais en silence.

Pourquoi ma note est-elle C pour des choses que je ne peux pas corriger sans réinstaller ? Elle ne l'est pas : à côté de la note globale, pavois publie une note de posture remédiable qui exclut les contrôles install-time et kernel-build, pour montrer ce qui est réellement corrigeable sur cet hôte.