Pavois vs OpenSCAP, Lynis et CIS-CAT : benchmark de configuration effective Linux

En un coup d’œil

Aucun de ces outils n’est mauvais, OpenSCAP/SSG est notamment une pile mature, standard et largement supportée, et Pavois recoupe même ses mappings contre SSG. Le point est plus étroit et ne vaut que pour les contrôles résolus par un service : quand un drop-in surcharge le fichier principal, une sonde OVAL pointée sur le fichier le rate, sauf à avoir été écrite pour le chemin résolu, en pratique les outils basés fichier ratent donc ce cas, là où une lecture effective l’attrape. Pour les contrôles d’inventaire, de paquets ou de système de fichiers, l’écart se referme largement.

Quel outil, quand ?

Réponse courte, par objectif :

• Utilisez Pavois quand vous devez auditer la configuration effective (drop-ins, Include, surcharges runtime résolues), un contrôle neutre mappé à plusieurs normes d’un coup, un rapport noté A:E, et le durcir-en-code opt-in avec un bundle de preuve signé.
• Prenez OpenSCAP / SSG quand vous voulez une pile SCAP officielle et mature avec XCCDF/ARF largement supportés et des datastreams fournis par l’éditeur, surtout là où la couverture fichier-et-OVAL suffit.
• Prenez Lynis quand vous voulez une passe de durcissement rapide et sans installation et un indice heuristique, sans besoin de mapping de norme.
• Prenez CIS-CAT quand vous avez besoin d’une attestation CIS officielle (CIS SecureSuite) et que le numéro de benchmark certifié est ce que votre auditeur exige.

Ils se composent : Pavois recoupe même ses mappings contre SSG. L’avantage de Pavois est étroit et précis, les contrôles résolus par un service ; pour l’inventaire, les paquets et le système de fichiers, les outils convergent largement.

Par type de preuve

Un tableau outil-contre-outil flatte celui qui l’a écrit. La coupe honnête, c’est par le type de preuve qu’un contrôle exige, lisez une colonne de haut en bas, pas une ligne en travers :

Pavois mène sur les deux lignes d’état résolu, c’est toute sa raison d’être, et est à égalité (inventaire, fichiers) ou réellement derrière (autorité de norme officielle, maturité de remédiation, écosystème) sur le reste. Choisissez l’outil selon la preuve dont votre contrôle a besoin ; pour une attestation CIS réglementée, CIS-CAT garde son intérêt, pour un pipeline SCAP large, OpenSCAP. Ils se composent.

Un benchmark reproductible

Nous avons joué le cas drop-in canonique sur une VM Debian 12 neuve (provision → snapshot → restore, identique à chaque run) : le sshd_config principal dit PermitRootLogin no, un drop-in dans sshd_config.d/ dit yes, la valeur qui s'applique réellement. Outils tels que livrés sur Debian 12 :

L'écart est réel et étroit, et nous l'énonçons honnêtement : Lynis résout le drop-in comme Pavois (il exécute sshd -T), mais seulement comme indice non normatif ; la règle d'OpenSCAP/SSG sondée sur le fichier le rate complètement ; Pavois le résout et le mappe à chaque norme applicable qu'il porte. Reproduisez-le avec tools/benchmark/effective-config-bench.sh <user@host> <clé> <ssg-debian12-ds.xml>, re-run depuis un snapshot identique à chaque fois.

La largeur compte aussi : on compte donc les règles que chaque outil implémente par gravité (ce n'est pas une métrique de gagnant : plus de règles n'est pas mieux, et le périmètre diffère). Pour Debian 12 :

SSG porte plus de règles brutes et est plus mature ; Pavois ajoute un palier critique que le modèle SSG n'a pas, chaque contrôle déclare son type de preuve et porte chaque mapping de norme applicable, et Lynis n'a aucune gravité par règle. Le cas drop-in porte sur le type de preuve ; cette table montre que Pavois est complet, pas un tour unique.

La comparaison est livrée comme outil : tools/coverage_gap.py mappe les contrôles Pavois aux règles SSG (via les tags ssg:) et trie le gap avec les verdicts d'oscap sur une cible réelle. Les 315 règles SSG brutes que Pavois ne mappe pas tombent à 87 applicables et en échec une fois les N/A retirées (139 sont notapplicable sur Debian, ex. SELinux ; 15 ne sont pas auto-vérifiées ; 74 passent déjà). Symétriquement, Pavois s'applique à 523 de ses 607 contrôles Debian 12 sur un hôte frais (84 N/A). Les comptes bruts de catalogue surévaluent des deux côtés ; le gap honnête et applicable est de 87, et --create-issues le verse en backlog (les contrôles cassés deviennent des issues bug). Méthode complète, commandes exactes, versions des outils et le CSV par règle : docs/benchmark.

OpenSCAP (SCAP / OVAL)

OpenSCAP est l’implémentation de référence de SCAP, le format NIST liant XCCDF (benchmark & règles), OVAL (les checks bas niveau) et CPE (identification de plateforme). Il est vraiment solide : le SCAP Security Guide fournit des datastreams SCAP (XCCDF/OVAL) mappant les règles à CIS, ANSSI BP-028, DISA STIG, PCI-DSS et NIST 800-53, il émet des remédiations bash et Ansible, et son rapport HTML est la mise en page que le renderer de Pavois vise à égaler.

