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

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 modèle de menaces officiel (SLSA v1.2) découpe la chaîne en neuf menaces, notées A à I, réparties sur quatre étapes : la source, le build, la distribution et l'usage.

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

Ce schéma place chaque menace là où elle frappe. SLSA ne prétend pas toutes les couvrir : il est très efficace de la source au build et à la distribution (menaces B à G, la source via le Source Track et sa revue à deux), mais reconnaît ne pas traiter directement le producteur malveillant (A), la sélection de paquet (H) ni l'usage final (I). C'est une honnêteté du framework, pas une lacune masquée.

Menaces sur la source (A, B, C)

Ces attaques ciblent le code et le dépôt avant toute compilation.

Menace	Ce que fait l'attaquant	Comment SLSA aide
(A) Producteur malveillant	Un mainteneur de confiance publie volontairement une version piégée	Hors périmètre direct : la provenance trace au moins l'origine et l'auteur
(B) Modification de la source	Pousse du code sans passer par la revue (push direct sur `main`)	Source L3-L4 : branches protégées et revue à deux personnes
(C) Abus du gestionnaire de source	Un administrateur contourne les contrôles ou compromet le serveur SCM	Source L3 : contrôles techniques tracés dans des attestations signées

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. Les mainteneurs ont détecté l'attaque rapidement grâce à leur processus de review. C'est un cas typique de menace (C) : compromission du gestionnaire de source.

Avec Source L3-L4, cette attaque aurait été bien plus difficile : les contrôles de branche auraient bloqué l'injection et les attestations l'auraient révélée.

Source : php.internals

Menaces sur le build (D, E, F)

Ces attaques ciblent le pipeline de compilation et la publication de l'artefact.

Menace	Ce que fait l'attaquant	Comment SLSA aide
(D) Paramètres de build non officiels	Lance le build depuis un fork ou avec des paramètres inattendus	La provenance révèle la vraie source ; la vérification la compare à la source attendue
(E) Compromission du processus de build	Implante du code dans la plateforme de build ou vole la clé de signature	Build L3 : isolation des builds et clé de signature inaccessible au code
(F) Altération à la publication	Modifie l'artefact (ou sa provenance) entre le build et la diffusion	Build L2+ : provenance signée ; vérification d'intégrité avant promotion

Exemple réel : SolarWinds (2020)

L'attaque SolarWinds est l'exemple parfait de menace (E). 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 la distribution (G)

Une fois l'artefact publié, il transite par un canal de distribution : un registre (npm, PyPI, Docker Hub), un miroir ou un CDN. Ce maillon concentre des millions de téléchargements, ce qui en fait une cible de choix.

Menace	Ce que fait l'attaquant	Comment SLSA aide
(G) Compromission du canal de distribution	Remplace le paquet sur le registre via une interface admin ou une compromission d'infrastructure	Signature des artefacts et vérification de provenance côté consommateur, qui détectent toute substitution

La parade ne consiste pas à faire confiance au registre, mais à vérifier : un consommateur qui contrôle la signature et la provenance d'un paquet détecte immédiatement un artefact substitué, même servi par un miroir légitime. C'est tout l'intérêt de Cosign et de la vérification automatisée décrite plus bas.

Menaces à l'usage et sur les dépendances (H, I)

Ces attaques exploitent le choix et l'utilisation du paquet par le consommateur. SLSA les couvre mal directement, mais sa logique s'applique récursivement aux dépendances : un composant tiers est lui-même un artefact qui mérite sa provenance.

Menace	Ce que fait l'attaquant	Comment SLSA aide
(H) Mauvaise sélection de paquet	Typosquatting (`lodash` vs `1odash`) ou dependency confusion (homonyme d'un paquet interne)	Hors périmètre direct ; la vérification de provenance confirme l'origine attendue
(I) Usage non sécurisé	Le paquet est mal configuré (identifiants par défaut, options dangereuses)	Hors périmètre SLSA : relève du durcissement côté consommateur

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), puis a glissé du code malveillant dans une dépendance transitive ciblant les portefeuilles Bitcoin. C'est la menace (A) appliquée à une dépendance : preuve que la sécurité d'un projet dépend de celle de toute sa chaîne. Les attaques par typosquatting et dependency confusion (menace H) sont détaillées dans attaques via les gestionnaires de paquets.

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 Technical 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 natif	Statut	Source
GitHub Actions	L3	Production (Artifact Attestations)	GitHub Blog
Google Cloud Build	L3	Production	Google Cloud Docs
GitLab CI	L2	Production ; L3 en bêta (test)	GitLab Docs
Jenkins	L1	Proof-of-concept	Jenkins Plugin

