Le framework SLSA

Supply chain Levels for Software Artifacts

Ce framework met l’accent sur la nécessité de garantir l’intégrité des artefacts logiciels tout au long de la chaîne d’approvisionnement logicielle.

Son implématation peut se faire par niveau qui sont au nombre de 4 :

• SLSA 1 : exige que le processus de génération soit entièrement scripté/automatisé et génère une provenance. La provenance est une métadonnée sur la façon dont un artefact a été construit, y compris le processus de génération, la source de niveau supérieur et les dépendances. Connaître la provenance permet aux consommateurs de logiciels de prendre des décisions de sécurité basées sur les risques. Bien que la provenance à SLSA 1 ne protège pas contre la falsification, elle offre un niveau de base d’identification de la source du code et peut aider à la gestion des vulnérabilités.
• SLSA 2 : Nécessite l’utilisation du contrôle de version et d’un service de génération hébergé qui génère une provenance authentifiée. Ces exigences supplémentaires donnent au consommateur une plus grande confiance dans l’origine du logiciel. À ce niveau, la provenance empêche la falsification dans la mesure où le service de build est approuvé. SLSA 2 fournit également un chemin de mise à niveau facile vers SLSA 3.
• SLSA 3 : exige en outre que les plates-formes source et de construction répondent à des normes spécifiques pour garantir l’auditabilité de la source et l’intégrité de la provenance, respectivement. Nous envisageons un processus d’accréditation dans le cadre duquel les auditeurs certifient que les plateformes répondent aux exigences, sur lesquelles les consommateurs peuvent ensuite compter. SLSA 3 offre des protections beaucoup plus solides contre la falsification que les niveaux précédents en empêchant des classes spécifiques de menaces, telles que la contamination croisée.
• SLSA 4: est actuellement le niveau le plus élevé, nécessitant un examen de toutes les modifications par deux personnes et un processus de construction hermétique et reproductible. L’examen par deux personnes est une pratique exemplaire de l’industrie pour détecter les erreurs et dissuader les mauvais comportements. Les builds hermétiques garantissent que la liste des dépendances de la provenance est complète. Les builds reproductibles, bien qu’ils ne soient pas strictement obligatoires, offrent de nombreux avantages en termes d’auditabilité et de fiabilité. Dans l’ensemble, SLSA 4 donne au consommateur un degré élevé de confiance que le logiciel n’a pas été falsifié.

Quelles attaques corrige le framework SLSA ?

SLSA, découpe la chaîne d’approvisionnement logicielle en cinq composantes :

• le code source
• les pipelines de build
• les dépendances directes et indirectes
• les artefacts
• le déploiement

Chacune de ces parties peut subir des attaques dont l’image suivante les liste, permet de les comprendre et apporte une solution possible pour en protéger.

• [A] : Soumettre du code incorrect au référentiel source
  • Exemple : Commits hypocrites ↗ Linux: Un chercheur a tenté d’introduire intentionnellement des vulnérabilités dans le noyau Linux via des correctifs sur la liste de diffusion.
  • Solution proposée : L’examen par deux personnes a permis de détecter la plupart des vulnérabilités, mais pas toutes.
• [B] : Plate-forme de contrôle de code source compromise
  • Exemple : PHP ↗: L’attaquant a compromis le serveur git auto-hébergé de PHP et injecté deux commits malveillants.
  • Solution proposée : Une plate-forme de code source mieux protégée aurait été une cible beaucoup plus difficile pour les attaquants.
• [C] : Construire avec un processus officiel mais à partir de code ne correspondant pas au contrôle de code source
  • Exemple : Webmin ↗ : l’attaquant a modifié l’infrastructure de génération pour utiliser des fichiers sources ne correspondant pas au contrôle de code source.
  • Solution proposée : Un serveur de build conforme à la SLSA aurait permis aux consommateurs de détecter une telle falsification.
• [D] : Plate-forme de build compromise
  • Exemple : L’exemple de SolarWinds
  • Solution proposée : Des niveaux SLSA plus élevés nécessitent des contrôles de sécurité plus stricts pour la plate-forme de build
• [E] : Utiliser une mauvaise dépendance direct ou indirect.
  • Exemple : event-stream ↗ : l’attaquant a ajouté une dépendance inoffensive, puis a mis à jour la dépendance pour ajouter un comportement malveillant. La mise à jour ne correspondait pas au code soumis à GitHub.
  • Solution proposée : L’application récursive de SLSA à toutes les dépendances aurait empêché ce vecteur particulier, car la provenance aurait indiqué qu’il n’avait pas été construit à partir d’un constructeur approprié ou que la source ne provenait pas de GitHub.
• [F] : Télécharger un artefact qui n’a pas été créé par le système CI/CD
  • Exemple : CodeCov ↗ : l’attaquant a utilisé des informations d’identification divulguées pour télécharger un artefact dans la registry d’artefacts malveillant mis à dispostion des utilisateurs.
  • Solution proposée : La provenance de l’artefact dans la registry d’artefacts aurait montré que l’artefact n’a pas été construit à partir du référentiel source attendu.
• [G] : Référentiel de paquets de compromis
  • Exemple : Attaques sur les miroirs de paquets ↗ : Researcher a créé des miroirs pour plusieurs référentiels de paquets populaires, qui auraient pu être utilisés pour servir des paquets malveillants.
  • Solution proposée : Comme ci-dessus (F), la provenance des artefacts malveillants aurait montré qu’ils n’ont pas été construits comme prévu ou à partir du référentiel source attendu.
• [H] : Inciter le consommateur à utiliser une mauvaise source
  • Exemple : Browserify typosquatting ↗ : l’attaquant a téléchargé un paquet malveillant portant un nom similaire à celui de l’original.
  • Solution proposée : SLSA ne traite pas directement cette menace, mais la liaison de la provenance au contrôle de code source peut permettre et améliorer d’autres solutions.