Qu'est-ce que SLSA ?

Quel problème SLSA résout-il ?

Vous pouvez relire chaque ligne de code source et livrer malgré tout autre chose, car ce que les utilisateurs exécutent est le résultat d'un build. Si le build est compromis, comme chez SolarWinds, une source saine produit une release empoisonnée. SLSA se concentre sur cette lacune : quelqu'un peut-il vérifier que cet artefact provient de cette source, par ce processus ?

Les niveaux SLSA

SLSA organise ses exigences en pistes. La version actuelle, 1.2, comporte une piste Build et une piste Source. La piste Build compte quatre niveaux.

Niveau	Nom	Ce qu'il exige	Ce qu'il apporte
Build L0	Aucune garantie	Rien	L0 correspond à l'absence de SLSA
Build L1	Provenance existante	Un processus de build cohérent, et une provenance générée par la plateforme de build et remise aux consommateurs	Aide à prévenir les erreurs, mais se contourne ou se falsifie très facilement
Build L2	Plateforme de build hébergée	Les builds s'exécutent sur une plateforme hébergée qui génère et signe la provenance, et les consommateurs la vérifient	Falsifier la provenance exige désormais une attaque délibérée
Build L3	Builds renforcés	Les exécutions sont isolées les unes des autres, et le secret de signature est hors de portée des étapes de build définies par l'utilisateur	Falsifier la provenance exige d'exploiter une vulnérabilité, ce qui dépasse la plupart des adversaires

Les niveaux ne sont pas une note à maximiser. Chacun protège contre des menaces précises : choisissez donc le niveau adapté à votre risque. Les mainteneurs open source qui utilisent un service CI hébergé peuvent souvent atteindre L2 sans grand effort.

Qu'est-ce que la provenance ?

La provenance est un enregistrement de la façon dont un artefact a été produit. Dans SLSA, elle indique quelle plateforme l'a construit, à partir de quelle source, par quel processus et avec quelles entrées de premier niveau. À partir de L2, la provenance est signée : un consommateur peut donc vérifier qu'elle provient de la plateforme de build et qu'elle n'a pas été modifiée.

Voyez une SBOM comme les ingrédients, et la provenance comme le lieu et la manière dont le plat a été cuisiné. Elles répondent à des questions différentes et se complètent bien : une SBOM liste ce qui se trouve à l'intérieur, tandis que la provenance indique d'où vient l'artefact.

Comment adopter SLSA

1. Construisez en CI, de la même façon à chaque fois. Cessez de publier des releases depuis des ordinateurs portables. C'est l'essentiel du travail pour atteindre L1.
2. Générez la provenance. Sur GitHub, les attestations d'artefacts produisent une provenance signée. Voir comment les attestations fonctionnent avec les SBOM dans GitHub Actions.
3. Vérifiez-la là où cela compte. Une provenance signée que personne ne contrôle ne protège personne. Ajoutez la vérification à votre étape de déploiement ou à votre contrôleur d'admission.
4. Renforcez le build. Isolez les exécutions et gardez les clés de signature à l'écart des étapes de build. Consultez le comparatif de la sécurité des runners.
5. Interrogez vos dépendances. Privilégiez les paquets qui publient leur provenance, ce que des registres tels que npm prennent désormais en charge.

Ce que SLSA ne couvre pas

• Les vulnérabilités. Un artefact parfaitement construit peut contenir une faille. SLSA ne dit rien de la sûreté du code.
• Une source malveillante. Si un attaquant commite dans le dépôt, la provenance enregistre fidèlement un build de ce code. La piste Source traite une partie de ce problème.
• Ce que le build a récupéré. La provenance liste les entrées de premier niveau. Rien dans la piste Build n'exige une liste complète des dépendances, et c'est le rôle d'une SBOM.
• Les initiés de confiance. La porte dérobée de xz est passée par un mainteneur de confiance, et SLSA seul ne l'aurait pas arrêtée.

SLSA et les autres cadres

SLSA approfondit l'intégrité du build. Le NIST SSDF est bien plus large : il couvre le développement sécurisé dans son ensemble, y compris une pratique de protection et d'archivage des releases que la provenance SLSA vient soutenir. SLSA est un projet de l'OpenSSF, et de nombreuses équipes utilisent les deux ensemble. Pour une vue d'ensemble, voir qu'est-ce que la sécurité de la chaîne d'approvisionnement logicielle.

La place de CRACI

CRACI ne produit pas de provenance signée et ne revendique aucun niveau SLSA : utilisez donc les attestations d'artefacts de GitHub ou un service similaire si vous en avez besoin. Ce que CRACI ajoute, c'est ce que SLSA laisse de côté : un enregistrement complet de ce que chaque job GitHub Actions a récupéré. Chaque job s'exécute dans sa propre machine virtuelle isolée, chaque paquet qu'il récupère entre dans une SBOM, et une politique de trafic sortant bloque les connexions dont le build n'a pas besoin. Consultez la génération de SBOM au build.

SLSA : questions fréquentes

Que signifie SLSA ?

Supply-chain Levels for Software Artifacts. Cela se prononce « salsa ».

Quels sont les niveaux SLSA ?

La piste Build en compte quatre : L0, aucune garantie ; L1, la provenance existe ; L2, une plateforme de build hébergée qui signe la provenance ; et L3, des builds renforcés avec des exécutions isolées et des secrets de signature protégés. La version 1.2 ajoute aussi une piste Source.

Qu'est-ce que la provenance SLSA ?

Un enregistrement de la façon dont un artefact a été construit : quelle plateforme, à partir de quelle source, par quel processus et avec quelles entrées de premier niveau. À partir de Build L2, elle est signée : les consommateurs peuvent donc la vérifier.

Quelle est la différence entre SLSA et une SBOM ?

Une SBOM liste ce qui se trouve à l'intérieur d'un logiciel. La provenance SLSA décrit comment et où il a été construit. En général, il vous faut les deux.

SLSA est-il obligatoire ?

Non. C'est un cadre volontaire issu de la communauté OpenSSF. Certains clients et organisations peuvent demander un niveau, mais ce n'est pas une loi.

Quel niveau SLSA viser ?

Commencez par Build L1 en construisant en CI et en générant la provenance, puis passez à L2 sur une plateforme hébergée, que de nombreuses équipes peuvent atteindre rapidement. L3 convient aux releases dont beaucoup d'autres dépendent ou qui présentent un risque élevé.