SLSA a rendu la sécurité de la chaîne d'approvisionnement adoptable en la transformant en niveaux

Après SolarWinds, Codecov et d'autres attaques de la chaîne de compilation, les consommateurs de logiciels devaient savoir si un artefact provenait de la source et du processus de compilation attendus. Un binaire seul ne pouvait pas répondre à cette question.

La démarche de SLSA n'était pas d'exiger la perfection immédiatement. La proposition de Google en 2021 décrivait quatre niveaux adoptables par étapes, commençant par des compilations automatisées générant une provenance et s'élevant vers un isolement de compilation, une revue et une reproductibilité plus forts.

La spécification v1.0 a affiné cela en pistes et niveaux : un vocabulaire partagé, une liste de contrôle et un modèle de preuves pour les producteurs, les consommateurs et les fournisseurs d'infrastructure. Le format a gagné en rendant lisible un progrès partiel au lieu de traiter la sécurité comme du tout-ou-rien.

Faire de l'intégrité une échelle, pas un interrupteur

Les niveaux permettaient aux organisations de revendiquer une posture d'intégrité spécifique sans prétendre que chaque dépendance était parfaite.

La provenance rendait le processus de compilation vérifiable par les moteurs de politiques et les consommateurs.

Le cadre associait le risque abstrait de la chaîne d'approvisionnement à des contrôles concrets de source, de compilation et de distribution.

Les niveaux inférieurs créaient un chemin de mise à niveau pour les projets qui ne pouvaient pas atteindre directement la barre la plus élevée.

Lorsque la norme idéale est trop coûteuse pour la plupart des utilisateurs, l'adoption peut commencer par nommer des garanties partielles qui réduisent tout de même le risque.

SLSA est devenu un langage commun pour l'intégrité des artefacts logiciels. Ses niveaux sont désormais utilisés aux côtés des SBOM, de Sigstore et des attestations in-toto pour décider si un paquet a été compilé par un système attendu à partir d'une source attendue.