Conforme, en écart ou impossible à conclure : lire un résultat Pépin

Un résultat Pépin ne se lit pas comme une alerte, mais comme une phrase avec un sujet, un verdict et une raison. Quatre statuts existent, et deux d'entre eux ne disent pas ce qu'on croit : not-applicable et not-evaluated sont des refus de conclure, pas des succès discrets. Cette page explique ce que chaque statut autorise à affirmer, pourquoi la gravité d'un écart ne dit rien de la certitude qu'on en a, et comment la provenance d'un scan permet de le relire dans six mois.

Ce que vous allez apprendre

Distinguer les quatre statuts, et ce que chacun permet de conclure.
Séparer la sévérité, qui dit la gravité, de la confiance, qui dit la certitude.
Lire le bloc de provenance : outil, jeu de règles, périmètre, horodatage.
Repérer un résultat qui ne se laisse pas interpréter, et ce qu'il faut alors vérifier.

Les quatre statuts

Deux statuts concluent, deux statuts refusent de conclure. C'est la première séparation à faire, et elle compte plus que la sévérité.

Statut	Ce que Pépin affirme	Ce que vous pouvez en faire
`pass`	la donnée nécessaire a été collectée, et elle est conforme	vous appuyer dessus
`fail`	l'écart est constaté, sur une ressource nommée	corriger, ou l'assumer par une dérogation
`not-applicable`	le contrôle ne concerne pas ce périmètre, et voici pourquoi	vérifier que la raison vous convient
`not-evaluated`	la donnée nécessaire manquait, et voici laquelle	rien, tant que vous ne l'avez pas collectée

Un cinquième statut, exempted, apparaît quand vous couvrez un écart par une dérogation. Il ne se confond jamais avec pass : l'écart reste visible, il est seulement assumé.

not-evaluated n'est pas un succès. Sur l'inventaire d'exemple du dépôt, 27 contrôles sont traités et 14 ressortent non évalués. Un outil qui les compterait comme conformes annoncerait un score de plus de 90 % là où la moitié du référentiel n'a pas été regardée.

C'est le raccourci le plus courant des tableaux de bord de conformité, et il produit exactement l'inverse de ce qu'on attend d'un audit : une assurance fondée sur ce qu'on n'a pas vu.

Lisez donc toujours la répartition complète avant le verdict :

pepin scan scaleway examples/scaleway/inventory.json -f assessment \
  | jq -r '.results[].status' | sort | uniq -c

Pourquoi un contrôle n'est pas évalué

Chaque non-évaluation porte sa raison, et les raisons ne se valent pas. Deux familles apparaissent, avec des conséquences opposées.

La première est bénigne : la ressource n'existe pas dans le périmètre.

compute_instance_has_security_group
  aucune ressource de type « compute_instance » dans l'inventaire évalué

Si votre inventaire ne contient aucune machine, un contrôle sur les machines n'a rien à examiner. Rien à corriger, sinon vérifier que l'absence est normale.

La seconde mérite votre attention : la donnée n'a pas pu être collectée.

governance_resource_required_tags
  collecte de la donnée nécessaire non confirmée pour ce fournisseur

Celle-là signale une limite réelle, du côté de l'outil, du fournisseur ou de vos droits. Sur une collecte live, c'est souvent une permission manquante : le scanner n'a pas pu lire, il ne conclut pas, et c'est le comportement attendu. Un compte insuffisamment autorisé ne doit jamais produire un pass.

Ce qu'un `not-applicable` vous apprend

Depuis la version 0.4.0, un contrôle non applicable dit pourquoi il ne s'applique pas, et la justification est souvent instructive.

blockstorage_volume_encryption
  Chiffrement au repos des volumes block côté invité (LUKS/Cryptsetup),
  responsabilité du client

Ce n'est pas une échappatoire : c'est une frontière du modèle de responsabilité partagée. Le contrôle ne s'applique pas au périmètre du fournisseur parce qu'il relève du vôtre, à l'intérieur de la machine. Lire ces justifications est le meilleur moyen de découvrir ce dont vous êtes responsable sans le savoir.

Sévérité et confiance : deux questions différentes

La sévérité dit ce que coûterait l'écart. La confiance dit à quel point on est sûr qu'il existe. Confondre les deux conduit à traiter en urgence une supposition, ou à négliger une certitude.

	Ce que ça mesure	Valeurs observées
`severity`	la gravité si l'écart est réel	`critical`, `high`, `medium`, `low`
`labels.confidence`	la certitude que l'écart est réel	`confirmed` sur les écarts de l'exemple

Sur l'inventaire d'exemple, les quatre écarts sortent en confirmed : ils reposent sur une donnée directement observée, une ACL publique ou une règle de pare-feu explicite. Il n'y a pas d'inférence.

La confiance n'est portée que par les écarts. Un pass n'en a pas, et c'est cohérent : la question « à quel point suis-je sûr qu'il n'y a rien » est déjà répondue par le statut lui-même, qui n'est accordé que si la donnée a été collectée.

La provenance : de quoi ce scan est-il la trace ?

Chaque résultat s'accompagne d'un bloc run qui permet de relire le scan des mois plus tard. C'est ce qui distingue un rapport d'une capture d'écran.

