Attestation cryptographique dans les pipelines CI/CD

Attestation cryptographique dans les pipelines CI/CD

SolarWinds. XZ Utils. 3CX. Chaque attaque supply chain majeure des cinq dernières années partage un point commun : l'artefact malveillant avait traversé le pipeline de build sans déclencher d'alerte, parce que personne ne vérifiait cryptographiquement ce qui sortait du pipeline ni ce qui y entrait.

L'attestation cryptographique est la réponse technique à ce problème. Ce n'est pas une option — c'est devenu une exigence de sécurité fondamentale pour tout pipeline CI/CD exposé.

Anatomie des attaques supply chain

SolarWinds (2020) : les attaquants ont compromis le système de build d'Orion et injecté du code malveillant directement dans le processus de compilation. Le binaire signé avec le certificat légitime de SolarWinds distribuait une backdoor à 18 000 organisations.

XZ Utils (2024) : deux ans d'ingénierie sociale pour devenir mainteneur d'une librairie critique, puis injection d'une backdoor dans le processus de release. Le code malveillant était dans les artefacts de distribution mais pas dans le code source versionné — contournant délibérément les reviews.

Pattern commun : l'attaque cible le pipeline, pas le code. La signature du binaire final ne prouve rien sur l'intégrité du processus qui l'a produit.

SLSA : Supply-chain Levels for Software Artifacts

SLSA (prononcé "salsa") est un framework de Google qui définit des niveaux progressifs de sécurité supply chain :

SLSA Build L1 — Provenance générée par le builder
SLSA Build L2 — Provenance signée par le builder hébergé
SLSA Build L3 — Build isolé, paramètres vérifiables, sources vérifiées

Note : SLSA v1.0 a restructuré les tracks. L'ancienne classification 0.x (Level 1 à 4) est conservée dans certains outils et documentations historiques ; le track Build officiel actuel est L1–L3.

La provenance est le document qui décrit comment un artefact a été produit : quel code source, quel builder, quels paramètres, à quelle heure. Signée cryptographiquement, elle permet de vérifier après coup que l'artefact correspond bien à ce qui était attendu.

Signatures Ed25519 et Sigstore

Ed25519 est l'algorithme de signature recommandé pour l'attestation : performances excellentes, résistance aux attaques par timing, clés courtes (32 bytes).

Le problème des clés : la signature ne vaut que si la clé privée est protégée. Les stocker dans des secrets CI/CD est une surface d'attaque. Sigstore résout ce problème avec des signatures éphémères liées à l'identité OIDC.

# Exemple complet GitHub Actions — signature keyless via OIDC
jobs:
  sign:
    permissions:
      id-token: write # requis pour obtenir le token OIDC
      contents: read
    steps:
      - uses: sigstore/cosign-installer@v3
 
      - name: Sign image
        run: |
          cosign sign --yes \
            registry.alien6.io/app:v1.2.3@sha256:abc123...

# Vérifier l'image avant déploiement
cosign verify \
  --certificate-identity="https://github.com/alien6-studio/app/.github/workflows/release.yml@refs/tags/v1.2.3" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  registry.alien6.io/app:v1.2.3

Attestations dans GitHub Actions

# .github/workflows/release.yml
jobs:
  attest:
    permissions:
      id-token: write # requis pour la signature OIDC
      attestations: write # requis pour écrire l'attestation
      contents: read
 
    steps:
      - name: Generate SLSA provenance attestation
        uses: actions/attest-build-provenance@v2
        with:
          subject-name: registry.alien6.io/app
          subject-digest: ${{ steps.build.outputs.digest }}
          push-to-registry: true
          # Note : push-to-registry pousse l'attestation sur le registre
          # mais ne suffit pas — vérifier via cosign ou gh attestation verify
 
      - name: Sign image with Sigstore
        run: |
          cosign sign --yes \
            registry.alien6.io/app@${{ steps.build.outputs.digest }}

Intégration dans le déploiement

L'attestation n'a de valeur que si elle est vérifiée avant le déploiement. La policy enforcement se fait au niveau de l'admission controller Kubernetes :

# Policy Kyverno : rejeter les images non signées
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  rules:
    - name: check-image-signature
      match:
        resources:
          kinds: ['Pod']
      verifyImages:
        - imageReferences: ['registry.alien6.io/*']
          attestors:
            - entries:
                - keyless:
                    issuer: 'https://token.actions.githubusercontent.com'
                    subject: 'https://github.com/alien6-studio/*'

Recommandations d'implémentation

1. Commencez par SLSA Level 2 : provenance signée sur tous les artefacts de production. C'est accessible en une journée avec GitHub Actions.
2. Adoptez le pinning par digest (pas par tag) dans vos manifests de déploiement — image@sha256:... est immuable, un tag ne l'est pas.
3. Auditez vos dépendances : les outils du pipeline lui-même (actions, orbs, buildpacks) sont aussi des vecteurs. Vérifiez qu'ils sont eux-mêmes signés.
4. Déployez un admission controller qui refuse les images sans attestation valide — la signature sur le registre ne suffit pas si elle n'est jamais vérifiée.

L'attestation cryptographique ne rend pas l'attaque impossible. Elle améliore fortement la vérifiabilité, l'auditabilité et la détection de tampering — rendant la falsification calculatoirement infaisable et les compromissions de pipeline beaucoup plus difficiles à dissimuler.