SLSA 1.2 : une piste « Source » pour sécuriser le code avant le build

2025-11-24 · Éditeur : SLSA (Linux Foundation) · Domaine : Cloud & DevOps

Le 24 novembre 2025, le cadre SLSA publie sa version 1.2, qui ajoute la piste Source : elle couvre les menaces liées à la rédaction, à la revue et à la gestion du code source. Elle reste compatible avec la 1.1.

Ce qui change

  • SLSA 1.2 est publiée le 24 novembre 2025.
  • Nouveauté : la piste Source, sur la rédaction, la revue et la gestion du code.
  • Rétrocompatible avec SLSA 1.1, après deux versions candidates en 2025.
  • Les pistes Build Environment et Dependency sont en préparation.

### Ce qui change Le 24 novembre 2025, SLSA (Supply-chain Levels for Software Artifacts), cadre de sécurité de la chaîne d'approvisionnement logicielle développé sous l'égide de la Linux Foundation, publie sa version 1.2. Son apport principal est la piste Source (« Source Track »), qui traite les menaces propres à la rédaction, à la revue et à la gestion du code source. ### Caractéristiques - Versions candidates publiées en juin puis en novembre 2025, avec une phase de relecture par la communauté. - La version 1.2 est rétrocompatible avec la 1.1. - La piste Source complète la piste Build : elle ajoute des garanties sur l'historique, les contrôles imposés et la revue de code. - Deux autres pistes sont en préparation : l'environnement de build (Build Environment Track) et les dépendances (Dependency Track). - SLSA est une collaboration inter-industrie qui suit le cycle de vie « Community Specification » de la Linux Foundation. ### Pourquoi c'est important Les attaques de 2025 (tj-actions, Shai-Hulud) ont visé les comptes de mainteneurs, les workflows et les dépôts autant que les artefacts. La piste Source de SLSA formalise ce qu'il faut démontrer en amont du build : qui a modifié le code, avec quelle revue, dans quel dépôt. Pour les ESN qui construisent des chaînes de livraison pour des clients soumis au CRA ou à NIS2, c'est un référentiel de preuve réutilisable. SLSA 1.2 n'est pas un outil mais une spécification : sa valeur dépend de l'outillage (plateformes de build, registres, attestations) qui la met en œuvre. ### À retenir SLSA couvre désormais le code source en plus du build : un cadre de preuve pour répondre aux attaques sur les comptes et les workflows.

Liens

Tags : Sécurité, CI/CD, Open Source, DevOps