SLSA : sécuriser la chaîne d'approvisionnement logicielle

Mise à jour : 30/12/2025

Il y a quelques années, les pipelines CI/CD étaient considérés comme sûrs par défaut. Personne ne se demandait vraiment si le code compilé correspondait exactement au code source versionné. Aujourd’hui, avec des attaques comme SolarWinds, nous savons que chaque maillon de la chaîne peut être compromis : du commit initial jusqu’à l’artefact final.

SLSA (Supply-chain Levels for Software Artifacts, prononcé “salsa”) apporte une réponse structurée à ce problème. Ce framework définit des exigences progressives pour sécuriser l’ensemble du cycle de vie du logiciel.

Le framework est porté par l’OpenSSF (Open Source Security Foundation) et s’adresse aux équipes DevOps, systèmes et sécurité. SLSA ne dicte pas d’outils spécifiques : il définit des principes applicables à tous les pipelines CI/CD, quelle que soit la technologie utilisée.

Pourquoi la sécurité de la supply chain est devenue critique

Les applications modernes ne sont plus des blocs monolithiques écrits de A à Z par une seule équipe. Elles reposent sur de nombreux éléments externes : bibliothèques open source, images de conteneurs, outils de build, scripts automatisés. L’ensemble de ces composants forme ce qu’on appelle la chaîne d’approvisionnement logicielle (software supply chain).

Chaque maillon de cette chaîne représente un point d’entrée potentiel pour un attaquant :

Code source : les dépôts Git contiennent le code, les branches, les commits et les tags. Un attaquant qui accède au dépôt peut modifier le code sans que personne ne s’en aperçoive.
Pipelines CI/CD : GitHub Actions, GitLab CI, Jenkins exécutent des scripts automatisés. Un pipeline compromis peut injecter du code malveillant pendant la compilation.
Secrets : tokens d’API, clés SSH, certificats de signature. Leur vol permet de publier des versions malveillantes avec une apparence légitime.
Artefacts : images de conteneurs, binaires, packages npm/pip/Maven. Une fois publiés, ils sont téléchargés par des milliers d’utilisateurs.

Le problème majeur : si un pipeline est compromis, un logiciel peut être modifié sans toucher au dépôt Git. Le code source reste intact, mais l’artefact distribué contient du code malveillant. C’est exactement ce qui s’est passé avec SolarWinds.

SLSA introduit des mécanismes de contrôle et de traçabilité pour détecter ces manipulations. L’idée centrale : ne plus faire confiance aveuglément, mais exiger des preuves vérifiables à chaque étape.

Modèle de la chaîne d'approvisionnement logicielle

Quelles menaces SLSA permet-il de contrer ?

Pour comprendre la valeur de SLSA, examinons les attaques réelles qu’il permet de détecter ou de prévenir. Le framework découpe la chaîne d’approvisionnement en composantes, chacune pouvant être la cible d’attaques spécifiques.

Modèle des menaces sur la chaîne d'approvisionnement logicielle

Menaces sur le code source

Ces attaques ciblent le dépôt Git et le code avant même qu’il soit compilé.

Menace	Ce que fait l’attaquant	Comment SLSA protège
(A) Changement non autorisé	Soumet du code malveillant dans le dépôt	Source L4 exige une revue à deux personnes, rendant l’injection beaucoup plus difficile
(B) Dépôt compromis	Pirate le serveur Git pour modifier l’historique	Source L2+ génère des attestations signées qui détectent les modifications
(C) Build depuis code modifié	Compile depuis du code non versionné ou modifié localement	Build L1+ inclut le commit source dans la provenance, permettant la vérification

Exemple réel : PHP (2021)

En mars 2021, des attaquants ont compromis le serveur Git auto-hébergé de PHP et injecté deux commits malveillants dans la branche principale. Ces commits ajoutaient une backdoor au langage PHP lui-même. Heureusement, les mainteneurs ont détecté l’attaque rapidement grâce à leur processus de review.

Avec Source L4, cette attaque aurait été beaucoup plus difficile : chaque commit aurait nécessité l’approbation de deux personnes distinctes.

