Pépin: find what actually weakens your cloud

Read this page in French

A scanner that finds nothing has not proved that everything is fine: it has proved that it found nothing. Pépin audits the effective configuration of European sovereign clouds, either from a Terraform plan before deployment or from a live collection afterwards, and it insists on separating three things most tools blur together: what is compliant, what is not, and what it could not observe.

The problem, before the architecture

Your Terraform looks fine. So does your tenant. Yet an over-broad network rule, an access key with no expiry or an open bucket is enough to change the posture, and nothing in the console tells you.

The hard part is not finding those deviations, plenty of tools do. The hard part is knowing what the scanner actually looked at. An absence of findings can mean "this is clean", or "I could not collect the data". Conflating the two turns an audit into false assurance.

Two commands, one verdict

No cloud account is needed to watch Pépin work: the repository ships example inventories.

pepin scan scaleway examples/scaleway/inventory.json

The output ends like this, and the exit code is 1:

 Verdict : NON CONFORME

 🔴 CRITICAL 2   🟠 HIGH 2   🟡 MEDIUM 0   🔵 LOW 0

On the fixed inventory, the same check returns a verdict worth reading word by word, and the exit code drops back to 0:

 Verdict : conforme sur le périmètre évalué
 (aucune non-conformité détectée, 12 contrôles conformes)

"Compliant within the evaluated scope", and the number of controls that establish it. Not "compliant". That nuance is the whole product.

Reports follow your locale

Pépin detects the interface language from PEPIN_LANG, then LC_ALL and LANG, and falls back to English. The verdicts above are shown in French because that is how they were captured; --lang en renders the same run in English, with identical statuses, subjects and exit codes.

What the table hides, and Pépin knows

The human-readable output shows deviations. The assessment format shows the whole truth, status by status. On the vulnerable inventory above:

Status	Count	What it means
fail	4	the deviation is established, with the offending resource
pass	7	the required data was collected, and it is compliant
not-applicable	2	the control does not concern this scope, and Pépin says why
not-evaluated	14	the data was missing: no conclusion is drawn

Glissez pour voir

Fourteen controls out of twenty-seven could not be evaluated, and it is written down. A scanner counting those fourteen as successes would have displayed a flattering, false score. Every non-evaluation carries its reason:

compute_instance_has_security_group
  no resource of type "compute_instance" in the evaluated inventory

governance_resource_required_tags
  collection of the required data not confirmed for this provider

The rule everything else rests on

An absence of findings is never converted into compliance. That single commitment is where the rest follows from: the not-evaluated status, the reason attached to it, the count of passing controls inside the verdict, and the refusal to display one global coverage percentage that would blend different degrees of proof.

What Pépin works on

Three providers, two data sources. Each provider is described in its native vocabulary, never by comparison with a non-sovereign hyperscaler.

Provider	Terraform plan audit	Live collection via API
Scaleway	yes	yes
Outscale	yes	yes
Exoscale	yes	yes

Glissez pour voir

The two sources do not answer the same question. The Terraform plan tells you what you are about to create, and lets you block before deployment. The live collection tells you what is actually running, including whatever nobody declared in code.

What the results map onto

Controls are anchored on a common referential of 57 controls, with mappings to SCSL, SecNumCloud 3.2, CIS Controls v8 and ISO/IEC 27001:2022 and 27017. Every finding carries its normative reference and a link to the control it names.

What those mappings are not

Pépin repeats it at the foot of every report, and so does this page: normative mappings are indicative. They are not proof of qualification or certification, which applies to the cloud service provider, not to your configuration.

What Pépin evaluates is the customer scope: what you are responsible for under the shared responsibility model. That is already a great deal, and it is something other than a certificate.

Where to start

I want to see Pépin find something A first scan in five minutes, with no cloud account and no credentials.

I just got a result Read the four statuses, the severity, and what each field establishes.

The actual state of the project

Pépin is at version 0.4.0. It is a young project, under the Apache-2.0 licence, and this page would rather say so than let you discover it.

	State on 9 September 2026
Controls in the common referential	57
Providers	Scaleway, Outscale, Exoscale
Sources	Terraform plan, live collection via API
Output formats	table, json, assessment, oscal, sarif
Evidence bundle	--seal, re-checked by pepin verify, optional cosign signature
Languages	French and English, detected automatically

Glissez pour voir

What is still under construction is stated where it belongs rather than here: each page states its own limits.

Key points

• An absence of findings is not compliance. Pépin separates pass, fail, not-applicable and not-evaluated, and justifies the last two.
• The compliant verdict is qualified: "within the evaluated scope", with the number of controls that establish it.
• Three providers, described in their native vocabulary: Scaleway, Outscale and Exoscale.
• Two sources answering different questions: the Terraform plan before deployment, the live collection afterwards.
• 57 controls mapped to SCSL, SecNumCloud 3.2, CIS v8 and ISO 27001/27017.
• Normative mappings are indicative: qualification applies to the provider, not to your configuration.
• The project is at 0.4.0, under Apache-2.0, and says so.

External resources

• Pépin on GitHub: the technical reference, the full command-line surface and the contribution guide.
• NIST OSCAL: the model Pépin exports its results into.
• SecNumCloud, the ANSSI referential: the framework the mappings anchor on.

×

📖 Voir la documentation →