SLSA en 2026 : utile pour vos pipelines CI/CD ?

Sécuriser la supply chain logicielle n’est plus un sujet réservé aux grandes entreprises ou aux équipes conformité. En 2026, SLSA s’impose surtout comme un cadre utile pour remettre de l’ordre dans les pipelines CI/CD, réduire les angles morts et rendre les livraisons plus traçables. Dit autrement : ce n’est pas seulement une grille de maturité sécurité, c’est aussi un bon révélateur des faiblesses très concrètes d’un pipeline.

Le problème, c’est que SLSA est souvent présenté de manière abstraite. On parle de provenance, d’attestations, de niveaux, de supply chain, mais rarement de ce que cela change vraiment dans GitHub Actions, GitLab CI/CD, Jenkins, Tekton ou dans une chaîne de build hétérogène qui a grandi par couches successives.

Dans cet article, l’objectif est simple : regarder ce que SLSA apporte réellement à un pipeline CI/CD, ce qui mérite d’être mis en place en priorité, et comment avancer sans transformer votre delivery en machine bureaucratique. Si vous cherchez un cadre pragmatique pour sécuriser vos builds, vos artefacts et vos déploiements, SLSA mérite clairement votre attention.

Pourquoi SLSA revient au centre des pipelines en 2026

SLSA, pour Supply-chain Levels for Software Artifacts, est un cadre lancé sous l’égide de Google puis hébergé par la communauté SLSA. Son but est de définir des pratiques et des garanties progressives pour mieux protéger la chaîne de fabrication logicielle.

Si le sujet revient fortement au centre des discussions DevOps, c’est pour plusieurs raisons très concrètes.

Les attaques sur la chaîne de build ont changé la perception du risque

Les incidents comme SolarWinds ou la compromission de dépendances et d’outils de build ont installé une idée simple : sécuriser le code source ne suffit pas. Un pipeline compromis, un runner mal isolé, un secret exposé ou un artefact non traçable peuvent suffire à diffuser un binaire malveillant ou non maîtrisé.

Dans beaucoup d’équipes, la question n’est plus “faut-il parler de supply chain logicielle ?” mais plutôt : quelles garanties minimales peut-on exiger de notre CI/CD pour savoir ce qui a été construit, par qui, à partir de quoi, et dans quelles conditions ?

Les exigences réglementaires et clients poussent vers plus de traçabilité

Selon les secteurs, les demandes autour des SBOM, de la provenance des artefacts, de la gestion des dépendances et de la preuve de build deviennent plus fréquentes. Même sans obligation réglementaire directe, les clients entreprise demandent de plus en plus souvent des éléments de traçabilité.

SLSA ne remplace pas une politique de sécurité complète, mais il fournit un langage commun pour décrire le niveau de confiance d’un processus de build.

Les outils ont mûri

Il y a quelques années, parler d’attestations, de provenance signée ou de vérification en admission controller relevait souvent du prototype. En 2026, l’écosystème est plus praticable. Des outils comme Cosign, Sigstore, Tekton, SLSA provenance, ou encore les fonctions de signature et de politique disponibles dans certaines plateformes cloud rendent le sujet plus opérationnel.

Autrement dit : SLSA devient utile quand il cesse d’être un document de doctrine et qu’il se traduit en contrôles CI/CD concrets.

Ce que SLSA cherche vraiment à garantir

Avant de parler niveaux, il faut clarifier le cœur du sujet. SLSA ne promet pas qu’un logiciel est sûr. Il aide à répondre à des questions précises sur l’intégrité du processus de build.

• Le code source utilisé est-il identifiable ?
• Le build est-il reproductible ou au moins traçable ?
• Les artefacts produits sont-ils liés à un pipeline contrôlé ?
• Peut-on prouver qu’ils n’ont pas été fabriqués localement sur un poste développeur ?
• Les étapes critiques sont-elles protégées contre la modification discrète ?

Dans un pipeline réel, cela se traduit par des exigences qui parlent immédiatement aux équipes DevOps :

• éviter les builds manuels hors CI ;
• réduire les secrets persistants dans les jobs ;
• durcir les runners et les environnements de build ;
• générer et conserver des métadonnées de provenance ;
• signer les artefacts et vérifier ces signatures avant déploiement ;
• contrôler qui peut modifier le pipeline, et comment.

Vu sous cet angle, SLSA est moins un standard “compliance” qu’un cadre de priorisation pour fiabiliser la chaîne CI/CD.

Ce que les niveaux SLSA changent vraiment côté CI/CD

Les niveaux SLSA servent à exprimer une progression. L’erreur fréquente consiste à les lire comme une checklist binaire. En pratique, ce qui compte est de comprendre quels contrôles techniques deviennent non négociables à mesure que l’on monte en maturité.

Niveau bas : sortir des builds opaques