Source : php.internals ↗

Menaces sur le build

Ces attaques ciblent le pipeline de compilation et la génération des artefacts.

Menace	Ce que fait l’attaquant	Comment SLSA protège
(E) Build compromis	Modifie le processus de build pour injecter du code	Build L2+ signe la provenance, détectant les modifications
(F) Upload modifié	Remplace l’artefact entre le build et la publication	Build L1+ permet de vérifier que l’artefact correspond à la provenance

Exemple réel : SolarWinds (2020)

L’attaque SolarWinds est l’exemple parfait de compromission du build. Les attaquants ont infiltré le système de build de SolarWinds et modifié le processus de compilation pour injecter du code malveillant dans les mises à jour du logiciel Orion. Le code source était propre, mais les binaires distribués contenaient une backdoor.

18 000 organisations ont installé la mise à jour compromise, dont des agences gouvernementales américaines.

Avec Build L3, cette attaque aurait été détectable : l’isolation des builds aurait empêché l’injection, ou au minimum, la provenance aurait révélé des anomalies.

En savoir plus sur SolarWinds

Menaces sur les dépendances et les registries

Ces attaques ciblent les composants externes et les dépôts de packages.

Menace	Ce que fait l’attaquant	Comment SLSA protège
(D) Dépendance compromise	Publie une version malveillante d’une dépendance	SLSA appliqué récursivement aux dépendances
(G) Registry compromise	Modifie un package directement sur npm/PyPI/Docker Hub	La provenance permet de vérifier l’origine
(H) Typosquatting	Publie un package au nom similaire (ex: `lodash` vs `1odash`)	Détection facilitée par la vérification de provenance

Exemple réel : event-stream (2018)

Un attaquant a d’abord gagné la confiance du mainteneur du package npm event-stream (200 millions de téléchargements hebdomadaires). Une fois mainteneur, il a ajouté une dépendance innocente flatmap-stream. Quelques semaines plus tard, il a publié une mise à jour de cette dépendance contenant du code malveillant ciblant les portefeuilles Bitcoin.

L’attaque est passée inaperçue pendant des mois car le code malveillant était obfusqué et ne s’activait que dans des conditions spécifiques.

Source : analyse détaillée ↗

Comprendre les deux tracks de SLSA

SLSA organise ses exigences en deux tracks (pistes) complémentaires. Chaque track adresse une partie différente de la chaîne d’approvisionnement :

Track	Ce qu’il protège	Niveaux disponibles
Source Track	Le code source et son intégrité	L1 → L4
Build Track	La construction des artefacts	L0 → L3

Pourquoi deux tracks ? Parce que sécuriser uniquement le build ne suffit pas. Si le code source lui-même est compromis (commit malveillant, dépôt piraté), même le meilleur pipeline de build produira un artefact dangereux. Inversement, sécuriser le code source sans contrôler le build laisse la porte ouverte aux injections pendant la compilation.

Les deux tracks fonctionnent ensemble pour couvrir l’ensemble du cycle : Source Track garantit l’intégrité du code en amont, Build Track garantit l’intégrité de la construction en aval.

Source Track : sécuriser le code source

Le Source Track définit des niveaux croissants de confiance dans la gestion du code source. Il répond à la question : peut-on prouver que le code source utilisé pour le build est bien celui qui a été approuvé par l’équipe ?

Voici les quatre niveaux du Source Track, du plus basique au plus exigeant :

Niveau	Nom court	Ce que ça signifie concrètement
L1	Version controlled	Le code est dans un système de versioning (Git, etc.)
L2	History & Provenance	L’historique est préservé et des attestations sont générées
L3	Continuous controls	Des contrôles techniques automatiques sont appliqués
L4	Two-party review	Chaque changement nécessite l’approbation de deux personnes

Source L1 : le code est versionné

Le premier niveau peut sembler évident, mais il est fondamental. À ce niveau, le code source doit être stocké et géré dans un système de contrôle de version moderne comme Git, Mercurial ou Subversion.

