The standards Pavois maps to

The threat: four checklists for one setting

The real threat here is not a single exploit, it is inconsistency and unverifiable claims. Different teams, auditors and regulators each demand a different hardening framework: a cardholder environment answers to PCI-DSS, a French public-sector host to ANSSI-BP-028, a US federal system to NIST 800-53/171, while operations standardize on CIS Benchmarks and defense on STIG. Maintaining four or five separate checklists for the same sshd or sysctl setting guarantees drift, contradictory values, and an audit you cannot reproduce. Worse, most tooling proves compliance by reading config files, so an Include or a drop-in silently breaks the mapping and you ship a control that looks covered but isn't.

Why it matters

A control is only worth its evidence. If you cannot point an auditor at one concrete check and say this is the CIS line, the ANSSI rule and the NIST family it maps to, here is the effective value we measured, the compliance claim is theatre. Mapping standards correctly turns scattered hardening into a defensible, multi-framework posture from a single scan, and lets you answer "are we CIS Level 2?" and "are we ANSSI enhanced?" without re-auditing the machine for each.

One neutral rule, N views

The load-bearing principle: a control has a single stable, vendor-neutral internal id (a domain-object slug like ssh-disable-root-login), and each standard is attached as a tag in a norms block. A standard is a view, never a copy. We never duplicate a control per framework, so the mappings can never drift apart. The standards themselves:

• CIS Benchmarks: community consensus, prescriptive and per-product, two profiles: Level 1 (baseline) and Level 2 (defense-in-depth, may break functionality). Tagged level_cis: '1'|'2' + the recommendation number.
• ANSSI-BP-028: the French agency's Linux guide, numbered R1..R<n>, with four cumulative levels (minimal, intermediary, enhanced, high).
• NIST SP 800-53 / 800-171: control families (AC, AU, SC, CM), abstract postures rather than line-by-line settings.
• PCI-DSS: numbered requirements (Req-8.x), pass/fail, mandatory for cardholder data.
• STIG: DISA per-rule prescriptive guides, like CIS in granularity.

Mapping types: direct vs supporting

A mapping is a cross-reference, not a proof of equivalence. The strength depends on the nature of the standard:

A direct mapping means the standard prescribes this exact setting; the check satisfies it on its own. A supporting mapping means the check contributes to an abstract family alongside others; passing it is evidence toward the family, not a certificate that the check alone fulfils it. The crosswalk badge on each rule fiche states which.

A real mapping, read correctly

The control ssh-disable-root-login carries this norms block, measured once by one sshd -T check:

"norms": {
  "bp28": "R33",
  "cis": ["5.1.20", "2.2.6", "5.1.22"],
  "nist": ["AC-17(a)", "AC-6(2)", "CM-6(a)", "IA-2"],
  "pci-dss": ["2.2.6", "Req-2.2.4"]
}

Read it correctly: CIS 5.1.20 and ANSSI BP-028 R33 are direct (each prescribes PermitRootLogin no); NIST AC-17(a)/IA-2 are supporting (disabling root SSH contributes to the remote-access and identification families, which many other controls also serve). A passing check is evidence toward all of them, not a blanket "compliant with five standards."

How mappings are validated

Mappings are per-OS and version-pinned: each rule records the benchmark version it was aligned against in os_versions (e.g. CIS 2.0.0 for rhel9, 1.1.0 for debian12), because a CIS recommendation number means nothing without its benchmark release. Every mapping is then cross-validated against independent sources rather than asserted:

# cross-check every norms[] entry against SSG, ansible-lockdown and ciso-assistant
mise run validate_mappings

This is the discipline that keeps a crosswalk honest rather than aspirational, and the same neutral corpus is published as an OSCAL bundle (catalog + profiles) for GRC tooling.

What Pavois audits

Pavois ships one corpus of neutral controls, each auditing the effective configuration (sshd -T, sysctl, systemctl show), each carrying a norms block mapping it to each standard that covers it. The HTML report exposes a regulation <select> plus a level selector (CIS 1/2, ANSSI minimal..high) that recomposes chapters and the score client-side: the same evidence, re-projected through whichever standard your auditor speaks. Because every check reads resolved state, the mapping stays honest even when settings live in Includes or drop-ins a file scanner would miss.

FAQ

Does a passing check mean I am compliant with five standards? No. It is evidence toward its mappings. Direct mappings (CIS, STIG, ANSSI) it satisfies outright; supporting ones (NIST families) it contributes to alongside other controls.

Why pin a benchmark version per OS? Because a bare 5.1.20 is meaningless without its release: CIS renumbers between versions. os_versions records exactly which benchmark each mapping was aligned to.

Can I export the mappings for my GRC tool? Yes, the neutral corpus is published as an OSCAL catalog and profiles, the NIST machine-readable format for compliance automation.