Is SOCLE just your own norm? (governance & the circularity question)

Let's state the objection plainly, because it is fair: Pavois conforms to SOCLE, but SOCLE is written by the same author, so the tool passes a norm built for it. A closed loop. An auditor is right to ask. Here is the answer, without spin.

What SOCLE is

SOCLE (framework-scsl) is an open, end-to-end DevSecOps norm: 16 domains, three progressive levels (R1 foundational, R2 reinforced, R3 sovereign). Crucially, it does not invent a competing standard. It is a federating profile that assembles the existing referentials (CIS, ANSSI, NIST SSDF/800-53, SLSA, OWASP, S2C2F) into one hierarchy, and fills the gaps those leave (CI runners, workstations and secrets, supplier audit, sovereign cloud, AI in the SDLC).

Pavois is one consumer of SOCLE: its executable Linux-host audit layer. A Pavois control maps onto a SOCLE requirement under the RUN (runtime) and CLD (host posture) domains, and carries its SOCLE-<DOMAIN>-<FAMILY>-<N> reference (see the control ID model).

What SOCLE explicitly is NOT

This is the part that answers the objection, and it is SOCLE's own published stance, not a Pavois excuse:

• Not a certification. SOCLE's manifesto says it in those words: not a certification nor a guarantee of compliance, an opposable, factual profile. It issues no badge, certifies no host, grants no conformity.
• Not the source of authority. Its governing principle is an explicit inversion: the norm is the reference; tools consume it, never the inverse. The requirements are not tuned so a tool can pass them.
• Not a place for invented mappings. Another stated principle: everything is anchored, no correspondence, no clause number, no regulatory date is stated from memory; each claim carries its verified, dated source.

Why the loop isn't closed

A Pavois control's credibility does not come from SOCLE agreeing with it. It comes from the external standard the control maps to (CIS Benchmark section, ANSSI BP-028 R-rule, NIST 800-53 control, PCI-DSS, DISA STIG), and those mappings are cross-validated against independent authorities (ComplianceAsCode/SSG, ansible-lockdown, ciso-assistant), not against SOCLE. SOCLE is the namespace and crosswalk model that lets one neutral control carry all of those at once; it is not the thing that makes the control right.

So the chain of trust runs outward, not inward: control, then external requirement (verified), then cross-validated. Remove SOCLE entirely and every control still stands on CIS/ANSSI/NIST. SOCLE only saves you from duplicating the control five times, once per standard.

How to challenge a mapping or a control

Governance you can act on, not just assert. Because the source of truth is open (docs/reference/rules.yml, one control per neutral id), any mapping is contestable:

1. Open a GitHub issue on the Pavois repository naming the control's SOCLE id and the mapping you dispute.
2. Point at the authoritative source (the CIS section, the ANSSI R-rule, the NIST control) that contradicts or refines it.
3. The fix is a one-line edit to the norms block, re-checked by tools/validate_mappings.py against the independent sources, and recorded in the CHANGELOG.

No mapping is sacred, and none is stated from memory. If an external source says otherwise, the mapping is the bug.

The honest disclosure

Yes, SOCLE and Pavois share an author (Stéphane Robert), and SOCLE is a work in progress, maintained in the open by a single maintainer today. We don't hide that; pretending otherwise would be the dishonest move. The defensible claim is narrower and testable: SOCLE is open (norm-as-code, single source, JSON-Schema-validated in CI, versioned), its mappings are anchored to dated external sources, it certifies nothing, and a Pavois grade is only ever as good as the external norm behind each control, which you can check yourself on every fiche and re-run with tools/validate_mappings.py.

Governance, concretely

• Norm-as-code. Requirements live in a single versioned source, generated artefacts downstream, schema-validated in CI.
• Versioned, with deprecation. A new threat becomes a requirement; an unprovable requirement is removed or marked. Changes are tracked in the CHANGELOG, not silent.
• Anchored mappings. Every correspondence cites a verified, dated source, the same discipline Pavois applies when it cross-validates CIS/NIST/PCI tags.
• Opposable, not certifying. SOCLE gives you a factual profile to argue from; the certifying authorities remain CIS, ANSSI, the regulators.

If that still reads as "his own norm" to you, then judge Pavois on the layer that does not depend on SOCLE at all: the external mappings and their cross-validation. That is exactly where we want the scrutiny.

FAQ

Does SOCLE (or Pavois) certify my host as compliant? No. SOCLE certifies nothing and issues no badge; it is an opposable, factual profile. The certifying authorities remain CIS, ANSSI and the regulators. Pavois reports evidence, not a certificate.

Isn't a norm by the same author circular? The control's authority comes from the external standard it maps to and the cross-validation against independent sources, not from SOCLE. Remove SOCLE and every control still stands on CIS/ANSSI/NIST.

How do I dispute a mapping I think is wrong? Open a GitHub issue with the SOCLE id and the authoritative source that contradicts it. The mapping is a one-line edit re-checked by validate_mappings and recorded in the CHANGELOG.