Pourquoi c’est important ? Sans versioning, impossible de savoir qui a modifié quoi, quand, et pourquoi. Les modifications sont invisibles. Avec un système de versioning, chaque changement est enregistré avec un identifiant unique (le hash du commit), l’auteur, la date et le message de commit.

Ce que vous devez mettre en place :

Utiliser Git (ou équivalent) pour tout le code source
Ne jamais modifier les fichiers directement sur le serveur de production
Versionner également les scripts de déploiement et les configurations

À qui s’adresse ce niveau ? Aux organisations qui ont encore du code géré de manière non standard (fichiers partagés sur un disque réseau, FTP, etc.). C’est la première étape indispensable vers SLSA.

Source L2 : historique fiable et provenance source

Le niveau 2 ajoute des garanties sur l’intégrité de l’historique. Il ne suffit plus d’avoir un historique : il faut pouvoir prouver qu’il n’a pas été altéré.

Le problème que ça résout : dans Git, il est techniquement possible de réécrire l’historique (force push, rebase, etc.). Un attaquant avec accès au dépôt pourrait modifier des commits anciens pour cacher ses traces. Au niveau 2, l’historique doit être continu, immuable et conservé.

Ce que vous obtenez :

L’historique complet des modifications est préservé et ne peut pas être réécrit
Le système de contrôle source génère des attestations de provenance source : des documents signés qui certifient l’origine du code
Ces attestations constituent des preuves résistantes à la falsification

Ce que vous devez mettre en place :

Activer la protection des branches principales (interdire le force push sur main)
Configurer la rétention de l’historique Git
Mettre en place un système de génération d’attestations (si votre plateforme le supporte)

À qui s’adresse ce niveau ? À toutes les organisations qui produisent du logiciel. C’est le niveau minimum recommandé pour les applications en production.

Source L3 : contrôles techniques continus

Le niveau 3 introduit l’application automatique de règles définies par l’organisation. Ce n’est plus seulement “l’historique est préservé”, mais “des contrôles sont activement appliqués et vérifiables”.

Le problème que ça résout : une organisation peut avoir des règles (obligation de review, interdiction de merge sans tests verts), mais rien ne prouve qu’elles ont été respectées. Un administrateur avec les bons droits peut contourner ces règles. Au niveau 3, le système de contrôle source (SCS) enregistre dans les attestations les contrôles qui ont été appliqués.

Ce que vous obtenez :

Les politiques de branche sont appliquées techniquement (pas seulement documentées)
Les attestations de provenance incluent la preuve des contrôles appliqués
Les consommateurs du code peuvent vérifier que les contrôles ont été respectés

Ce que vous devez mettre en place :

Configurer les branch protection rules avec enforcement strict
Exiger le passage des tests avant merge
Exiger au moins une approbation de review
S’assurer que votre plateforme documente ces contrôles dans les attestations

À qui s’adresse ce niveau ? Aux organisations souhaitant prouver à leurs clients ou partenaires que leurs processus de développement respectent des standards de sécurité.

Source L4 : revue obligatoire par deux personnes

Le niveau 4, le plus exigeant, impose une revue à deux personnes pour chaque modification du code sur les branches protégées.

Le problème que ça résout : avec une seule personne en review, cette personne peut être compromise (compte piraté, insider malveillant, erreur d’inattention). Avec deux personnes, la probabilité de collusion ou de double compromission diminue drastiquement.

Ce que vous obtenez :

Chaque changement nécessite l’approbation de deux personnes de confiance distinctes avant d’être intégré
Protection contre les changements unilatéraux, même par les administrateurs
Résistance aux menaces internes (un développeur malveillant seul ne peut rien faire)

Ce que vous devez mettre en place :

Configurer les règles de branche pour exiger 2 approbations minimum
S’assurer que l’auteur du code ne peut pas être l’un des approbateurs
Mettre en place des processus pour gérer les urgences (hotfixes) tout en respectant le principe des 4 yeux

À qui s’adresse ce niveau ? Aux organisations avec des exigences de sécurité élevées : logiciels critiques, infrastructures sensibles, conformité réglementaire stricte.

Build Track : sécuriser la construction

