Pavois

Effective Linux Compliance

Pavois audits the configuration your services actually run, sshd -T, sysctl, systemctl show, not just the files on disk. It catches the Includes and drop-ins that file-based scanners miss, grades the result A:E, and remediates it as code.

$pavois scan local --sudo

Get started →Read the docs →Browse 790 controls

File scanners read the file.
Attackers read the drop-in.

A permissive override in a .d directory silently defeats a stricter main config. Read the file and you get a green check that isn’t true. Read the effective state and you get the truth.

File scanner, oscap / OVAL

reads /etc/ssh/sshd_config
→ PermitRootLogin no

✓ PASS

Never opened sshd_config.d/90-cloud.conf. The Include is invisible to a file read.

same host

Pavois, effective config

reads sshd -T
→ permitrootlogin yes

✗ FAIL

The drop-in re-enabled root login. Pavois evaluates exactly what the daemon applies.

The file says no. The daemon says yes. Wherever a service resolves its own config, sshd -T, sysctl, systemctl, auditctl, only the effective read catches the override. Each control states the evidence it relies on, so you always know what a pass proves.

More on effective configuration, the truth no file holds →

the demo

From a cloud image to a hardened host,
in two minutes.

One Debian 13 VM, and every command really ran. Pavois asks the running system and grades it E. It then plans, where every gap is opt-in and nothing is done behind your back. Between the two takes the host is hardened for real, and the same command is run again.

pavois scan, harden plan, harden apply, scan again

In this recording: 258 of 523 controls passing before, 516 of 560 after, 0 critical and 0 high left, and grade A on everything a remediation can reach (469/470). It stays C overall because 44 gaps need a separate partition or a rebuilt kernel, and Pavois names them rather than dropping them from the denominator. The apply itself, three passes and three reboots, is off camera.

See a full report →

790

controls

2,730

norm references

228

controls cross ≥3 standards

Linux targets

standards, one rule base

Audit, grade, harden, prove.

A state-aware loop, not a blind script. Nothing changes until you opt in, and every fix is proven against a fresh scan.

01 · scan

Audit

Resolve the effective config of any target and grade it A:E against the standard you choose.

pavois scan <target>

02 · report

Grade

A chaptered A:E report, per-standard. SARIF, JUnit, HTML, and CI-friendly exit codes.

--format sarif --fail-under 80

03 · harden

Remediate

Plan the fixes, flip apply per rule, converge a native Chef run. No bash.

pavois harden plan local

04 · prove

Prove

Re-scan after a real reboot: a fix that survives is reboot-proven. The verdict is honest, runtime-only passes can’t earn a clean A.

pavois harden apply --reboot --scan

Pavois builds a compliant image.
It does not rescue a legacy host.

Some gaps cannot be closed by any command: a separate /var/log is decided when the disk is partitioned, and a kernel without the KSPP options cannot grow them at runtime. Those controls carry the classes install-time and kernel-build because no apply can close them on a box that is serving traffic. Point Pavois at a legacy host and it still tells you the truth, including which share of the gaps needs a rebuild rather than a command.

None of this replaces what you already run. Your configuration management stays the source of desired state and your scanner keeps its verdict: Pavois reads back the effective state a machine resolved, and the smallest useful first step is one image, side by side, comparing what the two of them actually measured. What that comparison looks like is published: a real report and its before/after campaign →

Built for

Building a golden image: fresh install, partition recipe, KSPP kernel, converged apply, then bake it.
Watching a fleet for drift: scan the hosts you shipped, catch the drop-in someone added last Tuesday.
Proving a posture: a chaptered report, a signed evidence bundle, an OSCAL export an auditor can consume.
Gating a pipeline: --fail-under turns the grade into a CI check on the image you are about to ship.
Already running Ansible, Puppet or Packer: they stay the source of desired state. Pavois reads back what the machine ACTUALLY resolved, which is not the same question and not the same answer.
Already running a compliance scanner: keep it. Run Pavois beside it on one image, compare the two verdicts and the evidence behind them, and decide from what you measured.

Not a fit

A ten-year-old production host you cannot repartition or reboot. It will be audited honestly, and a share of its gaps will stay open.
A one-shot script that blindly applies everything. Nothing changes until you flip apply per rule, on purpose.
A certification stamp. Pavois produces evidence; the auditor produces the verdict.
A non-Linux estate. 9 Linux OS families today, nothing else.

Operating Pavois: the four questions that decide whether it fits →

One control, every applicable mapping.

A single effective-config assertion carries every applicable mapping. One neutral control, each standard that covers it, never a duplicated rule, never a divergent result.

SOCLE-CLD-IAM-008Lock Accounts After Failed Password Attempts

✓ effective-config check

→

CIS5.3.3.1.1 ANSSI-BP-028R31 NIST3.1.8 PCI-DSS8.3.4 DISA STIGUBTU-22-411045

You audit the one you need.

Mapping several standards is how the rule base avoids duplicating the same check five times. It is not something you have to adopt. Pick one standard and Pavois runs that one:

$pavois scan local --sudo --standard bp28

$pavois scan local --sudo --standard cis --level 1

--standard filters what the engine runs, not what the report shows, and pavois harden apply takes it too, for the remediation values that differ between standards.

Built on SOCLE, one hardening norm, every tool.

Pavois’s controls come from SOCLE: a neutral, versioned reference that maps each requirement to CIS, ANSSI-BP-028, NIST, PCI-DSS and STIG where each applies, so a single check is the source of truth for every mapping it carries.

Each control carries a stable ID, SOCLE-<domain>-<family>-<n>, under SOCLE’s RUN (runtime) and CLD (host posture) domains. Consume it as JSON or OSCAL, version it, test it.

$pavois oscal --out oscal/

SOCLE · one control → every mapping

SOCLESOCLE-CLD-IAM-008 · effective-config assertion

CIS5.3.3.1.1

ANSSIR31

NIST3.1.8

PCI8.3.4

DISA STIGUBTU-22-411045

Three ways in.

Sysadmin

Harden a Linux server

Scan the host, understand the gaps, apply remediation, verify the effective state.

Quickstart →Auditor / GRC

Prove compliance

The auditor journey: report, verdict, score, signed evidence bundle, trust model, OSCAL exports and benchmark.

Audit journey →Platform / Security

Standardise hardening

Versioned SOCLE controls and repeatable evidence across the fleet.

Browse controls →

Native, agentless, CI-ready.

Native CINC / InSpec

Runs cinc-auditor natively over local, SSH or docker targets. No agent, your own ~/.ssh/config.

Effective by design

The resolved state, sshd -T, sysctl -a, systemctl show, auditctl -l, never the text of one file.

A:E grading

A chaptered report, a per-standard view, and a --fail-under gate that turns the grade into a CI check. How the grade is computed →

Qualified verdict

A PASS says what it proves: running now vs reboot-survivable. A runtime-only pass (a live sysctl not pinned on disk) is qualified, it caps the grade under A until persistence is proven. What a pass proves →

Harden as code

Plan, edit, apply. A native Chef convergence, opt-in per rule, with a dry-run, never a blind shell script.

CI-native output

SARIF for code scanning, JUnit for test reports, CSV/HTML/JSON, and exit codes a pipeline can act on.

Credential-safe

Passwords reach the engine over stdin only, nothing leaks via ps, /proc or shell history.

Audit what your servers
actually run.

A Go CLI that drives native CINC Auditor. Point it at a host and read the truth.