Google a proposé SLSA pour se protéger contre les modifications malveillantes durant le développement

La société Google a présenté le cadre SLSA (Supply-chain Levels for Software Artifacts), qui synthétise l'expérience acquise en matière de protection de l'infrastructure de développement contre les attaques survenant lors de l'écriture du code, des tests, de la construction et de la distribution du produit.

Les processus de développement deviennent de plus en plus complexes et dépendent d'outils tiers, créant ainsi des conditions favorables à la promotion d'attaques qui ne visent pas à identifier et exploiter des vulnérabilités dans le produit final, mais à compromettre le processus de développement lui-même (les attaques de la « chaîne d'approvisionnement », qui visent généralement à introduire des modifications malveillantes lors de l'écriture du code, à remplacer les composants et les dépendances distribués).

Le cadre prend en compte 8 types d'attaques liées aux menaces d'introduction de modifications malveillantes au stade du développement du code, de la construction, des tests et de la distribution du produit.

• A. Inclusion dans le code source de modifications contenant des portes dérobées ou des erreurs cachées entraînant des vulnérabilités.

  Exemple d'attaque : « Hypocrite Commits » — tentative de promotion de patchs vulnérables dans le noyau Linux.

  Méthode de protection proposée : examen indépendant de chaque modification par deux développeurs.

• B. Compromission de la plateforme de gestion du code source.

  Exemple d'attaque : introduction de commits malveillants avec une porte dérobée dans le dépôt Git du projet PHP après une fuite de mots de passe des développeurs.

  Méthode de protection proposée : renforcement de la sécurité de la plateforme de gestion du code (dans le cas de PHP, l'attaque a été réalisée via une interface HTTPS peu utilisée, permettant d'envoyer des modifications lors de l'authentification par mot de passe sans vérifier la clé SSH, alors qu'un hachage MD5 peu fiable était utilisé pour les mots de passe).

• C. Introduction de modifications lors du transfert de code au système de construction ou d'intégration continue (le code construit ne correspond pas au code du dépôt).

  Exemple d'attaque : introduction d'une porte dérobée dans Webmin par des modifications apportées à l'infrastructure de construction, entraînant l'utilisation de fichiers avec un code différent de celui des fichiers du dépôt.

  Méthode de protection proposée : vérification de l'intégrité et identification de la source du code entrant dans le système de construction. le serveur.

• D. Compromission de la plateforme de construction.

  Exemple d'attaque : attaque SolarWinds, au cours de laquelle, lors de la phase de construction, l'introduction d'une porte dérobée dans le produit SolarWinds Orion a été assurée.

  Méthode de protection proposée : mise en œuvre de mesures avancées pour sécuriser la plateforme de construction.

• E. Propagation de code malveillant à travers des dépendances de mauvaise qualité.

  Exemple d'attaque : introduction d'un backdoor dans la bibliothèque populaire event-stream, par l'ajout d'une dépendance inoffensive suivie de l'inclusion d'un code malveillant dans l'une des mises à jour de cette dépendance (la modification malveillante n'était pas reflétée dans le dépôt git, mais était seulement présente dans le paquet MNP prêt).

  Méthode de protection proposée : application récursive des exigences SLSA à toutes les dépendances (dans le cas d'event-stream, la vérification aurait révélé une construction de code ne correspondant pas au contenu du dépôt Git principal).

• F. Chargement d'artefacts non créés dans le système CI/CD.

  Exemple d'attaque : ajout de code malveillant dans le script CodeCov, permettant aux attaquants d'extraire des informations stockées dans les environnements des systèmes d'intégration continue des clients.

  Méthode de protection proposée : contrôle de la source et de l'intégrité des artefacts (dans le cas de CodeCov, il aurait été possible de constater que le script Bash Uploader fourni par le site codecov.io ne correspondait pas au code du dépôt du projet).

• G. Compromission du dépôt des paquets.

  Exemple d'attaque : des chercheurs ont réussi à déployer des miroirs de certains dépôts de paquets populaires dans le but de distribuer des paquets malveillants à travers eux.

  Méthode de protection proposée : vérification que les artefacts distribués sont construits à partir des sources déclarées.

• H. Induction en erreur de l'utilisateur pour installer le mauvais paquet.

  Exemple d'attaque : utilisation de type-squatting (NPM, RubyGems, PyPI) pour héberger dans les dépôts des paquets ressemblant à des applications populaires (par exemple, coffe-script au lieu de coffee-script).

Pour contrer les menaces identifiées, SLSA propose un ensemble de recommandations et des outils pour automatiser la création de métadonnées pour l'audit. SLSA résume les méthodes d'attaques courantes et introduit la notion de niveaux de protection. Chaque niveau impose des exigences spécifiques à l'infrastructure, garantissant l'intégrité des artefacts utilisés dans le développement. Plus le niveau SLSA supporté est élevé, plus les mesures de protection mises en œuvre sont nombreuses et meilleure est la protection de l'infrastructure contre les attaques courantes.

• SLSA 1 — exige que le processus de construction soit entièrement automatisé et génère des métadonnées (« provenance ») sur la manière dont les artefacts sont rassemblés, y compris des informations sur les textes sources, les dépendances et le processus de construction (un exemple de générateur de métadonnées pour l'audit a été proposé pour GitHub Actions). SLSA 1 n'inclut pas d'éléments de protection contre les modifications malveillantes, mais identifie simplement le code et fournit des métadonnées pour la gestion des vulnérabilités et l'analyse des risques.
• SLSA 2 — élargit le premier niveau en exigeant l'utilisation d'un système de gestion de version et de services de construction, générant des métadonnées authentifiées. L'application de SLSA 2 permet de suivre l'origine du code et empêche les modifications non autorisées, à condition d'utiliser des services de construction dignes de confiance.
• SLSA 3 — confirme que les textes sources et la plateforme de construction respectent les exigences des normes garantissant la possibilité d'audit du code et l'intégrité des métadonnées fournies. Il est prévu que les auditeurs puissent certifier les plateformes pour leur conformité aux exigences des normes.
• SLSA 4 — le niveau le plus élevé, complétant les niveaux précédents avec les exigences suivantes :
  • Examen obligatoire de toutes les modifications par deux développeurs différents.
  • Tous les étapes de construction, le code et les dépendances doivent être entièrement déclarés, toutes les dépendances doivent être extraites et vérifiées séparément, et le processus de construction doit s'exécuter sans accès au réseau.
  • Application d'un processus de construction reproductible — la possibilité de reproduire le processus de construction par ses propres moyens et de s'assurer que le fichier exécutable est construit à partir des textes sources fournis.
  
  
  Source : opennet.ru