Le Build Track définit des niveaux croissants de confiance dans la construction des artefacts. Il répond à la question : peut-on prouver que cet artefact a bien été construit à partir de ce code source, sans modification ?

La notion centrale du Build Track est la provenance : un document qui décrit exactement comment un artefact a été produit. Plus le niveau est élevé, plus la provenance est fiable et difficile à falsifier.

Voici les quatre niveaux du Build Track :

Niveau	Nom court	Ce que ça signifie concrètement
L0	No guarantees	Aucune garantie (build local, pas de traçabilité)
L1	Provenance exists	Une provenance est générée, mais peut être falsifiée
L2	Hosted build platform	La provenance est signée par une plateforme hébergée
L3	Hardened builds	Le build est isolé et protégé contre les manipulations

Build L0 : aucune garantie

Le niveau 0 correspond à l’absence de contrôle. C’est le point de départ de nombreuses organisations qui n’ont pas encore formalisé leur chaîne de build.

Ce que ça signifie en pratique :

Les builds peuvent être lancés depuis le poste d’un développeur
Aucune provenance n’est générée
Impossible de savoir qui a construit quoi, quand, et à partir de quel code

Pourquoi c’est problématique ? Un développeur malveillant (ou dont le poste est compromis) peut publier un artefact contenant du code malveillant. Personne ne peut vérifier que l’artefact correspond au code source.

À qui correspond ce niveau ? Aux projets en phase de développement exploratoire, aux prototypes, aux outils internes non critiques. Ce niveau n’est pas acceptable pour du logiciel en production.

Build L1 : la provenance existe

Le niveau 1 marque l’entrée dans SLSA. À ce niveau, le processus de build génère une provenance : un document qui décrit comment l’artefact a été construit.

Ce que vous obtenez :

Le build est exécuté par un pipeline CI/CD (pas sur un poste local)
Une provenance est générée automatiquement
La provenance établit un lien entre le code source (commit) et l’artefact

Ce que contient la provenance :

L’identifiant du commit source (SHA Git)
Le dépôt d’origine
L’horodatage du build
L’outil de build utilisé

Limitation importante : à ce niveau, la provenance peut être falsifiée. Un acteur malveillant ayant accès au pipeline peut modifier la provenance pour faire croire que l’artefact vient d’un autre commit.

À qui s’adresse ce niveau ? Aux équipes souhaitant gagner rapidement les bénéfices de SLSA sans refondre leur infrastructure. C’est un bon point de départ.

Build L2 : plateforme de build hébergée

Le niveau 2 ajoute une couche de sécurité cruciale : la provenance est générée et signée cryptographiquement par une plateforme de build hébergée.

Le problème que ça résout : au niveau 1, n’importe qui avec accès au pipeline peut générer une fausse provenance. Au niveau 2, seule la plateforme de build peut signer la provenance avec sa clé privée. Cette signature prouve l’authenticité.

Ce que vous obtenez :

La provenance est signée par la plateforme (GitHub, GitLab, Google Cloud Build, etc.)
Le build s’exécute sur une infrastructure dédiée, pas sur le poste d’un développeur
Les consommateurs peuvent vérifier la signature pour s’assurer de l’authenticité

Ce que ça protège contre : la falsification après le build. Une fois l’artefact construit et la provenance signée, il devient très difficile de les modifier sans invalider la signature.

Ce que vous devez mettre en place :

Utiliser une plateforme CI/CD hébergée (GitHub Actions, GitLab CI, etc.)
Configurer la génération de provenance signée (selon les capacités de votre plateforme)
Stocker la provenance avec l’artefact

À qui s’adresse ce niveau ? Aux équipes ayant migré vers une plateforme hébergée et souhaitant une garantie d’authenticité. C’est le niveau minimum recommandé pour les applications critiques.

Build L3 : builds durcis ⭐

Le niveau 3, le plus élevé du Build Track, offre une protection forte contre les manipulations pendant le build lui-même.

Le problème que ça résout : au niveau 2, le build s’exécute sur une plateforme hébergée, mais cette plateforme pourrait être compromise. Un attaquant avec accès à l’infrastructure de build pourrait modifier le processus de compilation. Au niveau 3, des mesures d’isolation empêchent ces attaques.

