Depuis quelques mois, je construis un référentiel : SOCLE, pour Sécurité Ouverte du Cycle de Livraison et d'Exploitation. C'est un projet personnel, né d'un besoin très concret : pouvoir auditer une infrastructure de bout en bout, du dépôt Git jusqu'à la production, sans angle mort et avec des exigences que je peux prouver.
Aujourd'hui je le sors au grand jour. Soyons clairs tout de suite : c'est une version gamma. Le squelette est là, l'ancrage est sérieux, mais ce référentiel a besoin de vos retours et de plusieurs itérations pour mûrir. Cet article raconte d'où il vient, ce qu'il est déjà, et comment je compte m'en servir pour mener des audits, notamment avec CISO Assistant.
Le besoin : auditer sans angle mort
Quand je veux évaluer la posture de sécurité d'une chaîne logicielle, je me heurte toujours au même mur : il n'existe pas de référentiel unique qui couvre tout le spectre. La provenance du build ? SLSA. Le cycle de développement ? NIST SSDF. Les risques applicatifs et CI/CD ? OWASP. Le durcissement ? CIS et ANSSI. La consommation d'open source ? S2C2F. Le réglementaire ? CRA, NIS2, DORA. Chacun éclaire un maillon. Aucun ne donne la vue unique, du poste de développement au cloud d'exécution, fournisseurs inclus.
Résultat : pour auditer correctement, je devais jongler entre une dizaine de cadres, recoller les morceaux à la main, et accepter des trous entre eux. Ce n'est pas tenable, et surtout ce n'est pas reproductible.
Le problème : riche mais fragmenté, ou opaque
En face de cette richesse fragmentée, il y a les plateformes propriétaires qui promettent la conformité dans une boîte noire : catalogues non publics, correspondances générées par IA et non rejouables. C'est exactement l'inverse de ce qu'exige une démarche sérieuse : transparence, preuve, traçabilité, vérifiabilité. Je n'allais pas baser mes audits sur quelque chose que je ne peux ni lire ni contredire.
Ce que SOCLE assemble
Je n'ai pas voulu créer un référentiel de plus. SOCLE assemble ceux qui font autorité en un profil fédérateur, lisible de bout en bout. Concrètement, à ce jour :
- 16 domaines, de la gouvernance au cloud, en passant par la culture, la source, l'intégration, le packaging, la release, le déploiement, les fournisseurs et l'IA.
- 408 exigences hiérarchisées en trois niveaux de robustesse (R1 fondamental, R2 renforcé, R3 souverain), chacune avec une correspondance ancrée vers sa source et une preuve attendue.
- 106 vecteurs d'attaque et 169 incidents réels reliés aux exigences : on part de l'attaque, on remonte au contrôle.
- 56 outils open source cartographiés, avec ce que chacun prouve et ce qu'il ne prouve pas.
Le tout est publié en « norme comme code » : une source de vérité unique, versionnée, validée par schéma, dont ce site est généré. La norme est sous CC BY 4.0, le code sous Apache-2.0. Vous pouvez tout lire, tout réutiliser, et surtout tout contredire.
Pas qu'un référentiel : une méthode
Un référentiel qui dort dans un coin ne sert à rien. SOCLE porte aussi une méthode : un modèle de maturité M0 à M4 par domaine, trois piliers (auditer, transformer, capaciter), et une évaluation opposable. Cette dernière est le coeur de mon besoin : un format où chaque exigence reçoit un statut, où le niveau atteint se calcule sans interprétation, et où un score n'est valable que si son périmètre est déclaré. Pas de note sans contexte, pas de conformité « en un clic ».
Pourquoi je parle de version gamma
Je l'ai versionnée 1.0.0-rc, mais honnêtement, pour moi c'est encore une
gamma. Oui, « gamma » : ni alpha, ni bêta. Un cran de plus dans l'humilité,
parce que ça tient debout mais ça bouge encore. Le classement par niveau est
posé, les correspondances sont ancrées, mais :
- certaines correspondances externes restent à figer ;
- le nom même pourrait changer (c'est un nom de travail) ;
- des domaines comme la culture ou la sécurité applicative méritent encore d'être étoffés.
Je préfère le dire franchement plutôt que de survendre. SOCLE s'enrichira par itérations, et ces itérations seront bien meilleures avec des retours de terrain que seul, dans mon coin.
Conduire les audits : je teste CISO Assistant
Un référentiel, c'est le « quoi ». Pour mener un audit réel, il me faut un « avec quoi » : un outil de GRC (gouvernance, risque, conformité) capable de porter SOCLE, de suivre les statuts par exigence et de produire des rapports.
J'évalue actuellement CISO Assistant, la solution open source d'intuitem. Deux raisons : elle est ouverte (cohérent avec ma démarche), et elle permet d'importer son propre référentiel via un DSL dédié. L'idée est donc d'y charger SOCLE comme framework personnalisé, puis de conduire les évaluations directement dedans, avec le suivi et les exports qui vont avec. Si l'essai est concluant, j'en ferai un retour détaillé.
Ce dont j'ai besoin de vous
C'est là que ça devient intéressant. SOCLE n'a de valeur que s'il est confronté au réel. J'attends :
- des retours d'usage : une exigence floue, un niveau mal placé, un domaine incomplet ;
- des cas concrets : un incident, une architecture, un contexte que le référentiel couvre mal ;
- des corrections d'ancrage : une correspondance vers un standard qui ne tient pas, une source à dater.
Pas besoin d'être d'accord avec tout. Les désaccords argumentés sont ce qui fera progresser le référentiel le plus vite.
À retenir
- SOCLE est mon référentiel ouvert pour auditer la chaîne logicielle de bout en bout, sans angle mort.
- Il assemble les cadres existants (SLSA, SSDF, OWASP, CIS, ANSSI, CRA/NIS2…) plutôt que d'en inventer un de plus.
- À ce jour : 16 domaines, 408 exigences (R1/R2/R3), 106 vecteurs, 169 incidents, 56 outils, le tout en norme comme code (CC BY 4.0 / Apache-2.0).
- Il porte une méthode (maturité M0-M4, audit/transformation/capacitation) et une évaluation opposable.
- C'est une version gamma : elle a besoin de vos retours pour s'enrichir.
- J'évalue CISO Assistant pour outiller les audits en y important SOCLE comme framework personnalisé.