SLSA : une spécification stabilisée au prix de compromis

Mieux définie, mais moins ambitieuse ? Ce sont les porteurs de la spécification SLSA qui le disent. Le contexte : la publication de la première version stable (1.0).

Cette mouture est, reconnaissent-ils, moins complète que la précédente (0.1) sur certains aspects. Il n’y a, en particulier, plus que trois niveaux de certification, contre quatre auparavant. Quant aux recommandations en matière de protection contre la manipulation de code source, elles ont disparu.

Autant de compromis nécessaires pour une publication « dans un temps raisonnable », nous explique-t-on. Logique compréhensible si on considère le changement conceptuel significatif qu’apporte cette v1 : une approche divisée en « parcours ».

Dans la version initiale, chacun des niveaux de la spécification englobait des exigences couvrant de multiples aspects de la chaîne d’approvisionnement logicielle (source, build, provenance). Il fallait les respecter toutes pour valider un niveau. Autrement dit, les progrès individuels n’étaient pas valorisés.

La v1 divise chaque niveau en « parcours » (tracks) couvrant chacun un aspect de la supply chain logicielle. Elle n’en définit qu’un (build), les autres étant prévus pour de futures versions de la spécification.

SLSA joue la complémentarité avec in-toto

SLSA (Supply Chain Levels for Software Artifacts ; à prononcer « salsa ») avait pris son envol voilà près de deux ans, sous l’impulsion de Google. Le groupe américain s’était appuyé sur un processus qu’il utilisait alors en interne depuis près d’une décennie. Son nom : autorisation binaire pour Borg. Son principe : vérifier la provenance du code et implémenter son identité.

D’autres groupes sont aujourd’hui dans la boucle, sous l’égide de l’OpenSSF. Parmi eux, Chainguard, Datadog, Intel et Verizon.

En toile de fond, une spécification plus ancienne : in-toto, dont la première version remonte à 2016. Son objectif : définir un format permettant d’attester l’authenticité des opérations menant à un produit logiciel. SLSA la complète en spécifiant quelles informations d’attestation capturer pour garantir un niveau de sécurité donné.

Outre l’approche « parcours », la v1 :

– Réorganise et simplifie le cœur de la spécification (pagination des exigences pour mieux refléter la division des tâches sur la chaîne)

– Documente la vérification des artefacts et des systèmes de build (la 0.1 spécifiait comment attester la provenance ; pas comment la vérifier)

– Met à jour les formats d’attestation de provenance et harmonise leur description

Les exigences de protection contre la manipulation du code source arriveront donc dans une prochaine version de SLSA. Pour rappel, la mouture initiale imposait :

– Authentification forte des auteurs et des vérificateurs
– Rétention du code source pour permettre des inspections ultérieures
– Double révision obligatoire pour tout changement sur la source

Il faudra également attendre pour voir revenir un éventuel niveau 4. Jusqu’alors, il incluait essentiellement :

– Épinglage des dépendances
– Builds hermétiques (blocage de toute dépendance externe)
– Listage de toutes les dépendances dans l’attestation de provenance
– Builds reproductibles (afin que d’autres plates-formes puissent corroborer la provenance)

À consulter pour davantage de contexte :

D’ATT@CK à OSC&R : l’esquisse d’un nouveau framework pour la supply chain logicielle
Le protestware devient un leitmotiv du conflit russo-ukrainien
GitHub déploie l’authentification à deux facteurs
Spring4Shell : faut-il comparer cette faille Java critique à Log4Shell ?

Photo d’illustration © Ferenc Almasi – Unsplash