La limite structurelle tient à la façon dont OVAL fonctionne : la plupart des checks inspectent des fichiers sur disque (textfilecontent54 grep un fichier). Un check OVAL pointé sur sshd_config ne voit jamais un drop-in dans sshd_config.d/, il lit le défaut et affiche PASS alors que le drop-in a réactivé PermitRootLogin yes. Pavois garde le rapport SCAP chapitré et multi-normes mais remplace le moteur de lecture de fichiers par un moteur effective-config. Il n’exécute jamais oscap comme moteur, seulement comme référence visuelle de mise en page.

Lynis

Lynis est un script shell unique, sans agent ni dépendance, qui audite 60+ sous-systèmes (462 tests en v3.0.8, la version livrée par Debian 12 ; la 3.1.x est la version courante) en minutes et émet des suggestions, avertissements et un hardening index (0:100). Comme triage rapide de première passe et source d’inspiration, il est excellent : il dit où regarder.

Mais il est heuristique, pas normatif. Ses checks encodent des opinions de bonnes pratiques ; ils ne sont pas mappés à une norme publiée, et le hardening index est un nombre propre à Lynis, pas un verdict de conformité qu’un auditeur accepte. Pour SSH il exécute en réalité sshd -T (comme Pavois), donc il résout les drop-ins là ; il ne grep le fichier brut que pour quelques checks (ex. AllowUsers) et pour d’autres sous-systèmes. Sa limite décisive est d’être heuristique, pas un angle mort sur les drop-ins : utilise Lynis pour repérer l’évident et motiver les gains rapides, utilise Pavois pour la passe rigoureuse, mappée aux normes, auditable. Fabriquer une référence lynis_X à la place d’un vrai contrôle CIS ou BP-028 serait une erreur, Pavois ne le fait jamais.

CIS-CAT

CIS-CAT est l’outil officiel d’évaluation de configuration de CIS, un scanner Java qui note un hôte contre un CIS Benchmark. Le hic est le modèle d’adhésion : CIS-CAT Lite est gratuit mais ne couvre qu’une poignée de benchmarks (Windows 10, Chrome, Ubuntu) ; le CIS-CAT Pro Assessor complet requiert l’adhésion payante CIS SecureSuite. Le seul outil officiel pour s’auto-évaluer contre une norme publiquement publiée est donc derrière un paywall : ce n'est pas un moteur de règles ouvert, et l'assesseur complet exige l'adhésion CIS SecureSuite.

Pavois n’est pas CIS-CAT et n’embarque aucun contenu CIS, il porte sa propre base ouverte où les numéros de recommandation CIS sont des tags sur des IDs neutres et stables (473 contrôles portent un mapping cis: explicite). Choisis CIS dans le rapport, Niveau 1 ou 2, et Pavois recompose une vue CIS, ouvertement, contre l’état effectif, sans palier d’adhésion.

Outils de remédiation

Le scan trouve l'écart ; la remédiation le ferme. Là encore le paysage diffère, et l'angle de Pavois est que le même corpus qui audite corrige aussi, en une seule boucle.

ansible-lockdown (les rôles CIS/STIG de MindPoint Group, à ne pas confondre avec les collections de durcissement dev-sec.io) est mature et répandu, Pavois cross-valide même ses mappings contre lui. Mais il applique des fichiers et tourne en playbook découplé de l'audit : rien ne prouve que le démon en cours est devenu conforme. OpenSCAP émet du bash/Ansible directement depuis le benchmark XCCDF, orienté fichier, et tu fais confiance au correctif du benchmark.

Pavois ferme la boucle : pavois harden plan lit l'état réel, tu actives apply par règle, une convergence Chef native s'applique, et pavois diff re-scanne la config effective pour prouver que chaque écart est fermé et que rien n'a régressé. Un correctif invérifiable n'est pas une preuve.

Quand Pavois n’est pas le bon outil

Pavois est fort sur les contrôles d'état résolu et la remédiation-as-code, mais il n'est pas la réponse à tout, et le dire fait partie de l'honnêteté :

• Auto-évaluation CIS officielle pour une certification : CIS-CAT reste l'autorité ; les tags cis: de Pavois sont des références croisées, pas des attestations.
• Pipelines SCAP natifs (XCCDF/OVAL/ARF, outillage entreprise large) : OpenSCAP/SSG est plus mature.
• Triage rapide de première passe : Lynis est plus rapide et plus simple.
• Catalogues de remédiation matures : SSG et ansible-lockdown sont plus anciens et plus larges.
• Et harden peut être plus dangereux : il applique de vrais changements, certains risqués (un kernel.modules_disabled=1 a déjà brické un boot EFI), donc les correctifs risqués sont livrés en opt-in, pas auto-exécutés, et une campagne reboot prouve le résultat.

Choisissez l'outil selon la preuve qu'un contrôle exige et le travail à faire ; ils se composent.

Le moteur : CINC Auditor / InSpec

Pavois est 100% CINC Auditor, le build libre et sans marque de Chef InSpec. Un contrôle décrit l’état attendu d’une ressource en langage lisible ; CINC l’exécute contre la configuration effective. Il tourne en binaire natif : un scan d’hôte (local://) et un scan SSH (ssh://) utilisent ton propre ~/.ssh/config, ton routage et ton user, le conteneur n’est qu’un repli zéro-install. Les commandes effective-config exigent du privilège : Pavois passe --sudo à CINC, par stdin, jamais en ligne de commande.