Les plateformes Linux que Pavois a réellement prouvées
9 systèmes sur 9 ont traversé une campagne complète sur VM vierge, avec la base de règles telle qu’elle est aujourd’hui. Chaque ligne est générée depuis ces campagnes par le contrôle qui verrouille une release : un système que personne n’a prouvé ne peut pas s’afficher comme prouvé.
| Plateforme | État | Dernière campagne | Note avant → après | Pavois |
|---|---|---|---|---|
| Debian 12debian 12.15 | VERIFIED | 2026-09-21il y a 0 j · poste | E→D509/542 (94%) | dev |
| Debian 13debian 13.7 | VERIFIED | 2026-09-21il y a 0 j · poste | E→D512/544 (94%) | dev |
| Ubuntu 22.04ubuntu 22.04 | VERIFIED | 2026-09-21il y a 0 j · poste | E→D488/526 (93%) | dev |
| Ubuntu 24.04ubuntu 24.04 | VERIFIED | 2026-09-21il y a 0 j · poste | E→D532/567 (94%) | dev |
| Ubuntu 26.04ubuntu 26.04 | VERIFIED | 2026-09-21il y a 0 j · poste | E→E534/570 (94%) | dev |
| RHEL 8 / Rocky 8 / AlmaLinux 8almalinux 8.10 | VERIFIED | 2026-09-21il y a 0 j · poste | E→E535/600 (89%) | dev |
| RHEL 9 / Rocky 9 / AlmaLinux 9almalinux 9.8 | VERIFIED | 2026-09-21il y a 0 j · poste | E→D580/626 (93%) | dev |
| RHEL 10 / Rocky 10 / AlmaLinux 10almalinux 10.2 | VERIFIED | 2026-09-21il y a 0 j · poste | E→E549/605 (91%) | dev |
| Fedorafedora 43 | VERIFIED | 2026-09-21il y a 0 j · poste | E→E569/622 (91%) | dev |
Fenêtre de fraîcheur : 30 jours. Au-delà, une campagne passée bascule en STALE même si la base de règles n’a pas bougé : ce sont les paquets et le noyau de la cible qui ont bougé, et aucune empreinte de notre côté ne peut le voir.
Le corpus de Fedora ne vise aucun numéro de version : le rapport de normes le documente, aucun benchmark CIS n’existe pour Fedora et ses mappings sont hérités de RHEL 9. Un verdict y porte donc sur la version effectivement mesurée, celle qui est nommée sous le libellé, et pas sur la distribution entière.
Ce que chaque état veut dire
La dernière campagne est passée, sur cette base de règles exacte, dans la fenêtre de fraîcheur.
La dernière campagne a tourné et une étape requise a échoué. Un run vert plus ancien ne l’annule pas.
Elle est passée, mais sur une autre base de règles, ou il y a plus longtemps que la fenêtre ne l’autorise.
Une campagne existe et ne dit pas ce qu’elle a prouvé : interrompue, ou muette sur la base de règles mesurée.
Le corpus de règles existe, curé et validé statiquement. Aucune campagne sur VM vierge n’a jamais tourné. Pas un PASS plus faible : une autre affirmation.
Rien sur quoi s’appuyer. Une preuve absente ne se lit jamais comme un succès.
Pourquoi cette page existe
Pour un outil de durcissement, la cadence des releases est un mauvais signal de maturité. Un bon signal, c’est ce que les campagnes ont réellement démontré, machine par machine, et ce que personne n’a encore démontré. Les deux se publient ici.
Une campagne, c’est une VM vierge créée pour l’occasion : scan de la machine d’origine, plan, application, redémarrage, deuxième passe replanifiée depuis l’état courant, redémarrage, nouveau scan, diff, puis un bundle de preuves qui est vérifié. Un conteneur ne peut pas la remplacer : 259 des contrôles n’ont aucun sens sans un noyau à soi.
La donnée brute derrière cette page est servie telle quelle, débarrassée de toute identité machine : platform-matrix.json.