Les attaques de la chaîne d'approvisionnement des logiciels devenant une préoccupation majeure après l'incident de sécurité de SolarWinds et de Codecov, Google propose une solution pour garantir l'intégrité des paquets logiciels et empêcher les modifications non autorisées. Nommé "Supply chain Levels for Software Artifacts" (SLSA, et prononcé "salsa"), le framework de bout en bout vise à sécuriser le pipeline de développement et de déploiement des logiciels ‘ c'est-à-dire le flux de travail source ➞ build – publish) et à mitiger les menaces qui résultent de l'altération du code source, de la plateforme de build et du dépôt d'artefacts à chaque point de la chaîne.

Google a déclaré que la SLSA s'appuie sur le mécanisme d'application interne de l'entreprise appelé Binary Authorization for Borg, un ensemble d'outils d'audit qui vérifie la provenance du code et met en œuvre l'identité du code afin de garantir que les logiciels de production déployés sont correctement vérifiés et autorisés.

"Dans son état présent, SLSA est un ensemble de directives de sécurité adoptées progressivement et établies par des standards de industry consensus ", ont déclaré Kim Lewandowski de l'équipe de sécurité open source de Google et Mark Lodato de l'équipe Binary Authorization for Borg.

" Dans sa forme finalisée, SLSA se distinguera d'une liste de bonnes pratiques par son applicabilité : elle prendra en charge la création automatique de métadonnées vérifiables qui pourront être introduites dans des moteurs de politique pour donner une " certification SLSA " à un paquet ou une plateforme de construction particulière. "

Le cadre SLSA garantit l'intégrité de la supply chain de logicielle de bout en bout et est conçu pour être à la fois incrémentiel et actionnable. Il comprend quatre niveaux différents de complexité progressive de la sécurité des logiciels, SLSA 4 offrant un degré élevé de confiance dans le fait que le logiciel n'a pas été modifié de manière illicite.

· SLSA 1 — Nécessite que le processus de génération soit entièrement scripté/automatisé et génère une provenance

· SLSA 2 — Nécessite l'utilisation du contrôle de version et d'un service de build hébergé qui génère une provenance authentifiée

· SLSA 3 — Exige que la source et les plates-formes de construction répondent à des normes spécifiques pour garantir l'audibilité de la source et l'intégrité de la provenance

· SLSA 4 — Nécessite un examen par deux personnes de tous les changements et un processus de construction hermétique et reproductible

"Des niveaux plus élevés de SLSA exigent des contrôles de sécurité plus stricts pour la plate-forme de construction, ce qui rend plus difficile la compromission et la persistance", ont précisé Lewandowski et Lodato.

Alors que SLSA 4 représente l'état final idéal, les niveaux inférieurs fournissent des garanties d'intégrité progressives, ce qui rend difficile pour les acteurs malveillants de rester cachés dans un environnement de développement compromis pendant de longues périodes.

Google a partagé des détails supplémentaires sur les exigences en matière de source et de construction qui doivent être respectées, et appelle également l'industrie à normaliser le système et à définir un modèle de menace qui détaille les menaces spécifiques que SLSA espère résoudre à long terme.

"Atteindre le plus haut niveau de SLSA pour la plupart des projets peut être difficile, mais les améliorations progressives reconnues par les niveaux inférieurs de SLSA contribueront déjà largement à améliorer la sécurité de l'écosystème open source", a déclaré la société.