Conformité Linux effective
Pavois audite la configuration que vos services appliquent réellement, sshd -T, sysctl, systemctl show, pas seulement les fichiers sur disque. Il capte les Include et drop-ins que les scanners de fichiers ratent, note le résultat A:E, et remédie en code.
pavois scan local --sudoLes scanners lisent le fichier.
Les attaquants lisent le drop-in.
Une surcharge permissive dans un répertoire .d annule en silence une config principale plus stricte. Lisez le fichier et vous obtenez un feu vert mensonger. Lisez l’état effectif et vous obtenez la vérité.
→
PermitRootLogin no→
permitrootlogin yesLe fichier dit non. Le démon dit oui. Partout où un service résout sa propre config, sshd -T, sysctl, systemctl, auditctl, seule la lecture effective attrape la surcharge. Chaque contrôle indique la preuve sur laquelle il s’appuie : on sait toujours ce qu’un PASS démontre.
Plus sur la configuration effective, la vérité qu’aucun fichier ne contient →
D’une image cloud à un hôte durci,
en deux minutes.
Une VM Debian 13, et chaque commande a réellement tourné. Pavois interroge le système en marche et le note E. Il établit ensuite un plan, où chaque écart est à activer et rien ne se fait dans votre dos. Entre les deux prises, l’hôte est durci pour de vrai, et la même commande est relancée.
Dans cet enregistrement : 258 contrôles sur 523 conformes avant, 516 sur 560 après, 0 critique et 0 élevé restants, et la note A sur tout ce qu’une remédiation peut atteindre (469/470). La note globale reste C parce que 44 écarts exigent une partition séparée ou un noyau recompilé, et Pavois les nomme au lieu de les sortir du dénominateur. Le durcissement lui-même, trois passes et trois redémarrages, est hors caméra.
Auditer, noter, durcir, prouver.
Une boucle consciente de l’état, pas un script aveugle. Rien ne change sans votre accord, et chaque correctif est prouvé contre un nouveau scan.
Auditer
Résolvez la config effective de n’importe quelle cible et notez-la A:E contre la norme choisie.
pavois scan <target>Noter
Un rapport A:E chapitré, par norme. SARIF, JUnit, HTML, et des codes de sortie pour la CI.
--format sarif --fail-under 80Remédier
Planifiez les correctifs, activez apply par règle, convergez un run Chef natif. Pas de bash.
pavois harden plan localProuver
Re-scannez après un vrai reboot : un correctif qui survit est prouvé reboot-proof. Le verdict est honnête, un PASS runtime-only ne décroche pas un A net.
pavois harden apply --reboot --scanPavois construit une image conforme.
Il ne rattrape pas un hôte legacy.
Certains écarts ne se ferment par aucune commande : un /var/log séparé se décide au partitionnement du disque, et un noyau sans les options KSPP ne peut pas les acquérir à chaud. Ces contrôles portent les classes install-time et kernel-build parce qu’aucun apply ne peut les fermer sur une machine en production. Pointez Pavois sur un hôte legacy et il vous dit quand même la vérité, y compris quelle part des écarts exige une reconstruction plutôt qu’une commande.
Fait pour
- Construire une image golden : installation neuve, recette de partitionnement, noyau KSPP, apply convergé, puis on la fige.
- Surveiller la dérive d’un parc : scanner les hôtes livrés, attraper le drop-in ajouté mardi dernier.
- Prouver une posture : rapport chapitré, paquet de preuve signé, export OSCAL exploitable par un auditeur.
- Verrouiller un pipeline :
--fail-undertransforme la note en check CI sur l’image que vous vous apprêtez à livrer.
Pas fait pour
- Un hôte de production de dix ans que vous ne pouvez ni repartitionner ni redémarrer. Il sera audité honnêtement, et une part de ses écarts restera ouverte.
- Un script one-shot qui applique tout aveuglément. Rien ne change tant que vous n’avez pas activé
apply, règle par règle, volontairement. - Un tampon de certification. Pavois produit la preuve ; c’est l’auditeur qui rend le verdict.
- Un parc non-Linux. 9 familles d’OS Linux aujourd’hui, rien d’autre.
Opérer Pavois : les quatre questions qui décident s’il est fait pour vous →
Un contrôle, chaque mapping applicable.
Une seule assertion de config effective porte tous ses mappings applicables. Un contrôle neutre, chaque norme qui la couvre, jamais de règle dupliquée, jamais de résultat divergent.
Bâti sur SOCLE, une norme de durcissement, tous les outils.
Les contrôles de Pavois viennent de SOCLE : une référence neutre et versionnée qui relie chaque exigence à CIS, ANSSI-BP-028, NIST, PCI-DSS et STIG là où chacune s’applique, un seul check fait foi pour chaque mapping qu’il porte.
Chaque contrôle porte un ID stable, SOCLE-<domaine>-<famille>-<n>, sous les domaines RUN (runtime) et CLD (posture hôte) de SOCLE. Consommez-le en JSON ou OSCAL, versionnez-le, testez-le.
Trois façons d’entrer.
Durcir un serveur Linux
Scanner l’hôte, comprendre les écarts, appliquer la remédiation, vérifier l’état effectif.
Quickstart →Auditeur / GRCProuver une conformité
Le parcours auditeur : rapport, verdict, score, bundle de preuve signé, modèle de confiance, exports OSCAL et benchmark.
Parcours auditeur →RSSI / plateformeStandardiser le durcissement
Des contrôles SOCLE versionnés et des preuves répétables sur tout le parc.
Parcourir les contrôles →Natif, sans agent, prêt pour la CI.
CINC / InSpec natif
Lance cinc-auditor en natif sur des cibles local, SSH ou docker. Aucun agent, votre propre ~/.ssh/config.
Effectif par conception
L’état résolu, sshd -T, sysctl -a, systemctl show, auditctl -l, jamais le texte d’un fichier.
Note A:E
Un rapport chapitré, une vue par norme, et un seuil --fail-under qui transforme la note en check CI. Comment la note est calculée →
Verdict qualifié
Un PASS dit ce qu’il prouve : actif maintenant vs survit au reboot. Un PASS runtime-only (un sysctl live non épinglé sur disque) est qualifié, il plafonne la note sous A tant que la persistance n’est pas prouvée. Ce qu’un PASS prouve →
Durcir en code
Planifiez, éditez, appliquez. Une convergence Chef native, opt-in par règle, avec dry-run, jamais un script shell aveugle.
Sortie CI-native
SARIF pour le code scanning, JUnit pour les rapports de test, CSV/HTML/JSON, et des codes de sortie exploitables.
Secrets protégés
Les mots de passe atteignent le moteur par stdin seulement, rien ne fuit via ps, /proc ou l’historique shell.
Auditez ce que vos serveurs
appliquent réellement.
Un CLI Go qui pilote CINC Auditor natif. Pointez-le sur un hôte et lisez la vérité.
pavois scan local --sudo