SOCLE, n'est-ce pas votre propre norme ? (gouvernance & la question de la circularité)

Posons l'objection franchement, car elle est légitime : Pavois est conforme à SOCLE, mais SOCLE est écrit par le même auteur, donc l'outil passe une norme bâtie pour lui. Une boucle fermée. Un auditeur a raison de le demander. Voici la réponse, sans enrobage.

Ce qu'est SOCLE

SOCLE (framework-scsl) est une norme DevSecOps ouverte, de bout en bout : 16 domaines, trois niveaux progressifs (R1 fondamental, R2 renforcé, R3 souverain). Surtout, il n'invente pas un standard concurrent. C'est un profil fédérateur qui assemble les référentiels existants (CIS, ANSSI, NIST SSDF/800-53, SLSA, OWASP, S2C2F) en une hiérarchie unique, et comble les creux que ceux-ci laissent (runners CI, postes et secrets, audit des fournisseurs, cloud souverain, IA dans le SDLC).

Pavois est l'un des consommateurs de SOCLE : sa couche d'audit exécutable pour hôtes Linux. Un contrôle Pavois s'aligne sur une exigence SOCLE sous les domaines RUN (runtime) et CLD (posture hôte), et porte sa référence SOCLE-<DOMAINE>-<FAMILLE>-<N> (voir le modèle d'identifiant).

Ce que SOCLE n'est explicitement PAS

C'est la partie qui répond à l'objection, et c'est la position publiée de SOCLE lui-même, pas une excuse de Pavois :

• Pas une certification. Le manifeste SOCLE le dit mot pour mot : pas une certification ni une garantie de conformité, un profil opposable, factuel. Il n'émet aucun badge, ne certifie aucun hôte, n'accorde aucune conformité.
• Pas la source de l'autorité. Son principe directeur est une inversion explicite : la norme est la référence ; les outils la consomment, jamais l'inverse. Les exigences ne sont pas ajustées pour qu'un outil les passe.
• Pas un lieu de mappings inventés. Autre principe énoncé : tout est ancré, aucune correspondance, aucun numéro de clause, aucune date réglementaire n'est énoncé de mémoire ; chaque affirmation porte sa source vérifiée et datée.

Pourquoi la boucle n'est pas fermée

La crédibilité d'un contrôle Pavois ne vient pas de l'accord de SOCLE. Elle vient de la norme externe sur laquelle le contrôle se mappe (§ d'un CIS Benchmark, règle R d'ANSSI BP-028, contrôle NIST 800-53, PCI-DSS, STIG DISA), et ces mappings sont recoupés contre des autorités indépendantes (ComplianceAsCode/SSG, ansible-lockdown, ciso-assistant), pas contre SOCLE. SOCLE est le namespace et le modèle de crosswalk qui permettent à un contrôle neutre de porter tout cela d'un coup ; il n'est pas ce qui rend le contrôle juste.

La chaîne de confiance court donc vers l'extérieur, pas vers l'intérieur : contrôle, puis exigence externe (vérifiée), puis recoupée. Retirez SOCLE entièrement et chaque contrôle tient encore sur CIS/ANSSI/NIST. SOCLE vous épargne seulement de dupliquer le contrôle cinq fois, une par norme.

Comment contester un mapping ou un contrôle

Une gouvernance sur laquelle on peut agir, pas seulement affirmer. Parce que la source de vérité est ouverte (docs/reference/rules.yml, un contrôle par id neutre), tout mapping est contestable :

1. Ouvrez une issue GitHub sur le dépôt Pavois en nommant l'id SOCLE du contrôle et le mapping que vous contestez.
2. Pointez la source faisant autorité (la section CIS, la règle R d'ANSSI, le contrôle NIST) qui le contredit ou le précise.
3. Le correctif est une édition d'une ligne du bloc norms, re-vérifiée par tools/validate_mappings.py contre les sources indépendantes, et consignée dans le CHANGELOG.

Aucun mapping n'est sacré, et aucun n'est énoncé de mémoire. Si une source externe dit le contraire, c'est le mapping qui est le bug.

La divulgation honnête

Oui, SOCLE et Pavois partagent un auteur (Stéphane Robert), et SOCLE est un travail en cours, maintenu ouvertement par un mainteneur unique aujourd'hui. Nous ne le cachons pas ; prétendre l'inverse serait le geste malhonnête. L'affirmation défendable est plus étroite et testable : SOCLE est ouvert (norme-comme-code, source unique, validée par JSON Schema en CI, versionnée), ses mappings sont ancrés à des sources externes datées, il ne certifie rien, et une note Pavois ne vaut jamais mieux que la norme externe derrière chaque contrôle, que vous pouvez vérifier vous-même sur chaque fiche et rejouer avec tools/validate_mappings.py.

La gouvernance, concrètement

• Norme-comme-code. Les exigences vivent dans une source unique versionnée, les artefacts sont générés en aval, validés par schéma en CI.
• Versionnée, avec dépréciation. Une menace nouvelle devient une exigence ; une exigence non prouvable est retirée ou marquée. Les changements sont tracés dans le CHANGELOG, pas silencieux.
• Mappings ancrés. Chaque correspondance cite une source vérifiée et datée, la même discipline que Pavois applique en recoupant les tags CIS/NIST/PCI.
• Opposable, pas certifiant. SOCLE vous donne un profil factuel d'où argumenter ; les autorités certifiantes restent CIS, ANSSI, les régulateurs.

Si cela vous lit encore comme « sa propre norme », alors jugez Pavois sur la couche qui ne dépend pas du tout de SOCLE : les mappings externes et leur recoupement. C'est exactement là que nous voulons l'examen.

FAQ

SOCLE (ou Pavois) certifie-t-il mon hôte comme conforme ? Non. SOCLE ne certifie rien et n'émet aucun badge ; c'est un profil opposable et factuel. Les autorités certifiantes restent CIS, ANSSI et les régulateurs. Pavois rapporte des preuves, pas un certificat.

Une norme du même auteur n'est-elle pas circulaire ? L'autorité du contrôle vient de la norme externe sur laquelle il se mappe et du recoupement contre des sources indépendantes, pas de SOCLE. Retirez SOCLE et chaque contrôle tient encore sur CIS/ANSSI/NIST.

Comment contester un mapping que je crois faux ? Ouvrez une issue GitHub avec l'id SOCLE et la source faisant autorité qui le contredit. Le mapping est une édition d'une ligne re-vérifiée par validate_mappings et consignée dans le CHANGELOG.