Pépin: find what actually weakens your cloud

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.

What you will learn

• Explain why an absence of results does not prove compliance.
• Tell apart the four statuses of a result and what each lets you conclude.
• Choose between auditing a Terraform plan and auditing a tenant.
• Place what the tool does not cover and the real state of the project.

Prerequisites

This lesson is optional. It assumes you know what a cloud configuration posture is, and the shared responsibility (in French) between provider and customer. Two terms are used throughout: a Terraform plan is the list of what terraform plan is about to create, and a tenant is your organisation's space at a cloud provider.

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 (deviations flagged by the scanner) can mean "this is clean", or "I could not collect the data". Conflating the two turns an audit into false assurance.

One scan, one verdict

No cloud account is needed to watch Pépin work: the repository ships example inventories. You do need to install Pépin and clone its repository to get the examples/ folder; the first scan page shows how, step by step.

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, which the first scan page has you work with, 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 provider's contract declares that this control cannot exist on its side, with a justification
not-evaluated	14	the data was missing: no conclusion is drawn

Swipe to see more

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 hyperscaler.

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

Swipe to see more

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 58 controls, with mappings to SCSL (the common referential of the SOCLE cloud domain, in French), 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: your tenant's configuration as the API or the Terraform plan describe it, so what you are responsible for on the platform side under the shared responsibility model. The inside of the machines (guest operating system, guest-side encryption) is not observed. That is already a great deal, and it is something other than a certificate: a posture read, not a qualification.

Where to start

Two entry points are enough to get started: seeing Pépin at work on a test project, or reading a result you already have. Pick the one that matches your situation.

To see Pépin at work, the first scan guide gets you to a result in five minutes, with no cloud account and no credentials. To read a result you already have, the optional lesson Compliant, deviating or impossible to conclude explains the four statuses, severity, confidence and provenance. It aims at the skill of reading a posture, more than that of operating the tool.

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 16 October 2026
Controls in the common referential	58
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

Swipe to see more

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

For the technical reference and the command-line options, see the Pépin repository on GitHub. The oscal export format follows the NIST OSCAL model, and the mappings anchor on SecNumCloud, the ANSSI referential.

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.
• 58 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.

×

See in the glossary →