Ce tableau porte sur le Build Track, le seul que les plateformes auto-certifient. Le Source Track, lui, ne dépend pas de l'outil de build mais de la configuration de votre dépôt : branches protégées, revue obligatoire, historique immuable. À ce jour, ni GitHub ni GitLab ne publient d'auto-évaluation Source Track officielle ; vous l'atteignez en durcissant vos contrôles de source, détaillés dans le guide gouvernance du code source.

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 une provenance "SLSA level 2 compliant", signée par le GitLab Runner (donc aussi Level 1). Le Level 3 est documenté mais en test, pas pour la production.
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 plafonne sur le Build Track ?

Si vous êtes sur Jenkins, ou si vous voulez aller au-delà du Build L2 natif de GitLab, vous pouvez renforcer votre posture autrement :

Durcir le Source Track : branches protégées et revue obligatoire vous rapprochent des exigences Source L3-L4, indépendamment du Build Track.
Ajouter des signatures Cosign : signez vos artefacts indépendamment de la plateforme.
Utiliser des outils tiers : slsa-github-generator, Sigstore et solutions équivalentes comblent les écarts.
Évaluer une migration : si la criticité de vos applications l'exige, GitHub Actions et Google Cloud Build offrent le Build 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)

Exigences SOCLE couvertes

SLSA n'est pas qu'un cadre théorique : ses niveaux se traduisent en exigences opposables. Mettre en pratique ce guide, c'est satisfaire plusieurs exigences du référentiel SOCLE (Sécurité de la Chaîne logicielle), avec un niveau de robustesse associé (R1 fondamental, R2 renforcé, R3 souverain). Voici la correspondance, du build à l'admission :

SOCLE-INT-GEN-6 (R2) : le build s'exécute sur une plateforme hébergée et tracée qui génère une provenance. C'est exactement le Build L2 décrit plus haut.
SOCLE-REL-GEN-2 (R2) : la provenance in-toto est générée, attachée à l'artefact et vérifiable par les consommateurs. C'est le cœur du Build Track.
SOCLE-REL-GEN-4 (R3) : pour les artefacts sensibles, la provenance devient non falsifiable grâce au build isolé (Build L3). C'est le niveau cible des releases critiques.
SOCLE-DPL-GEN-4 (R2) : à l'admission, on vérifie la provenance contre un builder et une source attendus (allowlist), pas seulement la présence d'une attestation. C'est l'étape de vérification avant déploiement décrite ci-dessus.

Référentiel : framework SOCLE. Ce guide met en œuvre ces exigences ; il ne constitue pas une promesse de conformité.

Pour aller plus loin

Vérifier et bloquer : de la provenance à la policyImplémenter la vérification de provenance SLSA en CI et avec Kyverno Cosign : signature et vérification d'artefactsSigner vos images conteneurs avec Cosign (keyless via OIDC) Vérifier la provenance SLSA dans les PRImplémenter la vérification avec Kusari et Kyverno Kusari : décisions go/no-goExploiter SLSA pour automatiser les contrôles dans les pull requests SBOM : inventaire de vos dépendancesGénérer un Software Bill of Materials avec Syft VEX : réduire les faux positifsQualifier l'exploitabilité réelle des CVE dans votre contexte Gouvernance du code sourceCODEOWNERS, CONTRIBUTING et Branch Protection pour Source Track L3 OpenSSF Scorecard : évaluer la sécurité de vos projetsAudit automatisé de la posture sécurité de vos dépôts Sécuriser vos dépendancesVérifier la provenance SLSA de npm, PyPI et Go in-toto : attestations de pipelineLe 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.