Fiche 20 — Chaîne vérifiable, runtime cloud-native, plateforme & culture

Trois blocs : (A) prouver l’intégrité de ce qu’on livre · (B) sécuriser ce qui tourne · (C) faire adopter le tout. Le bloc C est celui qui décide de la réussite d’une mission.

A. Chaîne d’approvisionnement vérifiable

A.1 SLSA — le référentiel à connaître ⭐

SLSA (Supply-chain Levels for Software Artifacts, OpenSSF) : cadre de garanties sur la provenance d’un artefact. Version 1.0, piste Build :

Niveau	Exigence	Traduction concrète
L1	Provenance générée et disponible	Le build produit un document décrivant comment il a été fait
L2	Provenance signée, build hébergé	Un service de build authentifié signe l’attestation
L3	Build isolé et non falsifiable	Le processus de build ne peut pas influencer sa propre provenance ; secrets de signature inaccessibles au code utilisateur

À savoir dire : « La plupart des organisations sont à L0. Passer à L1-L2 est réaliste en quelques semaines avec slsa-github-generator ou les attestations GitLab ; L3 demande une refonte de la plateforme de build. »

A.2 Signature & vérification (Sigstore)

cosign signe images, SBOM, attestations. Keyless signing : identité OIDC du pipeline au lieu d’une clé privée à protéger → transparence via le log Rekor, racine Fulcio.

Chaîne complète à décrire :

build → SBOM (syft) → scan (trivy) → attestations (in-toto/SLSA)
      → cosign sign + cosign attest → push registre
      → cosign verify à l'admission Kubernetes  ← le maillon souvent oublié

Signer sans vérifier ne sert à rien. La vérification se fait à l’admission : Kyverno (verifyImages), Sigstore policy-controller, Connaisseur, ou Binary Authorization (GCP) / Notation (Azure).

# Kyverno : n'admettre que les images signées par notre pipeline
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:{name: verify-image-signature}
spec:
validationFailureAction: Enforce
rules:
-name: verify-signature
match:{any:[{resources:{kinds:[Pod]}}]}
verifyImages:
-imageReferences:["registry.example.com/*"]
attestors:
-entries:
-keyless:
subject:"<https://gitlab.example.com/platform/*>"
issuer:"<https://gitlab.example.com>"

A.3 SBOM & VEX en pratique

SBOM : CycloneDX (plus riche pour la sécurité) ou SPDX (plus orienté licences). Généré au build (pas a posteriori), stocké comme artefact attaché à l’image, versionné.
Un SBOM n’a de valeur que s’il est consommé : rapproché en continu des bases de vulnérabilités, ce qui permet de répondre en 10 minutes à « sommes-nous exposés à cette nouvelle CVE ? » — la question posée un vendredi soir de Log4Shell. C’est l’argument de vente du SBOM, pas la conformité CRA. ⭐
VEX : dire « ce CVE nous concerne / ne nous concerne pas parce que… » — indispensable pour ne pas subir les questions clients à chaque CVE médiatique.
CRA : rend le SBOM et le traitement des vulnérabilités obligatoires pour les produits numériques mis sur le marché UE (notification à partir de sept. 2026, application pleine déc. 2027 — cf. fiche 02). Argument commercial fort auprès des éditeurs et industriels.

A.4 Registre & artefacts

Registre interne obligatoire · immuabilité des tags · déploiement par digest et jamais par tag · rétention/nettoyage · scan continu du registre (pas seulement au build : une image saine hier ne l’est plus demain) · séparation registre de dev / registre de prod avec promotion contrôlée · pas de :latest en production.