Software Supply Chain · OpenSSF Standard

SLSA — la chaîne logistique que les pirates ne percent plus.

Supply-chain Levels for Software Artifacts. Le framework qui transforme les pipelines de build en pièces à conviction — et le seul standard qui satisfait le CRA, NIS2 et l’EU AI Act avec des preuves cryptographiques.

L0 → L3 · Build Track

CRA · NIS2 · DORA · AI Act

OpenSSF · Open Standard

Demander un premier conseil En savoir plus

Un bref rappel

Quatre attaques — une seule et même classe.

Manipulation entre le code source et l’utilisateur final. La sécurité du code classique n’y suffit pas. C’est précisément cette faille que SLSA comble.

2020

SolarWinds Orion

18 000 organisations compromises. Système de build manipulé, les mises à jour signées sont devenues une arme.

2021

Codecov bash-uploader

Deux mois sans être détecté. Identifiants de nombreux pipelines CI/CD dérobés.

2023

3CX Desktop App

Attaque multi-étapes de la chaîne logistique. Le vendor lui-même victime d’une autre attaque de la chaîne logistique.

2024

XZ Utils Backdoor

Deux ans d’ingénierie sociale. CVSS 10.0. Découverte par le seul hasard d’une personne.

La situation

La question n’est pas si, mais quand.

Quatre chiffres que tout RSSI devrait connaître aujourd’hui — et qui expliquent pourquoi SLSA ne peut plus manquer dans aucune stratégie de pipeline.

742 %

hausse annuelle moyenne des attaques de la chaîne logistique depuis 2019

Sonatype · State of the Software Supply Chain

95 %

de toutes les codebases contiennent des composants open source

84 %

des codebases présentent au moins une vulnérabilité connue

1 / 8

téléchargements open source contient déjà une faille connue

Un artefact compromis finira dans votre build — non pas si, mais quand.

Introduction

Ce qu’est SLSA — et ce qu’il n’est pas.

Avant d’ouvrir le débat sur les niveaux et les pipelines, une clarification s’impose : SLSA résout un problème précis — et exactement celui-là.

SLSA

Supply-chain Levels for Software Artifacts

Framework de sécurité de l’OpenSSF (Linux Foundation), lancé en 2021 par Google. Se prononce « sal-sa ». Il classe les pipelines de build en niveaux de confiance mesurables — de L0 (aucune garantie) à L3 (durci, isolé, signé).

Ce que SLSA n’est pas

Pas de solution miracle, pas d’outil à acheter.

Ni pen test, ni scanner de code.SLSA ne vérifie pas le contenu des artefacts, mais l’intégrité de leur origine.
Pas un substitut au SBOM.SLSA complète le SBOM par une provenance démontrable — les deux sont complémentaires.
Pas un produit, pas un achat d’outil.Un framework avec des exigences et des niveaux, pas un modèle de licence.
Pas une checklist de conformité.Un threat model avec des contre-mesures concrètes — pas des cases à cocher obligatoires.

Threat Model

Les huit menaces tout au long de la chaîne logistique.

Quatre phases, huit vecteurs d’attaque concrets. SLSA adresse en priorité la phase de build et de distribution — la protection de la source et la vérification côté consommateur forment des tracks distincts.

Source

Dépôt de code source

Submit unauthorized change — un commit malveillant atterrit dans le dépôt.

Compromise source repo — le serveur du dépôt lui-même est pris en main.

Build

Pipeline CI/CD

Build from modified source — le build s’appuie sur une source manipulée.

Compromise build process — les étapes de build sont manipulées.

Package

Registry

Use compromised dependency — un paquet npm/pip malveillant est intégré.

Upload modified package — l’artefact est remplacé après le build.

Consume

Utilisateur final

Compromise package registry — le serveur de la registry lui-même est pris en main.

Use compromised package — l’utilisateur accepte un artefact compromis.

SLSA adresse en priorité C, D, F, G — la phase de build et de distribution. Pour A, B, E et H, il faut une gouvernance de la source complémentaire et une vérification côté consommateur.

Idée de base

Trois notions — le reste n’est que détail.

Si vous comprenez ces trois notions, vous avez compris SLSA. Tout le reste relève des variantes d’implémentation.

Provenance

L’acte de naissance

Document lisible par la machine : ce qui a été construit, à partir de quelle source, par quel builder, avec quels paramètres. Format : in-toto Attestation.

Build Platform

Le lieu de confiance

La plateforme CI/CD qui construit l’artefact. Elle génère la provenance et la signe. Exemples : GitHub Actions, GitLab CI, Tekton Chains.

Verifier

