Sections du handbook▾
Fondations
Comprendre les menaces qui pèsent sur un hôte LinuxPourquoi on durcitLes principes de défense derrière chaque règleConfiguration effective : la vérité qu'aucun fichier ne contientLes normes que Pavois cartographieModèle d'identifiant de contrôle SOCLEPreuves & exportsComment la note A-E est calculéeCe qu'un PASS prouve : le verdict qualifiéModèle de confiance du bundle de preuveSOCLE, n'est-ce pas votre propre norme ? (gouvernance & la question de la circularité)Ce que Pavois couvre, et ce qu'il ne couvre pasDomaines
Durcir SSHDurcir PAMContrôle d'accès obligatoire (SELinux / AppArmor)Durcir le pare-feu localDurcir sudoPermissions et propriété des fichiersDurcir les montages et le système de fichiersDurcir les modules noyauDurcir le noyau et le réseau avec sysctlJournalisation d'audit avec auditdDurcir la journalisation avec journald et rsyslogDurcir les services systemdHygiène des paquetsDurcir le chargeur d'amorçage (GRUB)Synchroniser l'heureBannières de connexion et MOTDContrôler l'accès à cron et atDurcir le bureau GNOME (dconf)Outillage
Annuler un durcissement : les points de restaurationExploiter Pavois : privilèges, air-gap, durée, dérogationsLancer Pavois en CI (GitHub Actions)État des fonctionnalités : livré, partiel, roadmapGouvernance : licence, versionnement, provenance, sécuritéGouvernance : licence, versionnement, provenance, sécurité
Revu le
Qui maintient ce projet, sous quelle licence, comment la base de règles est versionnée, d'où vient un mapping comme CIS 5.1.20, ce qui se passe quand CIS publie un nouveau benchmark, et comment signaler une vulnérabilité.
Un outil qui vous demande de croire son verdict vous doit les réponses de cette page. Aucune n'est flatteuse, et toutes sont vraies.
Licence
Apache License 2.0. Le code, la base de règles, le bundle OSCAL et ce site.
Les définitions de contrôles ont été amorcées depuis ComplianceAsCode/SSG (BSD-3), et cet héritage est crédité sur la page d'attribution. Les numéros de référence des normes eux-mêmes (CIS 5.1.20, ANSSI R33, PCI 2.2.6) sont des faits, pas du contenu : Pavois pointe vers eux et ne reproduit pas la prose des benchmarks, qui appartient respectivement à CIS, au PCI SSC, à la DISA et au NIST.
Qui maintient ce projet
Une seule personne. C'est un fait que vous devez peser, et c'est pourquoi le chapitre de gouvernance SOCLE dit exactement la même chose de la nomenclature. Un mainteneur unique, cela veut dire : rapide, cohérent, et un facteur d'autobus de un. Jugez en conséquence.
Comment la base de règles est versionnée
La baseline porte un nom, un identifiant et une version sémantique, en un seul endroit (docs/reference/baseline.yml), et pavois oscal en tamponne le catalogue OSCAL. Aujourd'hui : pavois-baseline 0.1.0.
| Changement | Incrément |
|---|---|
| un identifiant de contrôle est retiré ou renommé | MAJEUR |
| des contrôles ou des mappings sont ajoutés | MINEUR |
| une correction qui ne change ni identifiant ni mapping | CORRECTIF |
Un identifiant de contrôle est un contrat : il apparaît dans vos rapports, votre SARIF, vos paquets de preuve. En retirer un casse un consommateur, d'où l'incrément MAJEUR, et d'où la trace replaces: que gardent les doublons fusionnés.
D'où vient un mapping, et comment le vérifier
C'est la question que posera un auditeur, alors voici la chaîne honnête :
- Les numéros de référence ont été extraits, une fois, du datastream SSG de chaque OS (
ssg-<os>-ds.xml), c'est-à-dire la source même qu'évalue OpenSCAP. Ils n'ont pas été tapés de mémoire, et n'ont jamais été inventés. - Chaque mapping CIS est recoupé avec une SECONDE source indépendante : le rôle CIS d'
ansible-lockdownpour le même OS (tools/cross_validate.py). Un contrôle dont le numéro CIS n'apparaît que dans une source sur deux est signalé, pas conservé en silence. - Trois OS n'ont pas de benchmark CIS propre, donc leurs numéros CIS ne peuvent pas être recoupés avec une source du même OS : Fedora et RHEL 10 héritent du mapping RHEL 9, Ubuntu 26.04 hérite d'Ubuntu 24.04. Cet héritage est déclaré dans le tableau des benchmarks par OS, et marqué « hérité » sur ces OS plutôt que présenté comme un mapping natif. C'est un défaut raisonnable (les benchmarks RHEL 10 et Ubuntu 26.04 n'existaient pas à la rédaction) ; ce n'est pas la même preuve qu'une version épinglée et recoupée, et le site ne prétend jamais le contraire.
- La base de règles est désormais la source de vérité, maintenue directement. SSG n'est plus l'amont : c'est l'un des deux témoins.
Ce que cela ne vous donne pas : un audit indépendant des 2 729 références de normes. Personne ne l'a fait. Si vous engagez une certification sur un mapping précis, vérifiez celui-là contre le benchmark que vous certifiez, et s'il est faux, dites-le nous : un mapping faux est le pire bug que ce projet puisse livrer.
Ce qui se passe quand CIS publie un nouveau benchmark
La version du benchmark est épinglée par OS, et publiée en entier dans le tableau des benchmarks par OS (Debian 12 → CIS 1.1.0, RHEL 9 → CIS 2.0.0, et les trois OS hérités signalés comme tels). Quand une nouvelle version paraît :
- le datastream est récupéré à nouveau (
tools/fetch_datastreams.sh) ; - l'écart de couverture est calculé (quelles règles du nouveau benchmark Pavois ne couvre pas, et pourquoi) ;
- les mappings sont ré-ancrés, et la base prend un incrément MINEUR.
La même règle vaut pour une norme qui se renumérote : NIST 800-171 est épinglé sur la Rev 2 sur ce site, explicitement. Deux raisons, une pratique et une qui pèse davantage : la Rev 3 renumérote les exigences, donc le ré-ancrage est une passe complète de recoupement, pas un chercher-remplacer ; et, surtout, la dérogation de classe DFARS de mai 2024 maintient le DFARS 252.204-7012 et les évaluations CMMC sur la Rev 2, si bien qu'un évaluateur en 2026 mesure toujours contre la Rev 2. L'épingler n'est pas un retard, c'est suivre la révision que le contrat cite réellement. Un mapping vers une révision non nommée ne vaut rien ; un mapping vers la révision nommée qu'utilise votre auditeur est correct.
Releases
Les releases sont publiées sur le dépôt, et c'est de là que se tirent les binaires. Chacune porte un checksums.txt, un SBOM CycloneDX, une attestation de provenance de build SLSA et une signature Cosign sans clé : l'intégrité et l'origine sont donc vérifiables par quelqu'un qui n'a aucun accès à ce projet. La page d'installation donne les deux commandes.
Les releases sont suivies dans le CHANGELOG, et la version de la base de règles bouge avec elles selon les règles ci-dessus. La version de l'outil et celle de la baseline sont volontairement distinctes : un correctif du scanner n'est pas une modification de la norme qu'il évalue, et un rapport cite la version de la baseline et son empreinte de contenu, pour qu'un résultat archivé reste interprétable après que l'outil a évolué.
Signaler une vulnérabilité
En privé, via le signalement privé de GitHub, jamais dans une issue publique. Le SECURITY.md du dépôt donne les détails.
Une précision qui fait gagner du temps à tout le monde : une faille dans l'OS audité n'est pas une vulnérabilité de Pavois, pas plus qu'un défaut dans un datastream tiers ; signalez-les en amont. Une vulnérabilité de Pavois, c'est une vulnérabilité dans Pavois : une fuite d'identifiants, une injection de commande via un champ de règle, une remédiation qui ouvre un trou.
FAQ
La base de règles est-elle auditée indépendamment ? Non. Elle est recoupée avec deux sources amont, ce qui n'est pas la même chose, et cette page ne prétendra pas le contraire.
Et si un mapping est faux ? Ouvrez une issue avec l'identifiant du contrôle et la clause du benchmark. Un mapping faux est un bug de correction, pas une affaire d'opinion, et il sera traité comme tel.
Puis-je utiliser Pavois commercialement ? Oui : Apache 2.0. Les benchmarks vers lesquels il pointe ont leurs propres conditions, qui regardent leurs éditeurs et ne sont pas affectées par cette licence.
Qui décide de ce que veut dire un contrôle ? La base de règles, et elle est publique, dans un seul fichier, dans un format lisible. Si vous n'êtes pas d'accord avec un contrôle, vous pouvez lire exactement ce qu'il vérifie et ce qu'il changerait sur votre hôte, avant qu'il ne tourne.
À retenir
- Apache 2.0, un mainteneur, un facteur d'autobus de un. Pesez-le.
- La base de règles est versionnée sémantiquement, et un identifiant de contrôle est un contrat : en retirer un est un changement MAJEUR.
- Chaque mapping CIS a été extrait du datastream SSG et recoupé avec ansible-lockdown. Il n'a jamais été audité indépendamment, et cette page le dit.
- Les versions de benchmark sont épinglées et affichées par OS (trois OS sans benchmark héritent de celui d'un frère, signalé comme tel), et une renumérotation (NIST 800-171 Rev 3) est un ré-ancrage complet, pas un renommage.