Alors que les attaques de la chaîne d’approvisionnement logicielle deviennent un sujet de préoccupation à la suite des incidents de sécurité SolarWinds et Codecov, Google propose une solution pour garantir l’intégrité des packages logiciels et empêcher les modifications non autorisées.

Appelé « Niveaux de la chaîne d’approvisionnement pour les artefacts logiciels » (SLSA, et prononcé « salsa »), le cadre de bout en bout vise à sécuriser le pipeline de développement et de déploiement de logiciels – c’est-à-dire le flux de travail source ➞ build ➞ publication – et à atténuer les menaces résultant de la falsification du code source , la plate-forme de génération et le référentiel d’artefacts à chaque maillon de la chaîne.

Google a déclaré que la SLSA s’inspire du mécanisme d’application interne de l’entreprise appelé Autorisation binaire pour Borg, un ensemble d’outils d’audit qui vérifie la provenance du code et implémente l’identité du code pour s’assurer que le logiciel de production déployé est correctement examiné et autorisé.

« Dans son état actuel, SLSA est un ensemble de directives de sécurité progressivement adoptées et établies par consensus de l’industrie », mentionné Kim Lewandowski de l’équipe de sécurité Open Source de Google et Mark Lodato de l’équipe d’autorisation binaire pour Borg.

« Dans sa forme finale, SLSA différera d’une liste de meilleures pratiques dans son applicabilité : il prendra en charge la création automatique de métadonnées auditables qui peuvent être introduites dans les moteurs de politique pour donner une « certification SLSA » à un package ou à une plate-forme de build particulier.

Le cadre SLSA promet l’intégrité de la chaîne d’approvisionnement logicielle de bout en bout et est conçu pour être à la fois incrémentiel et exploitable. Il comporte quatre niveaux différents d’une sophistication progressive de la sécurité logicielle, avec SLSA 4 offrant un degré élevé de confiance que le logiciel n’a pas été mal bricolé.

• SLSA 1 — Nécessite que le processus de construction 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’auditabilité 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 de SLSA plus élevés nécessitent des contrôles de sécurité plus stricts pour la plate-forme de construction, ce qui rend plus difficile les compromis et la persistance », ont noté Lewandowski et Lodato.

Alors que le SLA 4 représente l’état final idéal, les niveaux inférieurs offrent des garanties d’intégrité incrémentielles, ce qui rend difficile pour les acteurs malveillants de rester cachés dans un environnement de développement violé pendant de longues périodes.

Parallèlement à l’annonce, Google a partagé des détails supplémentaires sur le La source et Construire exigences qui doivent être satisfaites, et appelle également l’industrie à standardiser le système et à définir un modèle de menace qui détaille les menaces spécifiques que SLSA espère traiter à long terme.

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