Le gardien

Composant qui vérifie avant le déploiement : la provenance est-elle correcte, la signature est-elle valide, l’artefact respecte-t-il la policy.

Build Track

Quatre niveaux — du Far West à la forteresse.

Chaque niveau s’appuie sur le précédent. Plus de sécurité, moins de confiance-sur-parole.

Aucune garantie

Aucun standard de build, aucune provenance. État par défaut de nombreux projets internes.

La provenance existe

Processus de build documenté. La provenance est générée — lisible par la machine.

Provenance signée

Build sur une plateforme hébergée. Provenance signée cryptographiquement.

Plateforme de build durcie

Isolation, aucune étape définie par l’utilisateur, provenance non falsifiable.

Exigences

Que faut-il concrètement faire ? La matrice du Build Track.

Trois « — » deviennent trois « ✓ ». C’est exactement le chemin de « fais-moi confiance » à « prouve-le ».

Exigence	L1	L2	L3
Le processus de build suit une procédure cohérente	✓	✓	✓
La provenance est générée automatiquement	✓	✓	✓
La provenance est complète (toutes les entrées de build incluses)	✓	✓	✓
La provenance est authentique (signée par le builder)	—	✓	✓
Le build s’exécute sur une plateforme de build hébergée	—	✓	✓
La plateforme de build isole les builds les uns des autres	—	—	✓
La provenance est non falsifiable (l’utilisateur ne peut la truquer)	—	—	✓

Anatomie

À quoi ressemble concrètement une provenance ?

Lisible par la machine, signée, entièrement auditable. Ce qui se cache derrière le format in-toto Statement v1.

Provenance v1 · in-toto StatementJSON

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{
    "name": "vamisec-app:v1.2.3",
    "digest": { "sha256": "a3f5…e91b" }
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://slsa-framework.github.io/…",
      "externalParameters": {
        "source": "git+https://github.com/vamisec/app",
        "ref":    "refs/tags/v1.2.3"
      },
      "internalParameters": { "runner": "ubuntu-22.04" }
    },
    "runDetails": {
      "builder":  { "id": "https://github.com/actions/runner" },
      "metadata": { "invocationId": "…", "startedOn": "2026-05-20T08:14:02Z" }
    }
  }
}

Ce que révèle la provenance

subject
Quel artefact — nom + hash SHA-256. Identifiable de façon unique.
externalParameters
Quelle source — URL Git, tag de commit, pilotable par l’utilisateur.
builder.id
Quel builder l’a construit — identité signée cryptographiquement.
metadata
Quand, combien de temps, avec quel invocation ID — entièrement auditable.

Hands-on

SLSA L3 dans GitHub Actions — en 15 lignes.

Aucune théorie, aucun nouveau silo d’outils. Reusable Workflow de slsa-framework, signature Sigstore via OIDC, Verifier CLI côté consommateur. Open Source, prêt pour la production.

.github/workflows/release.ymlYAML

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

jobs:
  build:
    permissions:
      id-token: write    # Sigstore OIDC
      contents: read
      actions:  read
    uses: slsa-framework/slsa-github-generator/.github/workflows/builder_go_slsa3.yml@v2.0.0
    with:
      go-version:  '1.22'
      config-file: .slsa-goreleaser.yml

Ce qui se passe automatiquement

1Le build s’exécute dans une VM de runner GitHub isolée.
2La provenance est générée automatiquement.
3Signée avec Sigstore (keyless, OIDC).
4Provenance attachée comme release asset.
5Vérifiable publiquement via slsa-verifier.

Vérification côté consommateur — une seule ligne.

Consumer-Side VerificationBash

$ slsa-verifier verify-artifact app-binary \
    --provenance-path app-binary.intoto.jsonl \
    --source-uri      github.com/vamisec/app \
    --source-tag      v1.2.3

PASSED: Verified SLSA provenance

✓ Signature valide✓ Le builder est trusted✓ L’URI de source correspond✓ Build issu du tag attendu

Cette vérification a sa place dans chaque admission controller, chaque pipeline CD, chaque wrapper de package manager. Par défaut : non vérifié = non déployé.

Outils

L’écosystème — Open Source, prêt pour la production.

Vous ne construisez rien de zéro — vous composez à partir de briques open source matures. Aucune licence commerciale nécessaire.

Builder

GitHub Actions

Provenance SLSA L3 native via slsa-github-generator. Signature Sigstore out of the box.

Builder

GitLab CI

Génération de provenance intégrée, conforme à in-toto, à partir de GitLab 16+.

Builder

Tekton Chains

