L'intégrité des chaînes d'approvisionnement en logiciels est devenue un sujet de discussion majeur ces dernières années, les attaques contre les chaînes d'approvisionnement en logiciels étant devenues plus fréquentes au cours des deux dernières années. Il est devenu impératif pour les développeurs de choisir avec soin les logiciels et produits externes à inclure dans leurs systèmes logiciels, tout en mettant en place des mesures pour garantir l'intégrité de leurs artefacts logiciels.
Le processus de création et de déploiement de logiciels est assez compliqué, avec de nombreux points de vulnérabilité potentiels tout au long de la chaîne. Au lieu de s'appuyer sur des correctifs spécifiques pour chaque vulnérabilité, il est plus logique pour les développeurs d'adopter un cadre de bout en bout plus complet qui peut aider à atténuer les menaces pendant la phase de développement.
Un de ces cadres est le Niveaux de la chaîne d'approvisionnement pour les artefacts logiciels (SLSA). Ce cadre est une liste de contrôle complète de contrôles et de normes de sécurité qui garantissent l'intégrité des progiciels et de l'infrastructure.
Les SLSA nouvellement introduit Le cadre de sécurité est le fruit d'une collaboration entre OuvertSSF, Google, et autres acteurs de la cybersécurité. Il s'agit d'une norme industrielle convenue qui peut être adoptée par les développeurs, les entreprises et les entreprises pour les aider à faire des choix éclairés concernant la sécurité des logiciels qu'ils créent ou utilisent et à sécuriser l'ensemble du cycle de vie du développement logiciel.
Comment SLSA aide à se défendre contre les attaques de la chaîne d'approvisionnement logicielle
Plus qu'un ensemble de règles, le cadre de sécurité SLSA est un cadre standard qui peut potentiellement renforcer l'intégrité des composants d'un artefact logiciel. Cette ligne directrice de bout en bout agit comme un ensemble de mesures défensives qui empêchent progressivement la falsification ou tout type de modification non autorisée des progiciels qui composent un produit logiciel. L'adoption du cadre SLSA peut aider à protéger votre logiciel contre les problèmes courants. attaques de la chaîne d'approvisionnement tels que les suivants:
Attaques malveillantes du référentiel de validation PHP
En mars 2021, Nikita Popov a annoncé que des acteurs malveillants avaient tenté d'attaquer le code source de PHP en créant une porte dérobée qui leur permettrait d'obtenir un accès non autorisé à la plateforme de code. En cas de succès, l’attaque aurait été dévastatrice, puisque PHP alimente environ 80 % des sites Web sur Internet. Heureusement, l’attaque a été détectée à temps, mais cet incident illustre encore comment les contrôles SLSA peuvent aider à prévenir de telles attaques à l’avenir. Le respect des protocoles SLSA, tels qu'un examen par deux personnes et une authentification à deux facteurs, aurait protégé la plate-forme de code source et en aurait fait une cible beaucoup plus difficile pour les attaquants.
Violation malveillante du compilateur d'Apple
En 2015, les développeurs de logiciels créant des applications pour les produits Apple ont téléchargé une version de Xcode (un outil d'écriture de code pour les appareils Apple) à partir d'une plateforme d'hébergement non vérifiée. La version de Xcode connue sous le nom de XcodeGhost avait été infectée par un code malveillant qui était secrètement transféré aux applications créées avec celui-ci. Il a créé une porte dérobée vers plusieurs applications qui échappaient au processus de révision du code d'Apple et aux applications proposées sur l'App Store. Le framework SLSA contient des protocoles de sécurité liés à la construction qui auraient empêché une attaque comme celle-ci ou l'auraient rendue plus difficile. L'une de ces mesures est l'exigence de construction hermétique qui aurait obligé les développeurs à déclarer toutes leurs sources, y compris l'outil construit qu'ils ont utilisé.
Artefacts malveillants téléchargés
Le 1er avril 2021, l'équipe Codecov a découvert des attaques affectant ses téléchargeurs Bash, notamment Codecov GitHub Action, The Codecov CircleCI Orb et Codecov Bitrise Step. L'attaquant a obtenu un accès non autorisé en extrayant une clé HMAC qui donnait accès au compte du service Google Cloud Storage d'une couche intermédiaire de l'une des images Docker publiques auto-hébergées de Codecov. Cette clé leur a permis de modifier le Bash Uploader pour télécharger des codes malveillants directement vers les utilisateurs finaux. Le framework SLSA aurait détecté cette action en montrant quand les artefacts sont construits d'une manière différente de la forme attendue dans leur référentiel source.
Mauvaise dépendance du flux d'événements
En 2018, des pirates ont publié un package malveillant flatmap-stream sur npm, qui a ensuite été ajouté en tant que dépendance au package de flux d'événements largement utilisé de la plate-forme. Après avoir ajouté la dépendance, les attaquants l'ont mise à jour avec un comportement malveillant. Étant donné que la mise à jour ne correspondait pas au code soumis à GitHub, le framework SLSA aurait détecté l'attaque et empêché le vecteur. Suivre la provenance du code malveillant aurait révélé qu'il ne provenait pas de GitHub ou du constructeur approprié. Quoi qu’il en soit, l’attaque aurait pu être évitée.
Les quatre niveaux de sécurité du cadre de cybersécurité SLSA
Le cadre SLSA est un protocole incrémentiel et exploitable. Il se compose de quatre niveaux, le niveau 4 représentant l'état final idéal d'un système sécurisé. Les artefacts au plus haut niveau répondent à toutes les exigences pour garantir aux consommateurs qu'ils n'ont pas été altérés de quelque manière que ce soit et que tous leurs composants peuvent être retracés jusqu'à leurs sources. Les artefacts des niveaux inférieurs sont ceux qui ont également atteint des étapes progressives avec des garanties d'intégrité spécifiques en fonction de leur rang.
Niveau 1 : poser les bases
Vous pouvez considérer le niveau 1 du framework SLSA comme une sorte de base pour l'ensemble du framework permettant de créer des logiciels sécurisés. À ce stade, les développeurs ou les organisations qui adoptent le SLSA doivent faire deux choses. Premièrement, ils doivent automatiser entièrement leur processus de construction. Cela peut être fait de différentes manières, mais la manière conventionnelle d'automatiser les builds consiste à utiliser un makefile. Les actions GitHub peuvent également être utilisées pour obtenir les mêmes résultats.
La deuxième partie pour atteindre le niveau SLSA 1 consiste à générer une documentation complète de provenance. Il s'agit de métadonnées qui montrent comment un artefact logiciel a été créé. Il doit détailler l'ensemble du processus de construction, toutes les dépendances et les sources de premier niveau utilisées pour sa construction.
Le script du processus de construction et l'affichage de la provenance d'un artefact logiciel de cette manière permettent aux consommateurs de prendre plus facilement des décisions éclairées concernant l'utilisation d'un produit logiciel. Bien que la vérification SLSA 1 ne signifie pas que le logiciel est entièrement protégé contre la falsification, cela facilite l'identification des composants du logiciel. C’est la première étape de la gestion des vulnérabilités.
Niveau 2 : assurez-vous que votre processus de création est inviolable
Le niveau 2 du cadre SLSA est l'endroit où vous commencez à mettre en place des mesures pour garantir que votre processus de construction est aussi inviolable que possible. Atteindre le niveau 2 du cadre SLSA donne également au consommateur plus de confiance quant à l'origine du logiciel.
Encore une fois, cela se fait en deux étapes, la première consistant à utiliser le contrôle de version et la seconde impliquant l'utilisation d'un service de build hébergé pour authentifier la provenance. Pour la première étape, GitHub, GitLab ou tout autre service similaire est utilisé pour stocker le code et enregistrer toutes les modifications qui y sont apportées. Le suivi des modifications de version de cette manière facilite la compréhension des modifications apportées à l'artefact au cours du processus de construction.
Bien que le niveau 2 nécessite une documentation de provenance, tout comme le niveau 1, la différence ici est que l'artefact logiciel doit être authentifié par un service de build hébergé. Le service hébergé sert de tiers de confiance qui peut confirmer que le processus de construction détaillé dans le document de provenance initial est exact. GitHub Actions est un type de service d'hébergement qui peut fournir une provenance authentifiée.
Niveau 3 : contrôles de sécurité de SLSA
Le niveau 3 est l'endroit où vous commencez à mettre en œuvre le contrôle de sécurité spécifique, comme souligné dans le cadre SLSA. Pour atteindre ce niveau, les plates-formes de source et de construction de vos artefacts logiciels doivent répondre à des normes spécifiques qui garantissent que la source est auditable et que la provenance du code est fiable. SLSA niveau 3 offre une garantie bien plus forte que l'artefact est bien protégé contre la falsification et des classes spécifiques de menaces.
Certaines des exigences spécifiques du niveau 3 comprennent :
- Historique et conservation vérifiés du code source—Un historique vérifié du code source garantit que toute modification apportée au code source du logiciel est accompagnée d'une identité authentifiée de l'auteur, du réviseur ou du téléchargeur qui a effectué la modification avec des horodatages spécifiques de la modification. Cet historique des modifications doit également être conservé pendant au moins 18 mois.
- Constructions isolées dans des environnements éphémères—Pour répondre à cette exigence, les builds logiciels doivent être implémentés dans des environnements éphémères où ils sont complètement indépendants de toute autre instance de build. Pour y parvenir, vous pouvez utiliser un service comme GitHub Actions, qui utilise une machine de build virtuelle pour produire votre build à la demande.
- Construit sous forme de code—Ces critères exigent que vous traitiez vos fichiers de build comme du code. Cela signifie qu'ils doivent être stockés dans un système de contrôle de version qui permet de recréer les processus de build si nécessaire.
- Provenance infalsifiable—Le but de cette exigence est d'empêcher les utilisateurs de falsifier la documentation de provenance générée par le service de construction.
Niveau 4—Confiance des consommateurs
Le niveau 4 du cadre SLSA vise à garantir que le logiciel n'a pas été falsifié de quelque manière que ce soit. Seuls les artefacts logiciels qui satisfont aux exigences suivantes peuvent atteindre le niveau 4 du cadre :
Examen par deux personnes de tous les changements
Ce critère exige que les organisations désignent deux examinateurs qualifiés pour examiner minutieusement toute modification proposée au code et aux composants du logiciel. Ce processus de révision par deux personnes garantit que seuls des développeurs fiables et authentifiés peuvent apporter des modifications aux artefacts logiciels.
Un processus de construction hermétique et reproductible
Un processus de construction est dit hermétique lorsque toutes les entrées sont spécifiées à l’avance et en dehors du processus de construction. Cette règle s'applique au code source ainsi qu'à tous les compilateurs, bibliothèques et outils utilisés dans la build. Cela permet de garantir l’intégrité de toutes les importations tierces. Les critères de construction reproductibles ne sont pas une exigence obligatoire, mais sont également recommandés. Les critères exigent que le processus de génération produise le même résultat, quel que soit l'endroit et le moment où il est exécuté.
Exigences techniques pour répondre aux niveaux SLSA
Le cadre SLSA comporte des exigences techniques spécifiques pour les différents niveaux. Ces exigences sont classées en cinq catégories principales : les exigences en matière de source, les exigences en matière de processus de construction, les exigences communes, les exigences en matière de contenu de provenance et les exigences en matière de génération de provenance. Chacune de ces catégories d’exigences est mise en évidence ci-dessous.
Exigences relatives aux sources
Il s'agit d'exigences destinées à garantir l'intégrité de votre code source. Le respect de ces ensembles de protocoles empêche la falsification et les modifications malveillantes de votre code. Cela garantit également que toute action néfaste ne passe pas inaperçue. Les exigences en matière de source sont définies dans le tableau ci-dessous.
| Exigences relatives aux sources | Description | Niveau SLSA |
| Contrôle de version | Toutes les modifications apportées au code source doivent être suivies. | 2 |
| Historique vérifié | Un historique complet détaillant « qui », « quoi » et « quand » de chaque révision de version doit être enregistré. | 3 |
| Conservé indéfiniment | Toutes les modifications de version et les informations d'historique doivent être stockées indéfiniment et ne doivent pas être supprimées. | 4 |
| Examen par deux personnes | Deux personnes de confiance et hautement authentifiées doivent autoriser tout changement de version. | 4 |
Exigences de construction
Le cadre SLSA met en évidence les exigences de construction destinées à améliorer la sécurité de la plate-forme de construction et à maintenir l'intégrité du processus de construction.
| Exigences de construction | Description | Niveau SLSA |
| Construction scriptée | Toutes les étapes du processus de construction doivent être entièrement automatisées. | 1 |
| Service de construction | Toutes les étapes du processus de build doivent s'exécuter sur un service de build dédié. | 2 |
| Environnement éphémère et isolé | Le processus de build doit s'exécuter dans un environnement éphémère fourni spécifiquement pour le build. Les étapes doivent également s'exécuter dans un environnement isolé, exempt d'autres instances de build.
|
3 |
| Sans paramètre et hermétique | Le processus de construction doit s'appuyer entièrement sur le script de construction plutôt que sur les paramètres utilisateur. Toutes les étapes de construction transitive doivent être hermétiques, ce qui signifie que toutes les sources et dépendances doivent être entièrement déclarées dès le départ et en dehors du processus de construction. | 4 |
Exigences de génération de provenance
Ces exigences visent à vérifier la source de tous les composants d'un actif logiciel. Les exigences en matière de génération de provenance sont mises en évidence dans le tableau ci-dessous.
| Exigences de génération de provenance | Description | Niveau SLSA |
| Disponible | Le consommateur devrait avoir accès aux informations sur la provenance dans un format acceptable. | 1 |
| Vérifiable : | Le consommateur devrait être en mesure de vérifier l'authenticité des informations sur la provenance fournies. | 1 |
| Généré par le service | Toutes les informations de provenance doivent être générées par le service de build.
|
2 |
| Infalsifiable | Les utilisateurs ne peuvent pas falsifier les données de provenance. | 3 |
| Dépendances complètes | Les données de provenance doivent inclure toutes les dépendances utilisées lors des étapes de construction. | 4 |
Exigences relatives au contenu de provenance
Les exigences de contenu de provenance vérifient l'identité et la source de tous les artefacts, dépendances et restrictions de build qui ont été utilisés dans le processus de build. Ils sont mis en évidence dans le tableau ci-dessous.
| Exigences relatives au contenu de provenance | Description | Niveau SLSA |
| Identifie l'artefact, le constructeur, la source et le point d'entrée. | ● Identifie l'artefact de sortie
● Identifie l'entité de construction ● Identifie la source via une référence immuable ● Identifie la commande qui a appelé le script de construction |
1 |
| Comprend tous les paramètres de construction | Tous les paramètres de construction doivent être identifiés.
|
3 |
| Comprend des dépendances transitives et des informations reproductibles | ● Inclut toutes les dépendances transitives
● Si la construction est reproductible, toutes les informations nécessaires à sa reproduction doivent être fournies
|
4 |
| Comprend des métadonnées | Toutes les métadonnées doivent être incluses pour faciliter les enquêtes. | 0 |
Exigences communes
Les exigences communes s'appliquent aux artefacts logiciels du niveau 4 de SLSA. Chaque artefact approuvé doit répondre à ces exigences. Ils incluent des exigences de sécurité de base et des journaux qui détaillent tous les accès physiques et à distance. Les exigences communes stipulent également qu'un petit nombre d'administrateurs de plate-forme peuvent remplacer les stipulations de la documentation SLSA.