Les Les développeurs de Google ont présenté « SLSA » (niveaux de la chaîne d'approvisionnement pour les artefacts logiciels) qui a pour but de prendre en charge les protection des infrastructures de développement d'attaques menées lors des phases de codage, de test, de construction et de distribution d'un produit.
Les développeurs mentionner que les processus de développement sont de plus en plus complexes et dépendent d'outils tiers, qui crée des conditions favorables à la promotion d'attaques liées non pas à l'identification et à l'exploitation de vulnérabilités dans le produit final, mais à l'engagement du processus de développement lui-même.
À propos de la SLSA
Il est mentionné que SLSA se concentre sur les deux principes fondamentaux suivants :
Non unilatéral - Aucune personne ne peut modifier l'artefact logiciel n'importe où dans la chaîne d'approvisionnement du logiciel sans examen et approbation explicites d'au moins une autre "personne de confiance". [^ 1] Le but est la prévention, la dissuasion ou la détection précoce des risques/mauvais changements.
Auditable - L'artefact logiciel peut être retracé en toute sécurité et de manière transparente jusqu'aux sources et dépendances d'origine lisibles par l'homme. L'objectif principal est l'analyse automatisée des sources et des dépendances, ainsi que des enquêtes ad hoc.
Pour bloquer les menaces signalées, SLSA propose un ensemble de directives et d'outils pour automatiser la création de métadonnées pour l'audit. SLSA résume les méthodes d'attaque courantes et introduit le concept de couches de protection.
Chaque couche a des exigences d'infrastructure spécifiques pour assurer l'intégrité des artefacts utilisés dans le développement, c'est-à-dire, plus le niveau de SLSA pris en charge est élevé, plus de défenses seront mises en œuvre et l'infrastructure sera mieux protégée contre les attaques typiques.
SLSA niveau 1
À ce niveau nécessite que le processus de construction soit entièrement automatisé et génère des métadonnées (« Provenance ») sur la façon dont les artefacts sont collectés, y compris les informations sur la source, la dépendance et le processus de génération (un exemple de générateur de métadonnées pour l'audit est fourni pour les actions GitHub). SLSA 1 n'inclut pas d'éléments de protection contre les modifications malveillantesIl identifie uniquement le code de la manière la plus simple et fournit des métadonnées pour la gestion des vulnérabilités et l'analyse des risques.
SLSA niveau 2
Ici, la première couche est étendue en exigeant l'utilisation d'un système de contrôle de source et de services de construction qui génèrent des métadonnées authentifiées. L'utilisation de SLSA 2 vous permet de retracer l'origine du code et empêche les modifications non autorisées dans le code, en cas d'utilisation de services d'assemblage fiables.
SLSA niveau 3
À partir de ce pointou le code source et la plate-forme de construction sont confirmés pour répondre aux exigences des normes pour s'assurer que le code peut être audité et que l'intégrité des métadonnées fournies est garantie. Les auditeurs sont censés être en mesure de certifier les plateformes de conformité aux exigences des normes.
SLSA niveau 4
Il s'agit du niveau le plus élevé et il complète également les niveaux précédents en ajoutant les exigences beaucoup plus strictes dont la revue obligatoire de toutes les modifications par deux développeurs différents, ainsi que toutes les étapes de compilation, le code et les dépendances. entièrement déclaré, toutes les dépendances doivent être extraites et vérifiées séparément, et le processus de génération doit être effectué hors ligne.
L'utilisation d'un processus de compilation reproductible permet également de répéter le processus de compilation et de s'assurer que l'exécutable est compilé à partir des sources fournies.
En plus de cela ce framework prend en compte 8 types d'attaques liés aux menaces de modifications malveillantes dans les phases de développement, de compilation, de test et de distribution du code du produit.
Les types d'attaques pris en compte sont les suivants:
1.- Inclusion dans le code source de modifications contenant des portes dérobées ou des erreurs latentes menant à des vulnérabilités.
2.- Engagement de la plateforme de contrôle de source.
3.- Apporter des modifications à l'étape de transfert de code vers le système de compilation ou d'intégration continue (le code qui ne correspond pas au code du référentiel est collecté).
4.- Engagement de la plate-forme de construction
5.- Promotion de codes malveillants via des dépendances de mauvaise qualité.
6.- Chargement des artefacts non générés dans le système CI/CD.
7.- Compromis du référentiel de paquets.
8.- Confusion chez l'utilisateur d'installer le mauvais package.
Enfin si vous voulez en savoir plus, vous pouvez vérifier les détails dans le lien suivant.