Plateforme de build native Kubernetes avec support SLSA natif pour les stacks cloud-native.

Signature

Sigstore (Cosign)

Keyless signing via OIDC + transparency log. Le standard de facto pour les conteneurs et les artefacts.

Format

in-toto Attestation

Le format standard pour les provenance statements. Basé sur JSON, structuré, signable.

Verifier

SLSA Verifier

CLI open source de l’OpenSSF. Vérifie la provenance par rapport à la policy — une ligne, un code de sortie.

Six composants, aucun vendor lock-in. L’ensemble de la stack SLSA est Open Source et neutre vis-à-vis des fournisseurs.

Pour qui

Pour qui SLSA est particulièrement pertinent.

Si vous décidez ou mettez en œuvre à l’un de ces postes, SLSA a sa place dans votre cible technique — avant que l’échéance du CRA ne devienne une urgence.

RSSI & Heads of AppSec

Sécuriser la chaîne logistique logicielle sur le plan réglementaire — sans bâtir un nouveau silo d’outils.

DevSecOps Leads

Durcir les pipelines CI/CD avec des patterns d’implémentation concrets — pas seulement de la théorie.

Conformité & auditeurs

Preuves techniques pour le CRA article 13, NIS2 article 21(2)(d), EU AI Act article 15.

Équipes plateforme

Bâtir ou évaluer des plateformes de build hébergées — conformes à SLSA dès le premier jour.

Contexte réglementaire

Pourquoi SLSA cesse d’être optionnel au plus tard en 2027.

Quatre règlements européens, une exigence commune : une sécurité de la chaîne logistique démontrable. SLSA fournit la preuve technique.

EU CRA

Règlement (UE) 2024/2847

Article 13 — « Cybersecurity by Design ». Identification des composants et gestion des vulnérabilités tout au long de la chaîne logistique. Applicable à partir du 11/12/2027.

NIS2

Directive (UE) 2022/2555

Article 21(2)(d) — la sécurité de la chaîne logistique comme mesure de gestion des risques obligatoire. Transposée en Allemagne par la NIS2UmsuCG.

EU AI Act

Règlement (UE) 2024/1689

Article 15 — exactitude, robustesse, cybersécurité. Pour l’IA à haut risque, une provenance traçable du build et de l’entraînement est obligatoire.

DORA

Règlement (UE) 2022/2554

Gestion des risques liés aux tiers pour les prestataires financiers. Les fournisseurs de logiciels doivent attester de processus durcis de façon démontrable.

Case Study

XZ Utils — et pourquoi SLSA ne l’aurait pas empêché.

Un regard honnête sur les limites du framework. Quand le pipeline suffit, et quand il en faut davantage.

2021

« Jia Tan » apparaît. Lente montée par ingénierie sociale.

2023

Reprise des droits de maintainer à l’auteur d’origine.

Fév. 2024

Code de backdoor dissimulé dans le script de build.

Mars 2024

Versions 5.6.0 + 5.6.1 publiées avec une backdoor SSH.

29/03/2024

Andres Freund détecte un délai de 0,5 s. Le monde l’échappe belle.

Pièges

Ce que les équipes ratent au premier essai.

Six erreurs que nous voyons régulièrement en audit. Les connaître vous épargne un coûteux second essai.

Générer la provenance, mais ne pas la vérifier

Une preuve sans contrôle, c’est du théâtre. La vérification a sa place dans l’admission controller, pas dans le backlog.

Migrer tous les dépôts d’un coup

Commencez par l’artefact de production le plus critique. Apprenez. Mettez à l’échelle. Le big bang échoue toujours.

Custom Build Steps dans les workflows L3

Les scripts définis par l’utilisateur rendent la provenance falsifiable. Les Reusable Workflows sans code utilisateur sont obligatoires.

Pas de policy, juste une signature

Une signature valide ne dit rien de l’identité du builder. La policy impose : qui a le droit de builder pour nous ?

Traiter SBOM et SLSA comme des concurrents

Ils se complètent. SBOM = quoi. SLSA = comment. Fournir les deux, vérifier les deux.

Le Sigstore-Root comme boîte noire

Sigstore repose sur un trust root public. Comprenez ce à quoi vous faites implicitement confiance. Pour des exigences très élevées : un trust root privé.

Roadmap

Du statu quo à L3 — le chemin réaliste.

Six mois pour passer de « works on my machine » à une provenance non falsifiable pour les artefacts critiques. Pas de big bang, mais quatre phases.

Semaine 1–2

Inventaire

Quels pipelines de build existent ? Qui construit les artefacts de production ? Quels builds tournent en local (« works on my machine ») ?