Ce que vous obtenez :

Isolation totale entre les builds : un build ne peut pas influencer un autre
Secrets de signature inaccessibles : les clés utilisées pour signer la provenance ne sont jamais accessibles au code du build
Auditabilité complète : chaque action est journalisée et vérifiable

Ce que ça protège contre :

Les menaces internes (employé malveillant avec accès à l’infrastructure)
Les credentials compromis (même avec un token volé, l’attaquant ne peut pas forger une provenance valide)
Les attaques cross-tenant (un client malveillant de la plateforme ne peut pas compromettre les builds d’un autre client)

Plateformes atteignant Build L3 :

GitHub Actions (avec slsa-github-generator)
Google Cloud Build

À qui s’adresse ce niveau ? C’est le niveau cible recommandé pour la majorité des releases logicielles. Si vous publiez des artefacts utilisés par d’autres (bibliothèques, images Docker, packages), visez Build L3.

La provenance : le cœur du système SLSA

Maintenant que vous comprenez les deux tracks, parlons de la provenance, le concept central qui fait fonctionner tout le système SLSA.

La provenance est une métadonnée structurée qui décrit précisément comment un artefact a été produit. Pensez-y comme un certificat de naissance pour votre logiciel : il indique son origine, les circonstances de sa création, et qui était présent.

Ce que contient une provenance :

Origine du code : l’identifiant exact du commit Git (SHA), la branche, le tag, l’URL du dépôt
Outil de build : Make, Maven, npm, Docker, Gradle, et leurs versions
Environnement d’exécution : système d’exploitation, version, identifiant du runner CI, horodatage précis
Identité du système de build : quelle plateforme a généré la provenance, avec quelle clé de signature

Pourquoi c’est révolutionnaire ? Avant SLSA, un binaire ou une image Docker était une boîte noire. Impossible de savoir avec certitude d’où il venait. Avec la provenance, tout consommateur peut vérifier :

Qui a construit l’artefact (quelle plateforme CI/CD)
Où le build a été exécuté (quel runner, quelle infrastructure)
Quand il a été produit (horodatage précis)
À partir de quoi (le commit exact du code source)
Comment (les commandes, outils et versions utilisés)

La provenance devient ainsi la preuve cryptographique de l’intégrité du processus de build. Si quelqu’un modifie l’artefact après coup, la signature de la provenance ne correspondra plus.

Mettre en place SLSA : guide étape par étape

Passons à la pratique. Comment implémenter SLSA dans votre organisation ? L’approche recommandée est progressive : commencez par un audit, puis montez en maturité étape par étape.

Étape 1 : Auditer vos pipelines existants

Avant de modifier quoi que ce soit, faites un état des lieux. Vous devez comprendre comment vos logiciels sont actuellement construits et publiés.

# Listez tous vos pipelines CI/CD
find .github/workflows -name "*.yml" -type f
ls .gitlab-ci.yml 2>/dev/null

# Recherchez les builds potentiellement manuels
grep -r "docker build" . --include="*.sh"
grep -r "npm publish" . --include="*.sh"
grep -r "mvn deploy" . --include="*.sh"

Questions à vous poser pendant l’audit :

Combien de pipelines génèrent des artefacts publiés (images Docker, packages npm, binaires) ?
Lesquels sont critiques pour votre business ou vos clients ?
Y a-t-il des étapes manuelles dans le processus de release ?
Vos artefacts sont-ils signés ? Si oui, où sont stockées les clés ?
Qui a accès aux secrets du pipeline ?

Documentez vos découvertes. Cet audit servira de base pour prioriser les améliorations.

Étape 2 : Automatiser complètement les builds

L’automatisation est le prérequis à tout le reste. Aucune intervention manuelle ne doit être possible dans le chemin critique du build à la publication.

Objectif : tout build publié doit passer par un pipeline CI/CD, sans exception.

GitHub Actions
GitLab CI

name: Build and publish
on:
  push:
    branches: [main]
    tags: ['v*']