Le premier bénéfice d’une démarche SLSA est souvent de faire disparaître des pratiques encore très répandues :

• builds lancés depuis des postes locaux ;
• scripts non versionnés copiés d’un projet à l’autre ;
• artefacts publiés sans lien clair avec un commit ou un tag ;
• images conteneur poussées dans un registre sans signature ni métadonnées.

À ce stade, l’enjeu n’est pas de viser la perfection. Il s’agit d’obtenir un minimum de traçabilité : savoir quel pipeline a produit quoi, depuis quelle révision, et conserver cette information.

Niveau intermédiaire : rendre le pipeline plus digne de confiance

Quand on avance, le sujet ne porte plus seulement sur la visibilité, mais sur la résistance à la compromission. Cela implique par exemple :

• des définitions de pipeline versionnées et revues ;
• des permissions plus strictes sur les branches et les workflows ;
• des environnements de build plus isolés ;
• des identités courtes durées à la place de secrets statiques ;
• des attestations de provenance émises automatiquement.

Concrètement, si un job GitHub Actions peut modifier son propre workflow, publier une image et accéder à des secrets très larges, votre niveau de confiance reste faible, même si vous avez ajouté un scanner de vulnérabilités.

Niveau élevé : contrôler l’intégrité de bout en bout

Les niveaux les plus élevés de SLSA demandent des garanties plus fortes sur l’isolement, la provenance et la reproductibilité. Dans la vraie vie, peu d’équipes ont besoin d’atteindre immédiatement le sommet du modèle. En revanche, les exigences associées servent de boussole utile pour les environnements sensibles : éditeurs logiciels, plateformes multi-clients, produits déployés à grande échelle, ou contextes réglementés.

Le point important est le suivant : chaque palier SLSA oblige à traiter des sujets CI/CD structurels, pas seulement à ajouter des rapports de sécurité.

Les contrôles CI/CD qui apportent le plus de valeur rapidement

Si votre pipeline est encore hétérogène, inutile de démarrer par le plus ambitieux. Certaines mesures donnent un retour sur investissement immédiat, à la fois en sécurité et en exploitabilité.

1. Imposer que les artefacts de production viennent uniquement de la CI

C’est probablement le premier garde-fou à mettre en place. Une image Docker, un package ou un binaire déployé en production ne devrait pas provenir d’un build local ou d’un script lancé à la main.

Dans un registre comme Harbor, Amazon ECR, Google Artifact Registry ou GitHub Container Registry, cela signifie organiser vos permissions pour que seuls les pipelines autorisés puissent publier les artefacts destinés à la production.

Le gain est immédiat : vous éliminez une large zone grise sur l’origine des livrables.

2. Lier chaque artefact à un commit, un pipeline et une provenance

Un tag comme latest ne suffit pas. Un artefact exploitable dans une logique SLSA doit être relié à des métadonnées vérifiables : dépôt source, commit, date de build, système de build, paramètres essentiels.

Des outils comme Cosign permettent de signer des images et de leur associer des attestations. C’est un excellent point d’entrée, surtout si vous travaillez déjà avec Kubernetes et des registres OCI.

Cette traçabilité aide autant la sécurité que l’exploitation : en cas d’incident, vous savez plus vite quoi a été déployé et d’où cela vient.

3. Réduire les secrets statiques dans les jobs

Un pipeline qui dépend de tokens longue durée stockés dans des variables CI est difficile à considérer comme robuste. L’approche plus saine consiste à utiliser des identités fédérées ou des credentials temporaires quand la plateforme le permet.

Exemples concrets :

• GitHub Actions OIDC avec AWS, Azure ou Google Cloud ;
• GitLab avec des mécanismes d’authentification fédérée selon l’environnement ;
• accès court terme à Vault plutôt que secrets persistants injectés partout.

Ce changement réduit fortement l’impact d’une fuite de secret dans les logs, dans un runner compromis ou dans un dépôt mal protégé.

4. Durcir les runners et l’environnement d’exécution

Beaucoup de pipelines échouent sur un point simple : le runner est trop permissif. Runner partagé avec privilèges élevés, accès réseau trop large, cache réutilisé sans contrôle, exécution de code non fiable dans le même environnement… tout cela fragilise la chaîne.

Les mesures utiles incluent :

• séparer les runners selon le niveau de confiance des jobs ;
• éviter les runners privilégiés quand ce n’est pas indispensable ;
• limiter l’accès sortant réseau des jobs sensibles ;
• nettoyer réellement les environnements éphémères ;
• isoler davantage les builds de publication.

Ce n’est pas spectaculaire, mais c’est souvent là que se joue la crédibilité d’une démarche SLSA.

5. Protéger les changements de pipeline comme du code sensible

