Comment sécuriser votre chaîne d'approvisionnement en logiciels Python ?

Dans les industries traditionnelles, une chaîne d'approvisionnement est tout ce qui permet à une entreprise de livrer un produit au client. Par exemple, lorsque vous achetez un croissant à la boulangerie, tous les ingrédients, l'emballage et le transport font partie de la chaîne d'approvisionnement.

Dans le domaine du logiciel, une chaîne d'approvisionnement est tout ce qui affecte votre logiciel avant son déploiement en production. Elle couvre tout, de la phase de développement au processus de mise en production, y compris le code que vous avez écrit, vos dépendances, votre environnement de construction, votre IDE, votre registre d'images - chaque composant avec lequel votre logiciel interagit à un moment ou à un autre !

Le terme “chaîne d'approvisionnement” a récemment été mis en lumière par des cyberattaques qui ont eu un impact considérable. Parmi toutes les attaques, Solarwinds est peut-être la plus célèbre. En effet, le gouvernement américain, de grandes entreprises technologiques comme Microsoft et Intel, mais aussi des hôpitaux, des compagnies d'électricité et des institutions financières ont été touchés.

Ironiquement, la cause première est l'infection de Solarwinds Orion, un moniteur de sécurité réseau. Le système de construction a été compromis et toutes les nouvelles versions entre mars et juin 2020 ont été infectées par des logiciels malveillants. Par conséquent, tous les clients qui ont mis à jour leur logiciel au cours de cette période ont été compromis.

Même si l'attaque de Solarwinds a été largement couverte par les médias, il existe des dizaines d'attaques similaires dont nous n'avons jamais entendu parler. Heureusement, la Cloud Native Computing Foundation les recense toutes dans une base de données. dépôt public. Vous serez peut-être surpris par l'accélération de ces attaques au cours des dernières années.

Il n'est pas possible de couvrir tous les aspects liés à la sécurité de la chaîne d'approvisionnement dans un seul article de blog. C'est pourquoi nous nous concentrerons dans cet article sur les projets qui utilisent Python comme langage principal.

Même si Python a une philosophie “batteries incluses”, vous avez souvent besoin de bibliothèques externes que vous pouvez télécharger à partir de PyPI, l'index officiel des paquets, et c'est à ce stade que vous devez être très prudent.

L'écosystème Python a déjà été ciblé, notamment par l'utilisation de deux techniques :

La première technique concerne une commande que tout développeur Python a exécutée au moins une fois au cours de sa carrière :

pip install 

Les pirates publient des paquets portant presque le même nom que des paquets existants en espérant que vous ferez une erreur de frappe et que vous installerez leur paquet au lieu du paquet officiel. Par exemple, un paquet appelé python3-dateutil au lieu de l'officiel dateutil a été récemment détecté.

La communauté python est travailler dur pour atténuer le risque, mais celui-ci reste élevé.

La deuxième technique, la confusion de dépendance, est plus sophistiquée que la première. tuyau fonctionne sous le capot.

Cette fois, cette commande vous expose au risque :

pip install --extra-index-url 

Lorsque vous tapez cette commande, voici ce qui se passe :

Prenons un exemple :

Dans cet exemple, le paquet du hacker malveillant sera installé sur la machine. En effet, le numéro de version le plus élevé figure dans l'index public des paquets.

Vous avez peut-être compris ce qui peut mal se passer avec ce processus. Quelqu'un de mal intentionné peut publier sur un dépôt public des paquets portant les mêmes noms que ceux hébergés dans les index de paquets internes et les étiqueter avec un numéro de version ridiculement élevé. De plus, trouver des noms de paquets pertinents n'est pas si difficile que cela. démontré par ce chercheur en sécurité.

Cette commande pourrait être qualifiée d“”insecure by design". Cette attaque exploite une fonctionnalité du gestionnaire de paquets Python et seuls quelques développeurs sont au courant de ce comportement.

Pour vous prémunir contre les attaques de "typo-squatting", vous pouvez utiliser un filtre de type verrouiller le fichier. A bon fichier de serrure possède les attributs suivants :

La bonne nouvelle, c'est qu'il existe un paquet dont le but est de créer un fichier de verrouillage pour vous : pip-tools. Quelques commandes suffisent pour générer un fichier de verrouillage doté de tous les attributs décrits précédemment.

$ python3 -m venv my-env # créer un nouvel environnement virtuel
$ source my-env/bin/activate # activez-le
$ pip install pip-tools==6.3.0 # installez le paquet qui vous permettra de gérer correctement les dépendances.
de gérer correctement vos dépendances
$ echo “sacremoses==0.0.46” >> requirements.in # ajoutez le paquet de votre choix dans requirements.in.
votre choix dans requirements.in
$ pip-compile --generate-hashes # compile le fichier requirements.txt avec des
des hachages basés sur ce que vous avez mis dans requirements.in

Votre fichier requirements.txt doit ressembler à ceci :

Maintenant que vous avez ce fichier qui contient toutes vos dépendances avec leurs versions et hachages associés, vous pouvez exécuter la commande suivante lors du prochain déploiement :

pip install --require-hashes -r requirements.txt

Ainsi, vous êtes sûr que les paquets que vous utilisez en production n'ont pas été modifiés. En supposant que vous ayez été prudent lors de l'écriture de votre exigences.in 👀, vous pouvez également être sûr de télécharger le paquet que vous voulez vraiment, car tout est automatisé. Aucun risque de faute de frappe !

Cette bonne pratique permet de se prémunir contre les attaques de "typo-squatting", mais qu'en est-il de la confusion des dépendances ?

Si vous regardez le tuyau vous verrez qu'il y a deux options que vous pouvez utiliser pour télécharger des paquets à partir d'un dépôt interne :

La documentation indique :

Comme vous pouvez le constater, il existe une légère différence entre les deux et elle n'est pas évidente à première vue. La différence réside dans le fait que si vous avez spécifié l'option --index-url option, tuyau n'extraira que les paquets du dépôt dont vous avez fourni l'URL, et non des dépôts publics. Donc, si vous voulez éviter le comportement que nous avons décrit plus tôt, utilisez --index-url plutôt que --extra-index-url et vous serez en sécurité !

Enfin, pour suivre les dernières vulnérabilités découvertes dans vos dépendances, vous pouvez choisir de vérifier périodiquement le fichier Avis GitHub database ou mieux, utilisez des outils tels que robot dépendant qui soumettra automatiquement une pull request sur votre repo pour mettre à jour une dépendance dans laquelle une vulnérabilité critique a été récemment identifiée.

Dans cet article, nous avons introduit le concept de chaîne d'approvisionnement pour le monde du logiciel. Nous avons spécifiquement étudié comment ce concept s'applique à l'écosystème Python. Le typo-squatting et la confusion des dépendances ont été expliqués et des solutions ont été proposées pour atténuer le risque d'être compromis.

Cette brève introduction à la sécurité de la chaîne d'approvisionnement n'a couvert que la partie émergée de l'iceberg, nous n'avons pas eu l'occasion de discuter de la manière dont la sécurité de la chaîne d'approvisionnement est assurée. construire des systèmes ou même votre IDE peut être compromise, mais je laisse cela pour un autre article !

Merci d'avoir lu jusqu'ici ! Je serais heureux d'entendre vos commentaires. Si vous avez apprécié cette lecture, n'hésitez pas à consulter notre rubrique postes ouverts à l'adresse Artefact 🙂 .