Governance: licence, versioning, provenance, security

A tool that asks you to trust its verdict owes you the answers on this page. None of them is flattering, and all of them are true.

Licence

Apache License 2.0. The code, the rule base, the OSCAL bundle and this site.

The control definitions were bootstrapped from ComplianceAsCode/SSG (BSD-3), and that inheritance is credited on the attribution page. The norm reference numbers themselves (CIS 5.1.20, ANSSI R33, PCI 2.2.6) are facts, not content: Pavois maps to them and does not reproduce the benchmarks' prose, which belongs to CIS, PCI SSC, DISA and NIST respectively.

Who maintains this

One person. That is a fact you should weigh, and it is why the SOCLE governance chapter states the same thing about the nomenclature. A single maintainer means: fast, coherent, and a bus factor of one. Judge accordingly.

How the rule base is versioned

The baseline carries a name, an id and a semantic version, in one place (docs/reference/baseline.yml), and pavois oscal stamps the OSCAL catalog from it. Today: pavois-baseline 0.1.0.

A control id is a contract: it appears in your reports, your SARIF, your evidence bundles. Removing one breaks a consumer, which is why it takes a MAJOR bump and why merged duplicates keep a replaces: trail.

Where a mapping comes from, and how you can check it

This is the question an auditor will ask, so here is the honest chain:

1. The reference numbers were mined, once, from the SSG datastream for each OS (ssg-<os>-ds.xml), which is the same source OpenSCAP evaluates. They were not typed from memory, and they were never invented.
2. Each CIS mapping is cross-validated against a SECOND, independent source: ansible-lockdown's CIS role for the same OS (tools/cross_validate.py). A control whose CIS number appears in one source and not the other is surfaced, not silently kept.
3. Three OSes have no CIS benchmark of their own, so their CIS numbers cannot be cross-validated against a same-OS source: Fedora and RHEL 10 inherit the RHEL 9 mapping, Ubuntu 26.04 inherits Ubuntu 24.04. That inheritance is declared in the per-OS benchmark table, and marked "inherited" on those OSes rather than passed off as a native mapping. It is a reasonable default (the RHEL 10 and Ubuntu 26.04 benchmarks did not exist when this was written); it is not the same evidence as a pinned, cross-validated version, and the site never pretends it is.
4. The rule base is now the source of truth, maintained directly. SSG is no longer the upstream: it is one of the two witnesses.

What that does not give you: an independent audit of all 2,729 norm references. Nobody has done that. If you are staking a certification on a specific mapping, verify that one against the benchmark you are certifying against: and if it is wrong, tell us, because a wrong mapping is the worst kind of bug this project can ship.

What happens when CIS publishes a new benchmark

The benchmark version is pinned per OS, and published in full in the per-OS benchmark table (Debian 12 → CIS 1.1.0, RHEL 9 → CIS 2.0.0, and the three inherited OSes marked as such). When a new version lands:

• the datastream is re-fetched (tools/fetch_datastreams.sh);
• the coverage delta is computed (which of the new benchmark's rules Pavois does not cover, and why);
• the mappings are re-anchored, and the base gets a MINOR bump.

The same applies to a standard that renumbers itself: NIST 800-171 is pinned to Rev 2 on this site, explicitly. Two reasons, one practical and one that matters more: Rev 3 renumbers the requirements, so re-anchoring is a full cross-validation pass rather than a search-and-replace; and, decisively, the May 2024 DFARS class deviation keeps DFARS 252.204-7012 and CMMC assessments on Rev 2, so an assessor in 2026 is still measuring against Rev 2. Pinning to it is not lag, it is tracking the revision the contract actually cites. A mapping to an unnamed revision is worthless; a mapping to the named revision your auditor uses is correct.

Releases

Releases are published on the repository, and that is where the binaries are pulled from. Each one carries a checksums.txt, a CycloneDX SBOM, a SLSA build-provenance attestation and a keyless Cosign signature, so integrity and origin are both checkable by someone with no access to this project. The installation page prints the two commands.

Releases are tracked in the CHANGELOG, and the rule base version moves with them under the rules above. The tool version and the baseline version are deliberately separate: a fix to the scanner is not a change to the standard it evaluates, and a report cites the baseline version and its content digest so an archived result stays interpretable after the tool has moved on.

Reporting a vulnerability

Privately, through GitHub's private vulnerability reporting, never in a public issue. The SECURITY.md in the repository has the details.

One clarification that saves everyone time: a finding in the OS being audited is not a Pavois vulnerability, and neither is a flaw in a third-party datastream: report those upstream. A Pavois vulnerability is one in Pavois: a credential leak, a command injection through a rule field, a remediation that opens a hole.

FAQ

Is the rule base independently audited? No. It is cross-validated against two upstream sources, which is not the same thing and this page will not pretend otherwise.

What if a mapping is wrong? Open an issue with the control id and the benchmark clause. A wrong mapping is a correctness bug, not a matter of opinion, and it will be treated as one.

Can I use Pavois commercially? Yes: Apache 2.0. The benchmarks it maps to have their own terms, which are the publishers' business and not affected by this licence.

Who decides what a control means? The rule base does, and it is public, in one file, in a readable format. If you disagree with a control, you can read exactly what it checks and what it would change on your host, before it runs.

Key takeaways

• Apache 2.0, one maintainer, a bus factor of one. Weigh it.
• The rule base is semantically versioned, and a control id is a contract: removing one is a MAJOR change.
• Every CIS mapping was mined from the SSG datastream and cross-validated against ansible-lockdown. It has never been independently audited, and this page says so.
• Benchmark versions are pinned and shown per OS (three OSes with no benchmark inherit a sibling's, marked as such), and a renumbering (NIST 800-171 Rev 3) is a full re-anchoring, not a rename.

Next steps

• Attribution & licensing · Feature status · SOCLE governance