Un pipeline est du code à haut impact. Une simple modification de workflow peut exfiltrer un secret, contourner un contrôle ou publier un artefact compromis. Il faut donc traiter les fichiers CI/CD avec un niveau d’exigence supérieur :

• revue obligatoire ;
• protection de branche ;
• CODEOWNERS sur les répertoires critiques ;
• journalisation des changements ;
• séparation claire entre pipelines de test et pipelines de release.

Dans GitHub, cela peut passer par les branch protection rules et CODEOWNERS. Dans GitLab, par les branches protégées, les approbations et les permissions fines sur les environnements et les jobs.

Ce qu’il ne faut pas faire : transformer SLSA en usine à conformité

Le risque avec SLSA n’est pas seulement de ne rien faire. C’est aussi de déployer une couche de complexité qui ralentit tout le monde sans gain proportionnel.

Accumuler les outils sans chaîne de décision claire

Ajouter un scanner SAST, un scanner de dépendances, un générateur de SBOM, un outil de signature, un policy engine et un admission controller ne suffit pas. Si personne ne sait quels résultats bloquent réellement un déploiement, vous créez surtout du bruit.

Chaque contrôle doit répondre à une question simple : qu’est-ce qu’on vérifie, où, et avec quelle conséquence ?

Bloquer tous les pipelines dès le premier jour

Une erreur classique consiste à vouloir imposer d’un coup signature, provenance, vérification stricte et politiques de déploiement sur l’ensemble du parc. Dans un environnement hétérogène, cela produit généralement des contournements, des exceptions permanentes et une défiance envers le sujet.

Une stratégie plus réaliste consiste à distinguer :

• les applications critiques ou exposées ;
• les pipelines de release par rapport aux pipelines de simple validation ;
• les nouveaux services par rapport à l’existant.

Autrement dit : commencez là où le contrôle a le plus de valeur.

Confondre SLSA et sécurité logicielle complète

SLSA ne remplace ni le durcissement des dépendances, ni la gestion des vulnérabilités, ni la revue de code, ni l’observabilité, ni la sécurité runtime. C’est un cadre centré sur l’intégrité de la chaîne de production logicielle.

Il faut donc l’articuler avec d’autres pratiques, par exemple la génération de SBOM, sujet déjà utile pour améliorer la visibilité sur les composants embarqués. Sur ce point, vous pouvez aussi lire notre analyse sur l’intérêt réel des SBOM dans le CI/CD.

Les mesures pragmatiques à déployer sans bloquer les équipes

Si vous cherchez un plan d’action réaliste, voici une séquence qui fonctionne bien dans des contextes DevOps variés.

Étape 1 : standardiser le minimum de pipeline release

Avant toute chose, définissez un chemin standard pour les livraisons de production :

• source dans un dépôt versionné ;
• build dans la CI uniquement ;
• publication dans un registre central ;
• tag ou version traçable ;
• journal d’exécution conservé.

Si vos équipes partent dans tous les sens, cette standardisation minimale est plus utile qu’une tentative immédiate de conformité avancée. Cela rejoint d’ailleurs la logique des golden paths DevOps : proposer un cadre robuste sans figer tous les cas d’usage.

Étape 2 : signer les artefacts les plus sensibles

Commencez par les images conteneur ou packages qui partent réellement vers la production. Avec Cosign et l’écosystème Sigstore, il est possible de mettre en place une signature moderne sans gérer manuellement toute une PKI interne dès le départ.

L’objectif n’est pas seulement de signer, mais de pouvoir vérifier ensuite cette signature avant promotion ou déploiement.

Étape 3 : générer des attestations de provenance

Une provenance utile doit être produite automatiquement par le système de build, pas écrite à la main. Si votre plateforme ou votre outillage le permet, associez aux artefacts les métadonnées essentielles du build.

C’est un point clé de la logique SLSA : pouvoir démontrer qu’un artefact a bien été produit par un pipeline identifié.

Étape 4 : vérifier en aval, pas seulement produire en amont

Signer sans vérifier n’apporte qu’une valeur limitée. Il faut donc introduire au moins un contrôle aval :

• vérification avant promotion d’un artefact entre environnements ;
• vérification avant déploiement dans le cluster ;
• politique d’admission sur Kubernetes selon votre stack.

Dans l’écosystème Kubernetes, des outils comme Kyverno ou OPA Gatekeeper peuvent être utilisés pour exprimer des politiques, selon vos choix d’architecture et votre niveau de maturité.

Étape 5 : réduire progressivement la surface d’exception

Au début, vous aurez forcément des exceptions : projets legacy, jobs Jenkins anciens, scripts shell historiques, publication manuelle de certains packages. Le bon réflexe n’est pas de nier ces exceptions, mais de les rendre visibles et temporaires.

Tenez une liste simple :

