Preuves & exports

Quelles preuves Pavois collecte

Pour chaque contrôle, un scan Pavois enregistre le check de preuve exécuté et son type de preuve (p.ex. un check effective-runtime comme sshd -T | grep -i permitrootlogin), la valeur observée, le verdict (conforme / écart / manuel / non-applicable), les normes mappées par le contrôle, et le contexte de cible (hôte, OS, version de profil). C'est la matière première d'une piste d'audit.

Ce qu'un PASS prouve : les quatre types de preuve

Tous les checks ne prouvent pas la même chose, et Pavois l'étiquette sur chaque contrôle (voir types de preuve) :

Le verdict d'un contrôle est distinct de son type de preuve : il peut être conforme, écart, manuel (requiert un jugement humain, Pavois fournit la question, pas le verdict) ou non-applicable. Le cas phare reste vrai pour les contrôles effective-runtime : un fichier peut paraître conforme alors qu'un drop-in réactive ce qu'il interdit, et c'est la lecture effective qui tient. Pavois indique le type de chaque contrôle, pour que l'auditeur sache ce qu'un PASS établit ou non.

Formats de rapport

pavois scan écrit le même résultat sous plusieurs formes (--format) :

• HTML : un rapport chapitré par norme, noté A-E, pour les humains.
• JSON : le résultat complet plus le bloc de note, pour l'outillage.
• SARIF : pour les tableaux de code-scanning.
• JUnit : pour les rapports de test CI.
• CSV : pour tableurs et croisements.

pavois scan local --sudo --format html
pavois scan admin@server1 --format sarif --fail-under 80

Le code de sortie (--fail-under N) transforme la note en gate CI. Le JSON porte la note et les comptes plus un tableau findings, chaque entrée contenant l'id du contrôle, son type de preuve, la valeur observée, le verdict et les correspondances de normes :

{
  "grade": "B", "points": 84, "passed": 142, "total": 150,
  "runtime_qualified": false, "qualified_passes": 0,
  "counts": { "critical": 0, "high": 0, "medium": 2, "low": 1 },
  "findings": [ { "id": "ssh-disable-root-login", "status": "passed" } ]
}

OSCAL : une baseline, pas encore un paquet d'évaluation

Le catalogue de contrôles est publié en OSCAL 1.1.2 (le format NIST adopté par CIS et NIST), pour qu'un outil GRC importe directement la baseline Pavois :

pavois oscal --out oscal/      # catalogue + un profil par OS

Il produit pavois-catalog.json (chaque contrôle, son check effectif, ses numéros CIS/STIG par OS et ses liens de normes) plus un profil par OS. Soyez précis sur le périmètre : Pavois émet le catalogue et les profils OSCAL (la baseline réutilisable), il n'émet pas encore les assessment-results OSCAL (le paquet de findings par scan). Vous obtenez donc aujourd'hui une baseline lisible par machine à importer, pas un bundle de résultats d'audit OSCAL complet ; les assessment-results sont en roadmap. La baseline est versionnée dans docs/reference/baseline.yml, suivie dans le CHANGELOG, et téléchargeable (catalogue, profils par OS, checksum SHA-256) sur la page Téléchargements.

La chaîne de preuve

Les pièces forment une chaîne que vous pouvez remettre à un auditeur : scan cible produit un finding par contrôle (check + type de preuve + valeur observée + verdict + normes), qui se cumule dans le rapport noté (HTML pour les humains, JSON/SARIF/JUnit/CSV pour l'outillage), tandis que la baseline réutilisable est le catalogue + profils OSCAL avec un checksum. Archivez le JSON et le HTML ensemble et la chaîne est reproductible avec --from.

Archiver un résultat de scan

Conserver le JSON (la source de vérité) et le HTML (la vue humaine), estampillés avec l'hôte, l'OS, la version de profil/baseline et la date du scan. Relancer avec --from <json> re-note un résultat archivé sans toucher à l'hôte.

Limites connues

À énoncer clairement dans tout dossier de preuve :

• Les checks effectifs nécessitent le service installé et démarré, souvent --sudo ; un contrôle sur un service absent est non-applicable, pas conforme.
• Certains contrôles n'ont pas de remédiation automatique (recompilations noyau, jugement) : Pavois livre la recette, il ne l'exécute pas.
• La couverture est honnête, pas totale : la plupart des contrôles mappent plusieurs normes, mais des contrôles mono-norme ou source-only existent et restent visibles.
• La sortie OSCAL est une baseline (catalogue + profils), pas encore un paquet assessment-results.

Bundle de preuve

pavois bundle <before.json> <after.json> empaquette toute une campagne dans un dossier infalsifiable : les scans avant/après, le plan appliqué (--plan), les rapports (--report), un éventuel justificatif de reboot et un fichier d'exceptions, un campaign-delta.json (la matrice de transition), un manifest.json (versions de pavois et du référentiel, cible, delta de note, SHA-256 par artefact) et un checksums.txt (vérifiable avec sha256sum -c). Le SHA-256 du manifeste est l'unique empreinte à signer et publier (minisign, cosign ou gpg) : le paquet devient inviolable, et une preuve opposable prête pour l'audit une fois signé sous une politique de confiance acceptée, et non une capture d'écran. Qui peut signer, quelle identité est acceptée, comment les clés tournent et comment vérifier hors ligne : voir le modèle de confiance. Vous signez checksums.txt avec votre propre identité (cosign sign-blob ou gpg --detach-sign) ; pavois ne possède pas la clé. pavois bundle verify <dir> revérifie ensuite le SHA-256 de chaque artefact, le digest du manifeste et la signature, et sort en erreur à la moindre falsification.

FAQ

Pavois émet-il les assessment-results OSCAL ? Pas encore. Il publie le catalogue et les profils par OS OSCAL (la baseline). Le paquet assessment-results par scan est en roadmap ; aujourd'hui vous exportez les findings en JSON/SARIF/JUnit/CSV.

Quel export archiver ? Le JSON (la source de vérité) plus le HTML (la vue humaine). --from <json> re-note le résultat archivé sans retoucher l'hôte.

Comment conditionner la CI à la note ? --fail-under N fixe le code de sortie d'après la note ; couplez-le à --format sarif ou junit pour faire remonter les findings dans le tableau de bord CI.

À quoi ressemble un vrai rapport Pavois ? Voyez le rapport d'exemple : un scan Debian 12 réel, plus le rapport de campagne avant/après avec la matrice de transition complète.

Comment produire une preuve prête pour l'audit ? Lancez pavois bundle before.json after.json --plan <plan> --report <html> : il regroupe les scans, le plan, les rapports, le delta de transition, un manifeste et des checksums, et affiche un unique SHA-256 à signer et publier.