# Principe du moindre privilège : permissions minimales par défaut
permissions:
  contents: read

jobs:
  build:
    # Toujours utiliser une version fixe du runner, jamais 'latest'
    runs-on: ubuntu-24.04
    steps:
      - name: Checkout code
        # Toujours épingler les actions par SHA, pas par tag
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

      - name: Build application
        run: make build

      - name: Run tests
        run: make test

      - name: Build Docker image
        run: docker build -t myapp:${{ github.sha }} .

stages:
  - build
  - test
  - publish

build:
  stage: build
  script:
    - make build
  artifacts:
    paths:
      - dist/

test:
  stage: test
  script:
    - make test

publish:
  stage: publish
  script:
    - docker build -t myapp:$CI_COMMIT_SHA .
  only:
    - main
    - tags

Vérification : après cette étape, personne ne devrait pouvoir publier un artefact sans passer par le pipeline.

Étape 3 : Générer la provenance (atteindre Build L3)

Si vous utilisez GitHub Actions, vous pouvez atteindre directement Build L3 grâce au projet slsa-github-generator ↗. Ce générateur produit une provenance signée conforme aux exigences SLSA.

name: Release with SLSA provenance

on:
  push:
    tags: ['v*']

# Principe du moindre privilège : permissions minimales par défaut
permissions:
  contents: read

jobs:
  build:
    # Toujours utiliser une version fixe du runner, jamais 'latest'
    runs-on: ubuntu-24.04
    outputs:
      digest: ${{ steps.push.outputs.digest }}
    steps:
      # Toujours épingler les actions par SHA, pas par tag
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

      - name: Build image
        run: docker build -t ghcr.io/${{ github.repository }}:build .

      - name: Push image and capture digest
        id: push
        run: |
          # Pousser l'image et récupérer le digest immuable
          docker push ghcr.io/${{ github.repository }}:build
          DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' ghcr.io/${{ github.repository }}:build | cut -d'@' -f2)
          echo "digest=$DIGEST" >> $GITHUB_OUTPUT
          # À partir d'ici, TOUJOURS référencer l'image par son digest, pas par tag

  provenance:
    needs: build
    permissions:
      id-token: write   # Nécessaire pour la signature OIDC
      contents: read
      actions: read
    # Épingler par SHA pour l'immuabilité (vérifier les releases sur GitHub)
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v2.1.0
    with:
      # Référence par digest (immuable), jamais par tag
      image: ghcr.io/${{ github.repository }}
      digest: ${{ needs.build.outputs.digest }}

Ce que fait ce workflow :

Construit et pousse l’image Docker
Appelle le générateur SLSA qui produit une provenance signée
La provenance est attachée à l’image via les signatures OCI

Étape 4 : Signer vos artefacts avec Cosign

En complément de la provenance SLSA, signez vos images avec Cosign. Cosign permet une signature keyless (sans gestion de clés) grâce à l’authentification OIDC.

# Dans votre pipeline CI/CD
# La signature utilise automatiquement l'identité OIDC du runner
cosign sign --yes ghcr.io/user/myapp@sha256:abc123...

Pourquoi signer en plus de la provenance ? La signature Cosign ajoute une couche de vérification supplémentaire. Elle lie l’artefact à l’identité du pipeline qui l’a construit (via le token OIDC). C’est une défense en profondeur.

Étape 5 : Vérifier avant chaque déploiement

Modèle de vérification SLSA

Ce schéma illustre le flux de vérification SLSA côté consommateur :

Build (boîtes rouges en haut) : plusieurs systèmes de build produisent des artefacts. Chacun génère sa propre provenance.
Provenance (boîte jaune gauche) : document signé attestant l’origine et le processus de construction.
Paquet (boîte jaune droite) : l’artefact distribué via l’écosystème de paquets.
Exigences (boîte verte) : les critères définis par le consommateur (ex : “doit provenir de GitHub Actions”, “doit être signé”).
Vérification automatique (boîte cyan) : le processus qui compare la provenance aux exigences avant d’autoriser l’utilisation.

Le consommateur ne fait jamais confiance aveuglément à un paquet. Il exige une provenance valide et vérifie automatiquement qu’elle correspond à ses attentes.

