For a few months now, I have been building a framework: SOCLE, for Sécurité Ouverte du Cycle de Livraison et d'Exploitation (open security of the delivery and operations lifecycle). It is a personal project, born from a very concrete need: being able to audit an infrastructure end to end, from the Git repository to production, without blind spots and with requirements I can prove.
Today I am bringing it into the open. Let me be clear right away: this is a gamma version. The skeleton is there, the anchoring is serious, but this framework needs your feedback and several iterations to mature. This post tells where it comes from, what it already is, and how I intend to use it to run audits, notably with CISO Assistant.
Why audit without blind spots?
When I want to assess the security posture of a software delivery chain, I always hit the same wall: there is no single framework covering the whole spectrum. Build provenance? SLSA. The development lifecycle? NIST SSDF. Application and CI/CD risks? OWASP. Hardening? CIS and ANSSI. Open source consumption? S2C2F. Regulation? CRA, NIS2, DORA. Each one lights up one link. None gives the single view, from the developer workstation to the execution cloud, suppliers included.
The result: to audit properly, I had to juggle a dozen frameworks, glue the pieces back together by hand, and accept gaps between them. That is not sustainable, and above all it is not reproducible.
What is wrong with the existing landscape?
Facing this fragmented richness, there are the proprietary platforms that promise compliance inside a black box: non-public catalogs, AI-generated mappings that cannot be replayed. It is exactly the opposite of what a serious approach demands: transparency, proof, traceability, verifiability. I was not going to base my audits on something I can neither read nor contradict.
What does SOCLE assemble?
I did not want to create yet another framework. SOCLE assembles the authoritative ones into a federating profile, readable end to end. Concretely, as of today:
- 16 domains, from governance to cloud, through culture, source, integration, packaging, release, deployment, suppliers and AI.
- 408 requirements ranked in three robustness levels (R1 fundamental, R2 reinforced, R3 sovereign), each with an anchored mapping to its source and an expected proof.
- 106 attack vectors and 169 real incidents linked to the requirements: you start from the attack, you trace back to the control.
- 56 open source tools mapped, with what each one proves and what it does not prove.
Everything is published as standard as code: a single source of truth, versioned, schema-validated, from which this site is generated. The standard is under CC BY 4.0, the code under Apache-2.0. You can read everything, reuse everything, and above all contradict everything.
Why is it more than a framework?
A framework gathering dust in a corner is useless. SOCLE also carries a method: a maturity model M0 to M4 per domain, three pillars (audit, transform, enable), and a defensible assessment. The latter is the core of my need: a format where every requirement receives a status, where the level reached is computed without interpretation, and where a score is only valid if its scope is declared. No grade without context, no one-click compliance.
Why do I call it a gamma version?
I versioned it 1.0.0-rc, but honestly, to me it is still a
gamma. Yes, "gamma": neither alpha nor beta. One extra notch of humility,
because it stands up but it still moves. The level ranking is
in place, the mappings are anchored, but:
- some external mappings remain to be frozen;
- the name itself could change (it is a working name);
- domains like culture or application security still deserve to be fleshed out.
I would rather say it plainly than oversell. SOCLE will grow through iterations, and those iterations will be far better with field feedback than alone, in my corner.
How will I run the audits? I am testing CISO Assistant
A framework is the "what". To run a real audit, I need a "with what": a GRC tool (governance, risk, compliance) able to carry SOCLE, track statuses per requirement and produce reports.
I am currently evaluating CISO Assistant, the open source solution by intuitem. Two reasons: it is open (consistent with my approach), and it allows importing your own framework through a dedicated DSL. The idea is therefore to load SOCLE into it as a custom framework, then run the assessments directly inside, with the tracking and exports that come with it. If the trial is conclusive, I will publish a detailed report.
What do I need from you?
This is where it gets interesting. SOCLE only has value if it is confronted with reality. I am hoping for:
- usage feedback: a fuzzy requirement, a misplaced level, an incomplete domain;
- concrete cases: an incident, an architecture, a context the framework covers poorly;
- anchoring fixes: a mapping to a standard that does not hold up, a source to date.
No need to agree with everything. Argued disagreements are what will make the framework progress the fastest.
Key takeaways
- SOCLE is my open framework to audit the software delivery chain end to end, without blind spots.
- It assembles the existing frameworks (SLSA, SSDF, OWASP, CIS, ANSSI, CRA/NIS2...) rather than inventing one more.
- As of today: 16 domains, 408 requirements (R1/R2/R3), 106 vectors, 169 incidents, 56 tools, all as standard as code (CC BY 4.0 / Apache-2.0).
- It carries a method (M0-M4 maturity, audit/transformation/enablement) and a defensible assessment.
- It is a gamma version: it needs your feedback to grow.
- I am evaluating CISO Assistant to tool the audits by importing SOCLE as a custom framework.