Administrador de paquetes Python Poetry e integración de seguridad con una herramienta de análisis de composición de software

Siempre he creído que los administradores de paquetes pueden ser el arma definitiva en la lucha contra las dependencias vulnerables. Si se pueden aprovechar para buscar dependencias vulnerables, los desarrolladores podrían identificar y corregir las vulnerabilidades de sus dependencias con mayor facilidad y rapidez, en lugar de permitir que la vulnerabilidad se abra paso en el proceso de compilación.

Sin embargo, para que esto funcione, la solución debe ser:

1. simple: muy fácil de usar

2. integrada: debe funcionar como parte del flujo de trabajo del desarrollador y con el administrador de paquetes en cuestión

Hace poco empecé a usar el sistema de administración de paquetes Python Poetry. Me gusta mucho cómo está organizado y algunas de las formas en que cumple sus objetivos declarados, así que esperaba encontrar una capacidad de análisis de seguridad que pudiera integrarse con él.

Por eso me alegró saber que Snyk presentó recientemente una nueva función compatible con el administrador de paquetes Poetry y la poetry lock syntax. Para ver más de cerca cómo funciona, inicié sesión en mi cuenta de prueba de Snyk, que acababa de crear, y creé un proyecto nuevo con algunas dependencias vulnerables intencionalmente.

Play Video: DevSecOps with Poetry and Source Composition Analysis

Ingresé el comando para crear un proyecto nuevo llamado Poetry snyk, que configuró un directorio llamado “poetry snyk” y un paquete llamado poetry_snyk : básicamente, código repetitivo junto con un paquete TOML.

Entonces, si voy a poetry_snyk y ejecuto tree, veré un archivo readme con el nombre del paquete raíz poetry_snyk. El archivo TOML es el descriptor de Poetry y también contiene pruebas de código repetitivo; más o menos, una prueba pi que escribió.

Si revisas el proyecto TOML, usamos Python 3.7(una versión un poco antigua de Python, debo admitirlo, pero aun así es la versión local de Python que uso por motivos relacionados con las dependencias). También usamos una dependencia de desarrollo para pruebas llamada pi test; en este caso, la pi test 5.2 version (3.7 es el núcleo pi de Python, que también tiene una compilación que no estoy usando).

Algo que debes saber sobre Poetry es que el archivo TOML reemplaza los archivos requirements.txt y setup.py que antes eran necesarios. Así, con Poetry no solo puedes configurar y hacer seguimiento de las dependencias, sino también compilar cosas y usarlo para publicar en la tienda de quesos de Python. Es bastante interesante que un solo archivo TOML pueda reemplazar los archivos completos setup.py y requirements.txt.

Algo que me gusta de Poetry frente a los administradores de paquetes anteriores es que puedes usarlo como una solución integrada en lugar de una solución improvisada.

Muchos de los administradores de paquetes anteriores con los que trabajé —incluso Pipenv —— me parecían incompletos, ya que se construían sobre la base de código del administrador de paquetes pip, más bien como una envoltura. Creo que Poetry lleva las cosas a otro nivel porque replantea el problema y, en esencia, combina lo mejor de npm, con su descriptor y archivo de bloqueo, y del sistema de administración de paquetes Cargo de Rust. Si revisas Cargo, el administrador de paquetes de Rust, ofrece documentación y pruebas listas para usar. Creo que Poetry ha intentado combinar estas dos cosas y ofrecerte ese enfoque.

Ahora creamos un proyecto nuevo de Poetry llamado poetry_snyk y lo configuramos, pero también necesitamos instalar algunas bibliotecas y ponerlo en marcha. Como lo estoy usando con Snyk, quiero probarlo con bibliotecas inseguras —por lo general, algunas ya conocidas— para ver si Snyk puede detectarlas al analizarlas. Snyk necesita que haya dos archivos disponibles, así que agreguemos algunas dependencias a nuestro proyecto con el siguiente código: 

Este es un docx project python.x que te permite analizar y crear archivos docx. Es vulnerable a una falla de entidades externas XML. Es una falla bastante grave que he mostrado varias veces en mis sesiones de capacitación.

Básicamente, si cargas un documento de Word malicioso con una variable de entidad XML configurada en algo como /etc/passwd, la biblioteca docx resuelve esa entidad, lo que provoca una inclusión de archivos locales e incluso podría encadenarse para crear un exploit de ejecución remota de código. Sin embargo, voy a instalarla, y se resolverán las dependencias y las dependencias anidadas. También se actualizará el archivo TOML y se agregará un archivo poetry.lock. El archivo poetry.lock incluye todas las dependencias anidadas de esa dependencia de nivel superior.

Puedes ver que incluye todas las dependencias anidadas que necesitas, ya que todas las herramientas de análisis, especialmente Snyk y muchas otras herramientas de análisis de código fuente o de paquetes, las necesitan para analizar las dependencias anidadas.

Además de las dependencias anidadas, también incluye la versión de la dependencia anidada que usa, junto con el valor hash correspondiente, para que quede fijada correctamente. Esta era una brecha importante en el ecosistema de Python, porque el administrador de dependencias pip, que es el administrador de dependencias predeterminado de Python, no proporcionaba todos estos detalles: solo las enumeraba, sin fijar sus versiones con precisión. Por eso, no hacía un buen trabajo al administrar las subdependencias.

Supongamos que instalo otro paquete con Poetry. Instalo otro paquete vulnerable de Python, en este caso, pyyaml. Voy a usar la versión 3.13, que es vulnerable a una falla de deserialización insegura. Si se explota esta falla, el atacante puede ejecutar código de forma remota en el entorno de la aplicación objetivo. Voy a instalarlo y verás que también debería actualizar el archivo TOML y el archivo de bloqueo.

Ahora hagamos el seguimiento con Snyk ingresando el siguiente código:

Parece que analizó todas mis dependencias. Este es mi proyecto de Snyk, o mi organización de Snyk, que se generó con todos mis proyectos enumerados; y puedes ver que creé este proyecto.

Como puedes ver, se marcaron problemas y todos son de gravedad alta: la deserialización insegura de pyyaml, la misma ejecución remota de código en pyyaml, un exploit muy conocido y grave, y también las inyecciones de entidades externas XML en python-docx. Snyk pudo detectar todas las vulnerabilidades en las dependencias que uso en este proyecto, gracias a su amplia base de datos y a la sencilla integración.

Cómo empezar

Para empezar a usar esta integración, solo tienes que instalar tu proyecto de Poetry y, desde ese momento, Snyk podrá hacerle seguimiento. Además, te envía notificaciones por correo electrónico sobre estas dependencias, ¡lo cual es genial!

 Pude configurar un proyecto de Poetry muy rápidamente, analizarlo con Snyk para encontrar problemas de seguridad y obtener un informe detallado de las consecuencias.

Ten en cuenta que Snyk necesita que estén disponibles estos dos archivos —el archivo de bloqueo y el archivo TOML— para que la integración funcione.