La génération de provenance ne sert à rien si personne ne la vérifie. Ajoutez une étape de vérification obligatoire avant tout déploiement.

# Vérifier la signature Cosign
# Cette commande échoue si la signature est invalide ou absente
cosign verify ghcr.io/user/myapp@sha256:abc123... \
  --certificate-identity-regexp="^https://github.com/user/myapp" \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com

# Vérifier la provenance SLSA
# Cette commande échoue si la provenance ne correspond pas aux attentes
slsa-verifier verify-image ghcr.io/user/myapp@sha256:abc123... \
  --source-uri github.com/user/myapp \
  --source-tag v1.0.0

Intégration dans Kubernetes : vous pouvez utiliser des admission controllers comme Kyverno ou Sigstore Policy Controller pour bloquer automatiquement le déploiement d’images non signées ou sans provenance valide.

Quel niveau SLSA par plateforme CI/CD ?

Toutes les plateformes CI/CD ne permettent pas d’atteindre les mêmes niveaux SLSA. Voici un récapitulatif basé sur la documentation officielle de chaque plateforme.

Plateforme	Build Track	Source Track	Source
GitHub Actions	L3	L3	GitHub Blog ↗
Google Cloud Build	L3	-	Google Cloud Docs ↗
GitLab CI	L1	L3	GitLab Docs ↗
Jenkins	L1	-	Jenkins Plugin ↗

Détail des sources :

GitHub Actions : le GitHub Blog officiel ↗ annonce explicitement “reach SLSA Level 3” avec les Artifact Attestations. Le projet slsa-github-generator ↗ est documenté sur slsa.dev.
Google Cloud Build : la documentation officielle ↗ indique “Cloud Build features meet the requirements of SLSA level 3”. Voir aussi l’article slsa.dev sur GCB ↗.
GitLab CI : la documentation officielle ↗ indique clairement “SLSA Level 1 compliant provenance statement”. GitLab ne signe pas la provenance avec ses propres clés (requis pour L2+).
Jenkins : le plugin SLSA ↗ et le générateur sur GitHub ↗ sont des “proof-of-concept”. Jenkins n’offre pas d’isolation native des builds.

Que faire si votre plateforme ne supporte pas L3 ?

Si vous êtes sur GitLab ou Jenkins, vous pouvez tout de même améliorer votre posture :

Maximiser le Source Track : GitLab excelle sur les protected branches et les merge request approvals (Source L3-L4)
Ajouter des signatures Cosign : signez vos artefacts indépendamment de la plateforme
Utiliser des outils tiers : des solutions comme Legit Security ou Sigstore peuvent compléter les lacunes
Évaluer une migration : si la criticité de vos applications l’exige, GitHub Actions ou Google Cloud Build offrent L3 nativement

Adopter SLSA progressivement : feuille de route

SLSA est un marathon, pas un sprint. Tenter d’atteindre L3 partout en une semaine est une recette pour l’échec. Voici une approche réaliste étalée sur plusieurs mois.

Phase 1 : Quick wins (semaines 1-4)

Objectif : poser les bases sans bouleverser l’existant.

Auditer tous les pipelines et documenter l’état actuel
Activer les branch protection rules sur tous les dépôts critiques
Exiger au moins une review avant merge
Supprimer les builds manuels (plus de docker build en local pour les releases)

Niveau atteint : Source L2, Build L1

Phase 2 : Renforcement (mois 2-3)

Objectif : ajouter la provenance et les signatures.

Implémenter slsa-github-generator sur les projets pilotes
Ajouter la signature Cosign aux images Docker
Documenter le processus pour les autres équipes
Mettre en place des dashboards de suivi (% d’artefacts avec provenance)

Niveau atteint : Source L2, Build L2-L3

Phase 3 : Consolidation (mois 4-6)

Objectif : généraliser et automatiser la vérification.

Déployer sur tous les projets critiques
Implémenter la vérification automatique avant déploiement
Exiger deux reviewers sur les dépôts les plus sensibles (Source L4)
Former toutes les équipes