Semaine 3–6

Atteindre L1

Standardiser les builds. Définition de build as code (YAML). Générer la provenance, même non encore signée.

Mois 2–3

Atteindre L2

Builds uniquement sur des plateformes hébergées. Signer la provenance avec Sigstore. Les consommateurs vérifient.

Mois 4–6

L3 pour les artefacts critiques

Hosted builders avec isolation. Reusable Workflows sans étapes de build définies par l’utilisateur. Provenance non falsifiable.

Statu quoSLSA L3 en production

Takeaways

Cinq phrases — vous n’avez pas besoin de plus.

Si vous ne devez retenir qu’une chose de cette page, que ce soit ces cinq affirmations — dans cet ordre précis.

SLSA est un framework d’exigences pour les pipelines de build — pas un outil, pas un produit.

Provenance + Verifier transforment « fais-moi confiance » en « prouve-le ».

L1 s’atteint en semaines, L3 en mois. Ni l’un ni l’autre ne passe à l’échelle par big bang.

Le SBOM répond au quoi, SLSA répond au comment. Vous avez besoin des deux.

CRA, NIS2, DORA, AI Act — tous exigent une sécurité de la chaîne logistique démontrable. SLSA la fournit.

Expert & auteur

Valeri Milke

CEO & Principal Consultant · VamiSec GmbH

« La sécurité n’est pas un produit — c’est un processus. Et un processus qui n’est pas démontrable n’existe pas lors d’un audit. »

ISO 27001 Lead AuditorISO 42001 Lead AuditorAI Officer (EU AI Act)NIS2 & DORA ExpertCRA ExpertBSI IT-GrundschutzWiz Partner

Référencé dans le webinaire

Des standards que vous connaîtrez ensuite sur le bout des doigts.

SLSA v1.0

Framework

in-toto

Attestation

Sigstore

Keyless Signing

SBOM

CycloneDX · SPDX

OpenSSF

Working Group

ENISA

EU Threat Landscape

Questions fréquentes

FAQ.

Combien de temps prend en général la mise en place de SLSA L3 ?

Pour un pipeline GitHub Actions ou GitLab CI moderne sans héritage historique : 4–8 semaines jusqu’à des attestations de provenance signées en production. Pour des paysages de build hétérogènes avec self-hosted runners et outils maison : 3–6 mois. Le facteur décisif n’est pas le code, mais la plateforme de build.

De quels outils ai-je concrètement besoin pour SLSA L3 ?

Dans la stack standard de l’OpenSSF : slsa-github-generator ou slsa-verifier pour la provenance, cosign/sigstore pour les signatures, optionnellement in-toto pour les attestations multi-étapes. Aucune licence commerciale nécessaire — toute la stack est Open Source et compatible avec GitHub, GitLab et Buildkite.

En quoi SLSA se distingue-t-il du SBOM ?

Le SBOM répond à ce qui se trouve dans un artefact (composants, versions, licences). SLSA répond à comment il a été construit (intégrité de build, provenance, signatures). Les deux sont des briques complémentaires d’un programme moderne de chaîne logistique — pas des concurrents.

Ai-je besoin de SLSA si je ne suis pas encore soumis au CRA ?

Strictement sur le plan juridique, souvent pas encore. En pratique : si vous commencez aujourd’hui, vos pipelines critiques seront en production sur L2/L3 d’ici 2027. Qui démarre en 2027 build sous la pression de l’audit — et cela coûte cher.

Comment VamiSec accompagne-t-il concrètement la mise en place ?

Trois étapes : évaluation du pipeline (maturité actuelle, écarts vers L2/L3, estimation de l’effort), roadmap avec des sprint packages concrets pour votre plateforme de build, implémentation hands-on ou coaching de votre équipe DevSecOps. En option, sous forme d’atelier d’une journée pour les équipes internes. Contactez-nous via le formulaire de réservation.

Prochaine étape

Résistant à l’audit.Démontrable.En production.

Avant de vous lancer, parlez-en à un expert. 30 minutes de premier conseil avec un plan concret pour votre pipeline — sans engagement et gratuit.

Demander un premier conseil

Lors du premier entretien

Bilan de maturité de votre pipeline de build actuel
Roadmap L0 → L3 avec estimation de l’effort
Patterns de code concrets pour GitHub Actions / Verifier
Cartographie de vos obligations : CRA · NIS2 · DORA · AI Act
Synthèse écrite & recommandations

VamiSec GmbH · AI-Driven IT-Security & GRC Experts · Bornheimer Str. 127 · 53119 Bonn ·Mentions légales ·Confidentialité