{
  "tool":    { "name": "pepin", "version": "0.4.0", "digest": "vcs:61e5de9…" },
  "ruleset": { "name": "pepin-config", "digest": "sha256:6eca0627…" },
  "target":  { "id": "scaleway", "provider": "scaleway" },
  "timestamp": "2026-09-09T05:25:56Z",
  "source": "export",
  "scope": {
    "included": ["access_key", "governance_provider",
                 "object_storage_bucket", "security_group_rule"]
  }
}

Quatre champs méritent d'être lus à chaque fois :

ruleset.digest identifie le jeu de règles exact. Deux scans qui divergent avec le même digest signalent un changement dans votre infrastructure ; avec des digests différents, la comparaison n'a pas de sens.
source dit d'où vient la donnée : un export, un plan Terraform ou une collecte live. Les trois ne prouvent pas la même chose.
scope.included énumère les types de ressources réellement examinés. C'est la contrepartie honnête du verdict : ce qui n'y figure pas n'a pas été regardé.
timestamp date l'observation. Un verdict conforme ne parle que de l'instant où il a été rendu.

Le verdict, et ce qu'il ne dit pas

La synthèse d'un scan conforme est délibérément prudente :

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

Trois précautions tiennent dans cette phrase. « Sur le périmètre évalué » renvoie à scope.included. « Aucune non-conformité détectée » n'est pas « aucune non-conformité ». Et le décompte des douze contrôles conformes vous dit sur quoi repose l'affirmation, ce qu'un pourcentage global masquerait.

Le rapport se termine d'ailleurs par un rappel qui vaut mise en garde :

Ce rapport évalue la configuration d'un tenant (périmètre commanditaire).
Les correspondances normatives (SecNumCloud, ISO, CIS) sont indicatives :
elles ne constituent pas une preuve de qualification/certification, laquelle
porte sur le prestataire de service cloud.

Les correspondances normatives

Chaque résultat porte ses références, sous forme structurée plutôt qu'en texte libre :

"references": [
  { "framework": "scsl",             "id": "CLD-IAM-2" },
  { "framework": "iso-27001",        "id": "A.5.17" },
  { "framework": "secnumcloud-3.2",  "id": "9.5" }
]

Le code scsl est celui du référentiel commun, et il renvoie à une exigence publiée. Depuis la version 0.4.0, le lien affiché sous chaque écart résout correctement vers la page de la famille concernée et son ancre :

↳ docs: …/socle/referentiel/cloud/iam-acces-cloud/#socle-cld-iam-2

Choisir son format de sortie

Cinq formats, trois usages. La sortie lisible ne montre que les écarts ; c'est pratique au quotidien et trompeur pour un audit, puisqu'elle tait les non-évaluations.

Format	Pour quoi faire
`table`	lecture humaine au quotidien, écarts uniquement
`assessment`	la vérité complète : les quatre statuts, la provenance, les références
`json`	traitement par script
`oscal`	échange avec un outil de conformité, au format OSCAL 1.1.2
`sarif`	remontée dans l'interface de revue de code

Pour juger d'une posture, prenez assessment. C'est le seul qui vous montre ce que le scan n'a pas pu regarder.

Pièges courants

Symptôme	Cause	Ce qu'il faut faire
Un score flatteur alors que rien n'a changé	les `not-evaluated` sont comptés comme conformes	relire la répartition des statuts, pas le seul verdict
Beaucoup de `not-evaluated` sur une collecte live	droits de lecture insuffisants sur l'API	compléter la politique du compte d'audit, puis relancer
Deux scans incomparables	`ruleset.digest` différent d'un scan à l'autre	figer le jeu de règles avant de comparer
Un contrôle « non applicable » suspect	la justification révèle une frontière de responsabilité	lire la raison, elle indique souvent une tâche à votre charge
Un écart jugé faux	la sévérité est lue comme une certitude	vérifier `labels.confidence` avant d'arbitrer

À retenir

Deux statuts concluent, deux refusent de conclure. pass et fail affirment, not-applicable et not-evaluated expliquent pourquoi ils s'abstiennent.
not-evaluated n'est jamais un succès. Sur l'exemple du dépôt, 14 contrôles sur 27 sont dans ce cas.
Une non-évaluation a deux causes très différentes : la ressource est absente du périmètre, ou la donnée n'a pas pu être collectée. Seule la seconde demande une action.
Depuis la 0.4.0, un not-applicable se justifie, et la justification révèle souvent une frontière du modèle de responsabilité partagée.
La sévérité dit la gravité, la confiance dit la certitude. Les écarts de l'exemple sortent en confirmed, sans inférence.
Le bloc run rend un scan relisible : version de l'outil, empreinte du jeu de règles, source, périmètre examiné, horodatage.
scope.included est la contrepartie du verdict : ce qui n'y figure pas n'a pas été regardé.
Pour juger une posture, utilisez assessment, le seul format qui montre les quatre statuts.

Ressources externes

Spécification OSCAL 1.1.2 : le modèle d'échange derrière le format oscal.
Spécification SARIF : le format attendu par les interfaces de revue de code.
Référentiel SOCLE, domaine cloud : les exigences vers lesquelles pointent les codes CLD-.