Niveau atteint : Source L3-L4, Build L3

Métriques à suivre

Pour piloter votre progression, suivez ces indicateurs :

% de pipelines automatisés : objectif 100%
% d’artefacts avec provenance : objectif 100% des releases
% d’artefacts signés : objectif 100% des images Docker
% de dépôts avec branch protection : objectif 100%
Temps moyen de review : surveiller pour éviter les bottlenecks

Limites de SLSA et défis d’adoption

Soyons honnêtes : adopter SLSA demande un investissement significatif. Voici les défis que vous rencontrerez et comment les aborder.

Défi	Ce que ça implique	Comment le surmonter
Génération de provenance	Comprendre les workflows GitHub Actions, les permissions OIDC, le format in-toto	Commencer par un projet pilote simple, documenter chaque étape
Signature keyless	Maîtriser Sigstore, Fulcio (CA), Rekor (transparency log)	Se former sur Cosign d’abord, puis approfondir l’écosystème
Vérification automatisée	Configurer slsa-verifier ou un admission controller K8s	Former une personne référente par équipe
Formation des équipes	1 à 2 semaines pour l’autonomie	Prévoir du temps dédié, pas “en plus du reste”
Refonte des pipelines	1 à 3 mois selon la complexité	Migrer projet par projet, pas tout d’un coup
Ralentissement perçu	Reviews et vérifications ajoutent du temps	Communiquer sur la valeur : c’est un investissement, pas un coût

🚩 Symptômes d’une mauvaise adoption :

Les développeurs contournent le système (builds locaux “en urgence”)
Les reviews sont faites sans réellement lire le code (approbation automatique)
La provenance est générée mais jamais vérifiée par personne
Les métriques sont bonnes sur le papier, mais la sécurité réelle ne s’améliore pas

✅ La bonne approche — SLSA doit apporter de la valeur visible :

Détection rapide quand quelque chose ne va pas (alertes sur provenance invalide)
Confiance accrue des clients et partenaires (preuve vérifiable)
Conformité aux réglementations (NIS2, Cyber Resilience Act, SOC 2)
Réduction du stress en cas d’incident (traçabilité complète pour l’analyse post-mortem)

Pour aller plus loin

Cosign : signature et vérification d'artefacts Signer vos images conteneurs avec Cosign (keyless via OIDC)

SBOM : inventaire de vos dépendances Générer un Software Bill of Materials avec Syft

VEX : réduire les faux positifs Qualifier l'exploitabilité réelle des CVE dans votre contexte

Gouvernance du code source CODEOWNERS, CONTRIBUTING et Branch Protection pour Source Track L3

OpenSSF Scorecard : évaluer la sécurité de vos projets Audit automatisé de la posture sécurité de vos dépôts

Sécuriser vos dépendances Vérifier la provenance SLSA de npm, PyPI et Go

in-toto : attestations de pipeline Le format d'attestation recommandé par SLSA

Conclusion

SLSA apporte une méthode structurée pour sécuriser l’ensemble de votre chaîne d’approvisionnement logicielle. En combinant le Source Track (protection du code source) et le Build Track (protection de la construction), vous pouvez prouver l’intégrité de vos logiciels de bout en bout.

Ce qu’il faut retenir :

Source Track (L1-L4) : du simple versioning jusqu’à la revue obligatoire à deux personnes
Build Track (L0-L3) : de l’absence de garantie jusqu’aux builds isolés et signés
La provenance est la pièce maîtresse : elle prouve comment chaque artefact a été construit
L’adoption progressive est la clé : commencez par Source L2 + Build L2, puis montez en maturité

Les bénéfices concrets :

Traçabilité : vous savez exactement qui a construit quoi, quand, et comment
Détection : une provenance invalide déclenche une alerte immédiate
Confiance : vos clients peuvent vérifier cryptographiquement l’origine de vos logiciels
Conformité : SLSA vous prépare aux exigences NIS2, Cyber Resilience Act, SOC 2

Ne cherchez pas la perfection immédiate. Chaque niveau franchi améliore votre posture de sécurité. Le plus important est de commencer.