Définition
Le cadre SLSA (en anglais, Supply-chain Levels for Software Artifacts, ou niveaux de chaîne d’approvisionnement pour les artefacts logiciels) est une norme de sécurité de l’OpenSSF qui permet de sécuriser le processus de création de logiciels. Il vise à limiter les risques de manipulation, à renforcer la traçabilité et à assurer l’intégrité des artefacts, en guidant les équipes vers des pratiques de développement logiciels vérifiables et de confiance.
Vue d’ensemble du cadre SLSA
La dernière version du cadre SLSA v1.1, comprend des niveaux de sécurité progressifs (SLSA 0-3), chacun représentant un ensemble de contrôles plus stricts sur le processus de création de logiciels. Les principes fondamentaux du SLSA framework incluent :
- Provenance : historique vérifiable du processus de construction logicielle ;
- Résistance à la falsification : protection contre les modifications non autorisées ;
- Isolation et reproductibilité : les builds s’effectuent dans des environnements sécurisés et maîtrisés.
Indépendant des outils, ce framework s’adopte par étapes selon le niveau de maturité de l’équipe en matière de sécurité.
SLSA : un atout pour garantir l’intégrité des logiciels
SLSA aide les organisations à instaurer la confiance dans leurs logiciels en imposant de bonnes pratiques qui garantissent l’authenticité et la fiabilité des applications. Elle permet aux équipes et aux utilisateurs finaux de vérifier plus facilement que le logiciel n’a pas été modifié et qu’il peut être utilisé en toute sécurité, jouant ainsi un rôle clé dans la sécurité de la chaîne d’approvisionnement logicielle moderne.
Des vulnérabilités peuvent être introduites à chaque étape de la chaîne d’approvisionnement logicielle (Source : SLSA.dev)
SLSA et GRC : un framework fondamental pour des logiciels prêts pour la conformité
À mesure que la gouvernance, la gestion des risques et la conformité (GRC) prennent de l’importance pour les entreprises, SLSA offre un cadre éprouvé pour prouver la sécurité de la chaîne d’approvisionnement logicielle. Reconnue par l’industrie, SLSA offre un langage commun qui facilite les échanges entre entreprises, régulateurs et auditeurs, favorisant ainsi la confiance et, à terme, la conformité.
Le besoin croissant de sécurité de la chaîne d’approvisionnement
Les logiciels modernes reposent sur des composants open source et tiers, ce qui fait de la chaîne d’approvisionnement une cible privilégiée pour les attaquants. Pour faire face à ces menaces, SLSA met en place un ensemble de contrôles rigoureux sur les processus de build, une vérification automatique et une traçabilité des artefacts. Ainsi, les équipes peuvent prévenir les manipulations, soutenir les investigations forensiques, et se conformer à des normes reconnues telles que SSDF et EO 14028.
Comment SLSA aborde les vulnérabilités et les risques
SLSA s’attaque aux risques négligés dans la chaîne d’approvisionnement logicielle, tels que les versions falsifiées et les dépendances non sécurisées, en sécurisant le processus de build lui-même. En imposant la traçabilité, la séparation des environnements de build et l’archivage vérifiable, SLSA empêche les modifications illicites et facilite la détection précoce des compromissions. Grâce à ses différents niveaux, les entreprises peuvent progressivement combler les lacunes en matière de sécurité et mieux contrôler le cycle de vie de leurs logiciels.
Avantages de l’adoption du cadre SLSA pour les organisations
L’adoption de SLSA renforce l’intégrité des logiciels, réduit le temps de réaction en cas d’incident, améliore la confiance des utilisateurs et des parties prenantes, et facilite les audits pour prouver la conformité aux standards comme SSDF et EO 14028.
Les niveaux de sécurité SLSA expliqués
Le cadre SLSA définit quatre niveaux progressifs d’assurance, chacun étant conçu pour renforcer l’intégrité de la chaîne d’approvisionnement logicielle. Ces niveaux peuvent être adoptés progressivement, ce qui permet aux organisations de faire évoluer leur dispositif de sécurité au fil du temps en fonction des risques, des ressources et des besoins de l’entreprise. Voici ce que contiennent les niveaux de sécurité SLSA dans le SLSA v1.1 (dernier framework en date d’avril 2025) :
Niveau 0 (L0) : Ce niveau implique qu’aucune exigence SLSA n’est mise en place et qu’il n’existe aucune traçabilité. Il ne convient que pour les phases de développement et de test, lorsque les builds sont réalisés et exécutés sur une même machine locale.
Niveau 1 (L1) : Établir les bases de la provenance
Critères : La plateforme de build doit générer automatiquement une traçabilité expliquant comment l’artefact a été construit. Les informations sur la provenance doivent également pouvoir être transmises aux utilisateurs finaux.
Le respect de la norme SLSA L1 aide les organisations à établir une base de provenance sur laquelle elles peuvent s’appuyer.
Niveau 2 (L2) : Héberger la provenance sur une plateforme de build hébergée
Critères : Il est nécessaire que la plateforme de build puisse, par elle-même, générer et signer la provenance de façon automatique. Les clients doivent ensuite pouvoir contrôler l’authenticité de cette provenance.
L’application du niveau SLSA L2 permet d’empêcher toute modification non autorisée des builds via des signatures numériques, de limiter la surface d’attaque et de dissuader les attaquants de contourner les protections de sécurité.
Niveau 3 (L3) : Renforcement supplémentaire des builds
Critères : Pour garantir que le package provient bien de la source officielle et du bon processus de build, la plateforme doit mettre en place des contrôles spécifiques. Elle doit aussi empêcher toute interférence entre différentes exécutions, même dans un même projet, et protéger les éléments secrets utilisés pour la signature de la provenance contre tout accès lors des étapes de build définies par l’utilisateur.
Le niveau SLSA L3 va plus loin que le L2, en offrant une défense supplémentaire contre la manipulation lors du build, notamment en cas de compromission des identifiants ou de menaces internes. À ce niveau, il devient extrêmement difficile de fabriquer une fausse provenance.
Ces différents niveaux permettent aux équipes d’adapter leur stratégie de sécurité à leurs contraintes d’implémentation, renforçant ainsi, niveau par niveau, la confiance et la résilience au sein de la chaîne logicielle.
Bonnes pratiques pour la mise en œuvre du SLSA
Étapes de l’intégration du SLSA dans le cycle de vie du développement logiciel
- Établissez une base solide grâce aux SBOM : débutez par la génération d’un Software Bill of Materials (nomenclature logicielle, ou SBOM) pour avoir une vue claire sur les composants et les dépendances utilisés.
- Automatisez les builds : adoptez des systèmes CI/CD hébergés pour limiter les risques de manipulation et garantir la reproductibilité des processus.
- Adoptez de bonnes pratiques du contrôle des versions : imposez la revue de code, signez les commits et limitez l’accès aux dépôts.
- Générez et vérifiez la provenance : utilisez des outils permettant la signature cryptographique et la validation des artefacts.
- Fixez des objectifs SLSA réalistes : commencez par des petites victoires, puis progressez graduellement. Mettez en place le niveau 1 en priorité, puis visez le niveau 3 à mesure que votre pipeline gagne en maturité.
Pièges à éviter
La mise en œuvre du cadre SLSA peut être compromise lorsque les équipes continuent à utiliser des processus de build manuels, omettent la vérification de la provenance, ou appliquent de façon inégale les politiques de gestion des versions et des accès. Sans formation adéquate aux bonnes pratiques de développement sécurisé, il devient difficile de rester conforme et de tirer pleinement parti du cadre SLSA.
Outils d’aide à la mise en œuvre du cadre SLSA
La mise en œuvre du cadre SLSA repose avant tout sur un outil automatisé de collecte de preuves capable de capturer la provenance. Vous pouvez exploiter des solutions open source comme Sigstore (incluant Cosign et Rekor) pour signer et vérifier la provenance logicielle. Le site SLSA.dev propose des spécifications et une documentation actualisées, tandis qu’in-toto offre un cadre pour sécuriser l’ensemble de la chaîne d’approvisionnement logicielle.
D’autres fournisseurs proposent également des solutions intégrées de collecte automatique de preuves, que ce soit via des plateformes DevOps, des outils d’automatisation de conformité ou des prestataires ASPM. Nous vous recommandons de choisir l’outil qui s’adapte le mieux à vos besoins, afin d’optimiser votre SDLC avec une vision complète sur vos applications et ainsi faire évoluer votre conformité SLSA à grande échelle.
Comment JFrog facilite l’application du cadre SLSA
JFrog facilite l’adoption du SLSA en sécurisant chaque étape du processus de build et de livraison logicielle. Sa solution Evidence Collection automatise la collecte des preuves signées sur l’ensemble du SDLC, vous permettant d’aligner vos builds avec les niveaux SLSA en toute simplicité. JFrog Artifactory offre un stockage sécurisé des artefacts, avec une traçabilité intégrée, tandis que JFrog Xray permet l’analyse des vulnérabilités et le contrôle des politiques de sécurité. Pour plus d’informations, veuillez consulter notre site web, organisez une visite virtuelle ou organisez une démonstration individuelle à votre convenance.
