Supply-chain Levels for Software Artifacts (SLSA, prononcé « salsa ») est un cadre de sécurité développé par Google et désormais géré par l’OpenSSF, qui définit un ensemble gradué d’exigences pour protéger l’intégrité des artefacts logiciels tout au long du processus de compilation et de distribution. SLSA cible un vecteur d’attaque précis et de plus en plus exploité : la compromission du logiciel entre le dépôt de code source et l’artefact logiciel qui parvient aux utilisateurs finaux, c’est-à-dire la chaîne de compilation, le dépôt d’artefacts et le canal de distribution. SolarWinds, XZ Utils et l’attaque de la chaîne d’approvisionnement contre 3CX ont tous exploité cette faille. SLSA fournit un cadre structuré pour la combler.
Le système de niveaux SLSA est la clé conceptuelle. SLSA définit quatre niveaux d’assurance progressivement plus forte concernant la provenance des logiciels et l’intégrité de leur compilation. Le niveau 1 exige que le processus de compilation génère une provenance, c’est-à-dire une documentation de la manière dont l’artefact a été produit. C’est le niveau d’entrée et il n’offre qu’une assurance de sécurité minimale : la provenance peut être falsifiée, le processus de compilation n’est pas isolé et aucune vérification n’est exigée. Le niveau 2 ajoute que c’est le service de compilation qui génère la provenance, et non le développeur, ce qui rend la provenance plus crédible. Le niveau 3 exige que le service de compilation génère une provenance que le développeur ne peut pas falsifier, car elle est signée par le service de compilation. Le niveau 4 ajoute des compilations hermétiques et reproductibles : la compilation est entièrement isolée du réseau, les dépendances sont entièrement spécifiées et les mêmes entrées produisent, de manière vérifiable, les mêmes sorties.
L’importance pratique des niveaux SLSA pour la TPRM tient au fait que les déclarations de conformité SLSA sans précision du niveau n’ont pratiquement aucun sens. Un fournisseur conforme au niveau 1 de SLSA a documenté son processus de compilation. Un fournisseur conforme au niveau 3 de SLSA dispose d’une provenance de compilation infalsifiable issue d’un service de compilation isolé. Ce sont des postures de sécurité très différentes. L’équipe de TPRM qui demande « êtes-vous conforme à SLSA ? » et reçoit « oui » sans demander « à quel niveau ? » a obtenu une confirmation qui peut tout décrire, d’un simple document texte sur le processus de compilation à une chaîne de compilation isolée et vérifiée cryptographiquement.
La perspective de l’attaquant explique pourquoi le niveau compte. L’attaque contre SolarWinds a compromis le pipeline de compilation, c’est-à-dire le processus situé entre le code source et l’artefact compilé. Au niveau 1 de SLSA, cette attaque passe en grande partie inaperçue : la provenance est générée par le même processus que celui que l’attaquant contrôle, et la provenance falsifiée reflète l’artefact malveillant. Au niveau 3 de SLSA, le service de compilation génère une provenance infalsifiable ; un artefact malveillant qui n’a pas été compilé par le service de compilation authentifié ne peut donc pas produire une provenance de niveau 3 valide. Plus le niveau SLSA est élevé, plus l’attaquant doit compromettre d’éléments pour produire un artefact valide accompagné d’une provenance valide.
La réalité de l’adoption constitue le contexte de gouvernance. Le niveau 4 de SLSA, le niveau d’assurance le plus élevé, est extrêmement difficile à atteindre à grande échelle. De nombreux grands éditeurs de logiciels se situent au niveau 1 ou 2. Le niveau 3 est atteignable moyennant des investissements dans l’infrastructure de compilation. Le niveau 4 représente un engagement architectural important. Pour les besoins de la TPRM, la question pertinente n’est pas de savoir si un fournisseur a atteint le niveau 4, mais s’il progresse activement dans les niveaux SLSA et si son niveau actuel est adapté au risque du logiciel qu’il livre.
Pourquoi c’est important
SLSA est important pour la TPRM, car les attaques contre la chaîne d’approvisionnement logicielle, en particulier la compromission des pipelines de compilation et de la distribution des artefacts, figurent parmi les vecteurs d’attaque actuellement exploités les plus lourds de conséquences et les plus difficiles à détecter. L’entreprise qui confirme qu’un fournisseur est conforme à SLSA sans en connaître le niveau n’a obtenu aucune assurance significative quant à l’intégrité de la compilation. L’entreprise qui comprend les niveaux SLSA peut poser les bonnes questions et fixer des attentes adaptées pour les logiciels qu’elle déploie.
Le rayon d’impact en aval est la préoccupation propre à la chaîne d’approvisionnement. Un logiciel compromis dans le pipeline de compilation contient le code de l’attaquant dans chaque artefact compilé distribué à chaque client. Une seule compromission du pipeline de compilation atteint toutes les entreprises qui déploient ce logiciel, comme SolarWinds l’a démontré à grande échelle. Les exigences des niveaux 3 et 4 de SLSA rendent cette attaque nettement plus difficile à mener sans être détectée.
Là où la plupart des équipes se trompent
La défaillance la plus constante consiste à accepter une confirmation de conformité SLSA sans demander le niveau, en traitant SLSA comme une certification binaire plutôt que comme un cadre gradué. La deuxième défaillance consiste à ne pas exiger de niveau SLSA minimal pour les fournisseurs de logiciels critiques, en acceptant n’importe quel niveau quel que soit le profil de risque du logiciel.
- Conformité SLSA confirmée sans niveau : une question binaire sur la conformité produit une réponse non informative
- Aucun niveau minimal exigé pour les fournisseurs de logiciels critiques
- SLSA niveau 1 accepté pour des logiciels très critiques dont le rayon d’impact est important
- Aucune compréhension de ce que chaque niveau empêche : la perspective de l’attaquant n’est pas appliquée
- Aucune exigence de progression SLSA : les fournisseurs ne sont pas tenus de s’améliorer au fil du temps
À quoi ressemblent les bonnes pratiques
Les programmes matures de sécurité de la chaîne d’approvisionnement logicielle demandent précisément le niveau SLSA, fixent des niveaux minimaux attendus proportionnés à la criticité des logiciels et demandent des attestations de provenance comme preuves, au lieu de se contenter des réponses aux questionnaires.
- Demandez précisément le niveau SLSA, et non une simple conformité binaire
- Fixez un niveau minimal selon la criticité : au minimum le niveau 2 pour la plupart des logiciels commerciaux, le niveau 3 pour les logiciels critiques
- Demandez une attestation de provenance comme preuve à l’appui du niveau revendiqué
- Demander la feuille de route SLSA : le niveau visé par le fournisseur et le calendrier
- Vérifiez la provenance des artefacts logiciels critiques à l’aide d’outils
Outils
Vérification SLSA : Sigstore/cosign pour la vérification de la provenance ; outils du cadre SLSA sur slsa.dev
L’outil cosign de Sigstore fournit le mécanisme de vérification des attestations de provenance SLSA, en confirmant que la provenance déclarée d’un artefact logiciel est valide et correspond à l’artefact. Pour les praticiens de la TPRM, demander à un fournisseur son attestation de provenance SLSA pour une version précise et la vérifier avec cosign est le test pratique qui confirme si le niveau SLSA revendiqué produit des artefacts vérifiables.
Systèmes de compilation : GitHub Actions avec le générateur SLSA, Google Cloud Build avec prise en charge de SLSA
Les principales plateformes CI/CD prennent désormais en charge la génération de provenance SLSA. Le générateur SLSA de GitHub Actions produit une provenance conforme au niveau 3 pour les compilations GitHub Actions. Pour les évaluations de TPRM, demander si le système de compilation du fournisseur prend en charge la génération de provenance SLSA, et à quel niveau, constitue une question précise sur l’infrastructure de compilation.
Enjeux de gouvernance
Le défi de gouvernance que pose SLSA dans la TPRM est le déficit d’expertise. SLSA est une norme technique dont l’évaluation sérieuse exige une compréhension de l’infrastructure de compilation. Les équipes TPRM qui ne disposent pas d’une expertise en sécurité de la compilation peuvent avoir du mal à évaluer les déclarations de niveau SLSA sans l’appui des développeurs. La réponse en matière de gouvernance consiste à élaborer un guide de référence sur les niveaux SLSA qui permet aux analystes TPRM de poser les bonnes questions et d’interpréter les réponses de manière appropriée, complété par la consultation des équipes de développement pour les fournisseurs de logiciels critiques.
- Définissez les niveaux SLSA exigés selon le niveau de criticité des logiciels
- Demander le niveau SLSA et une attestation de provenance, et non une conformité binaire
- Demander une feuille de route SLSA aux fournisseurs situés aux niveaux inférieurs
- Vérifier les attestations de provenance des artefacts logiciels critiques
- Développer la compréhension des niveaux SLSA chez les analystes TPRM : ce que chaque niveau empêche
Si vous êtes une petite équipe
Pour vos trois fournisseurs de logiciels les plus critiques, c’est-à-dire les produits dont la compromission de la chaîne d’approvisionnement serait la plus dommageable, posez deux questions précises. Premièrement : à quel niveau SLSA votre processus de compilation est-il conforme, et pouvez-vous fournir une attestation de provenance pour votre version la plus récente ? Deuxièmement : votre système de compilation est-il intégré à Sigstore ou à un cadre de vérification de provenance équivalent, et pouvons-nous vérifier l’attestation de manière indépendante ? Ces deux questions vous en apprendront bien plus sur l’intégrité réelle de la compilation qu’une confirmation binaire de conformité SLSA.
- Demander précisément le niveau SLSA des trois principaux fournisseurs de logiciels critiques
- Demander une attestation de provenance pour une version récente
- Demandez si la provenance peut être vérifiée de manière indépendante
- Fixez un niveau SLSA minimal exigé pour les logiciels critiques
Ce qu’il faut exiger
Demandez directement :
« À quel niveau SLSA votre processus de compilation est-il conforme, et pouvez-vous fournir, pour votre dernière version majeure, une attestation de provenance vérifiable confirmant que l’artefact a été compilé à partir du code source déclaré par un service de compilation authentifié ? »
Preuves attendues
- Niveau SLSA précis, et non une conformité binaire
- Attestation de provenance pour une version récente
- Méthode de vérification de l’attestation
- Feuille de route SLSA si le niveau est inférieur à la cible
Il convient de demander le niveau à un fournisseur qui confirme sa conformité à SLSA. La conformité au niveau 1 et la conformité au niveau 3 n’offrent pas la même assurance. Le niveau détermine ce que signifie la confirmation de conformité.
Comment le prouver
- Niveaux SLSA exigés selon la criticité des logiciels
- Registres des attestations de provenance
- Vérification de la provenance des logiciels critiques
- Suivi de la feuille de route SLSA du fournisseur
À retenir
Conformité SLSA : confirmée. Niveau : 1. Ce que signifie le niveau 1 : le processus de compilation est documenté. Ce qu’il empêche : rien qui intéresserait un attaquant. Le niveau 1 de SLSA relève de la documentation. Le niveau 3 correspond à une provenance infalsifiable émise par un service de compilation isolé. Le niveau 4 correspond à des compilations hermétiques et reproductibles. L’attaque contre SolarWinds, qui a consisté à compromettre le pipeline de compilation pour insérer du code malveillant dans des artefacts signés, est empêchée par le niveau 3, car la compilation malveillante ne peut pas produire une provenance de niveau 3 valide. C’est le niveau qui détermine ce que signifie la confirmation de conformité. Les questions binaires sur la conformité SLSA produisent des réponses binaires qui ne disent rien d’utile sur l’intégrité de la compilation.