• quels pipelines ne produisent pas de provenance ;
• quels artefacts ne sont pas signés ;
• quels runners restent trop permissifs ;
• quels déploiements échappent encore à la vérification.

Cette visibilité permet de piloter une trajectoire au lieu de rester dans l’intention.

Par où commencer si votre pipeline est encore hétérogène

Dans beaucoup d’organisations, la difficulté n’est pas de comprendre SLSA, mais de l’appliquer à un paysage fragmenté : un peu de GitHub Actions, du GitLab CI/CD, des jobs Jenkins historiques, des scripts Ansible, plusieurs registres, et des pratiques de release différentes selon les équipes.

Dans ce contexte, il faut éviter les programmes trop théoriques. Voici une approche réaliste.

Cartographier la chaîne de release avant de parler niveau SLSA

Commencez par répondre à quatre questions sur chaque flux critique :

• où se trouve la source de vérité ?
• quel système construit l’artefact ?
• où l’artefact est-il publié ?
• quel mécanisme le promeut jusqu’en production ?

Cette cartographie révèle souvent des zones floues : build local toléré, registre secondaire non géré, job de release manuel, secret partagé entre plusieurs projets, absence de séparation entre test et publication.

Choisir un périmètre pilote limité

Ne commencez pas par “tout le SI”. Prenez un périmètre restreint mais significatif :

• une application exposée en production ;
• un service interne critique ;
• une équipe déjà prête à standardiser son pipeline.

Sur ce périmètre, mettez en place un flux complet : build CI, publication contrôlée, signature, provenance, vérification avant déploiement. C’est beaucoup plus convaincant qu’un document de cadrage généraliste.

Standardiser les composants communs

Dans un paysage hétérogène, vous n’unifierez pas tout d’un coup. En revanche, vous pouvez standardiser certains briques transverses :

• un registre d’artefacts principal ;
• une convention de versioning et de tagging ;
• un mécanisme commun de signature ;
• un format commun pour la provenance ;
• des règles minimales sur les runners et les permissions.

C’est souvent la meilleure façon d’obtenir un gain rapide sans réécrire tous les pipelines.

Intégrer SLSA à la fiabilité du pipeline, pas seulement à la sécurité

Le bon angle pour embarquer les équipes n’est pas “il faut plus de conformité”. C’est plutôt : un pipeline plus traçable est aussi plus exploitable, plus auditable et plus simple à diagnostiquer.

Quand un incident survient, savoir exactement quel commit a produit quelle image, via quel job et avec quels paramètres, fait gagner un temps précieux. Sur ce terrain, SLSA rejoint les préoccupations très concrètes de robustesse pipeline. Si ce sujet vous parle, notre article sur la structuration d’un pipeline CI/CD fiable sans usine à gaz complète bien la démarche.

À quoi ressemble une adoption SLSA raisonnable en 2026

Pour la majorité des équipes, une adoption raisonnable de SLSA en 2026 ne ressemble pas à une quête du niveau maximal. Elle ressemble plutôt à ceci :

• les artefacts de production sont construits uniquement par la CI ;
• les pipelines de release sont versionnés, relus et mieux protégés ;
• les secrets statiques reculent au profit d’identités temporaires ;
• les artefacts importants sont signés ;
• une provenance exploitable est générée automatiquement ;
• un contrôle aval vérifie au moins une partie de ces garanties avant déploiement.

Ce socle ne règle pas tout, mais il change déjà fortement le niveau de confiance dans la chaîne de livraison. Et surtout, il reste compatible avec une approche pragmatique du DevOps : renforcer les points critiques sans casser la vitesse de delivery.

SLSA devient utile à partir du moment où il vous aide à supprimer les builds opaques, à mieux protéger vos pipelines de release et à rendre vos artefacts vérifiables. Le reste n’est que vocabulaire si ces bases ne sont pas en place.

Conclusion

En 2026, SLSA mérite sa place dans la boîte à outils DevOps, non pas comme une mode de plus, mais comme un cadre concret pour durcir les pipelines CI/CD. Son intérêt réel n’est pas de cocher un niveau sur une échelle, mais de vous pousser à traiter les sujets qui comptent vraiment : provenance, intégrité du build, contrôle des artefacts, protection des workflows et vérification avant déploiement.

Si votre chaîne CI/CD est encore hétérogène, inutile de viser trop haut trop vite. Commencez par les flux de release qui comptent, standardisez le minimum viable, signez ce qui part en production et rendez vos builds enfin traçables. C’est souvent là que les gains sont les plus nets, autant pour la sécurité que pour la fiabilité opérationnelle.

Et si vous voulez continuer à rendre vos pipelines plus robustes sans les transformer en usine à normes, explorez les autres articles de Pipeline Brut : vous y trouverez une approche volontairement pragmatique, centrée sur ce qui tient vraiment en production.