Gestionnaire de paquets Python Poetry et intégration de la sécurité avec un outil d’analyse de la composition logicielle

J’ai toujours pensé que les gestionnaires de paquets pouvaient être une arme redoutable dans la lutte contre les dépendances vulnérables. S’ils permettaient de détecter ces dépendances, les développeurs pourraient identifier et corriger leurs vulnérabilités plus facilement et plus rapidement, plutôt que de les laisser s’immiscer dans le processus de build.

Pour que cela fonctionne, la solution doit toutefois être :

1. simple — très facile à utiliser

2. intégrée — elle doit s’inscrire dans le workflow des développeurs et fonctionner avec le gestionnaire de paquets concerné

J’ai récemment commencé à utiliser le système de gestion de paquets Python Poetry. J’aime beaucoup son organisation et la manière dont il atteint certains de ses objectifs déclarés. J’espérais donc trouver une fonctionnalité d’analyse de sécurité pouvant s’y intégrer.

C’est pourquoi j’ai été ravi d’apprendre que Snyk avait récemment lancé une nouvelle fonctionnalité prenant en charge le gestionnaire de paquets Poetry et la poetry lock syntax. Pour voir de plus près comment cela fonctionne, je me suis connecté à mon compte de test Snyk que je venais de créer, puis j’ai créé un projet contenant des dépendances volontairement vulnérables.

Play Video: DevSecOps with Poetry and Source Composition Analysis

J’ai saisi la commande pour créer un projet appelé Poetry snyk. Elle a créé un répertoire nommé « poetry snyk » et un paquet nommé poetry_snyk — essentiellement du code standard, ainsi qu’un paquet TOML.

Si je me rends dans poetry_snyk et que j’exécute tree,, je vois un fichier readme qui contient le nom du paquet racine poetry_snyk. Le fichier TOML est le descripteur de Poetry et contient également des tests standard — plus ou moins un test pytest qu’il a généré.

Dans le projet TOML, vous pouvez voir que nous utilisons Python 3.7(une version légèrement ancienne de Python, je l’admets, mais c’est néanmoins la version locale de Python que j’utilise pour des raisons de dépendances). Nous utilisons également une dépendance de développement de test appelée pi test — en l’occurrence, la pi test 5.2 version (3.7 correspond au cœur Python de pi, qui propose également un build que je n’utilise pas).

Il faut savoir que Poetry remplace les fichiers requirements.txt et setup.py auparavant nécessaires par un fichier TOML. Ainsi, avec Poetry, vous pouvez non seulement configurer et suivre les dépendances, mais aussi créer des éléments et les publier sur le Python cheese shop. Il est assez intéressant de constater qu’un seul fichier TOML peut remplacer les fichiers setup.py et requirements.txt dans leur intégralité.

Ce que j’apprécie avec Poetry, par rapport aux gestionnaires de paquets précédents, c’est qu’il s’agit d’une solution intégrée plutôt que d’un assemblage de solutions disparates.

Beaucoup des gestionnaires de paquets que j’ai utilisés auparavant — même Pipenv — me semblaient incomplets, car ils reposaient sur la base de code du gestionnaire de paquets pip et faisaient davantage office de wrapper. Je trouve que Poetry va plus loin, car il reformule le problème en combinant, d’une part, le meilleur de npm, avec son descripteur et son fichier de verrouillage, et, d’autre part, le système de gestion de paquets Cargo de Rust. Le gestionnaire de paquets Cargo pour Rust fournit d’emblée de la documentation et des tests. Je pense que Poetry a essayé de combiner ces deux aspects et de proposer cette approche.

Nous avons maintenant créé un nouveau projet Poetry appelé poetry_snyk et configuré le projet, mais nous devons également installer des bibliothèques pour le faire fonctionner. Comme je l’utilise avec Snyk, je veux le tester avec des bibliothèques non sécurisées — généralement des bibliothèques déjà connues — afin de voir si Snyk peut les détecter lors de l’analyse. Snyk a besoin que deux fichiers soient disponibles. Ajoutons donc des dépendances à notre projet à l’aide du code suivant : 

Il s’agit d’un projet docx project python.xproject qui permet d’analyser et de créer des fichiers docx. Il est vulnérable à une faille liée aux entités externes XML. C’est une faille assez grave que j’ai présentée plusieurs fois lors de mes formations.

En gros, si vous chargez un document Word malveillant contenant une entité XML définie sur une valeur telle que /etc/passwd, la bibliothèque docx résout cette entité, ce qui entraîne une inclusion de fichier local et peut même être combiné à d’autres techniques pour créer un exploit d’exécution de code à distance. Je vais toutefois l’installer : les dépendances et les dépendances imbriquées seront résolues. Le fichier TOML sera également mis à jour et un fichier poetry.lock sera ajouté. Le fichier poetry.lock répertorie toutes les dépendances imbriquées de cette dépendance de premier niveau.

Vous pouvez constater qu’il répertorie toutes les dépendances imbriquées nécessaires, car tous les outils d’analyse — en particulier Snyk et de nombreux autres outils d’analyse du code source ou des paquets — en ont besoin pour analyser ces dépendances.

En plus des dépendances imbriquées, le fichier indique également la version utilisée pour chacune d’elles, ainsi que sa valeur de hachage, afin de garantir une correspondance correcte. C’était une lacune importante de l’écosystème Python, car le gestionnaire de dépendances pip, le gestionnaire de dépendances Python par défaut, ne fournissait pas tous ces détails : il se contentait de les répertorier sans verrouiller précisément les versions. Il ne gérait donc pas très bien les sous-dépendances.

Imaginons que j’installe un autre paquet avec Poetry. J’installe un autre paquet Python vulnérable, en l’occurrence pyyaml. Je vais utiliser la version 3.13, qui est vulnérable à une faille de désérialisation non sécurisée. Si cette faille est exploitée, l’attaquant peut exécuter du code à distance dans l’environnement de l’application cible. Je vais l’installer, et vous verrez que cela devrait également mettre à jour mon fichier TOML et mon fichier de verrouillage.

Surveillons maintenant le projet avec Snyk en saisissant le code suivant :

On dirait que toutes mes dépendances ont été analysées. Voici mon projet Snyk — ou mon organisation Snyk — généré avec la liste de tous mes projets. Vous voyez que j’ai créé ce projet.

Comme vous pouvez le voir, des problèmes ont été signalés et ils sont tous de gravité élevée : la désérialisation non sécurisée dans pyyaml, la même exécution de code à distance dans pyyaml, un exploit bien connu et sérieux, ainsi que les injections d’entités externes XML dans python-docx. Grâce à sa base de données complète et à la simplicité de son intégration, Snyk a détecté toutes les vulnérabilités présentes dans les dépendances utilisées par ce projet !

Pour commencer

Pour commencer à utiliser cette intégration, il vous suffit d’installer votre projet Poetry. Snyk peut alors le suivre et vous envoyer des notifications par e-mail au sujet de ces dépendances. C’est vraiment pratique !

 J’ai pu configurer rapidement un projet Poetry, l’analyser avec Snyk pour détecter les problèmes de sécurité et obtenir un rapport détaillé sur leurs conséquences.

N’oubliez pas que Snyk a besoin de ces deux fichiers — le fichier de verrouillage et le fichier TOML — pour que l’intégration fonctionne.