Cómo detectar ataques a la cadena de suministro en PyPI y npm: análisis de Supply Chain Monitor

Supply Chain Monitor — una herramienta de Elastic de código abierto para la monitorización automática de paquetes populares en PyPI y npm en busca de indicios de compromiso de la cadena de suministro. El sistema supervisa las nuevas versiones en ambos registros, compara cada lanzamiento con la versión anterior, envía las diferencias a un LLM a través de Cursor Agent CLI y, si el modelo considera el lanzamiento malicioso, envía una alerta a Slack. El proyecto se distribuye bajo la licencia MIT y se publicó en GitHub el 27 de marzo de 2026.

Supply Chain Monitor observa los registros públicos y trata de detectar lo antes posible que un lanzamiento sospechoso ha llegado a un paquete popular. El proyecto procesa el flujo de nuevas publicaciones en PyPI y npm. Este enfoque convierte a la herramienta más en un sistema de detección temprana que en una comprobación habitual de dependencias en CI.

Elastic señala además que esta herramienta ayudó a detectar el compromiso del paquete axios 0.30.4. El sistema registró el lanzamiento sospechoso, generó el diff, lo envió para análisis y obtuvo un veredicto, tras lo cual el equipo pudo reaccionar rápidamente. Esta historia es importante para evaluar el proyecto, porque muestra no solo el esquema de laboratorio del README, sino un caso real de uso. El proyecto se distribuye bajo la licencia MIT. Para despliegue interno y adaptación, es un modelo conveniente.

Cómo funciona Supply Chain Monitor

Para PyPI y npm se ejecutan flujos de sondeo separados, que luego convergen en una única canalización de análisis y alertas. En el caso de PyPI, la herramienta toma la lista de paquetes populares del conjunto hugovk/top-pypi-packages, luego llama a changelog_since_serial() vía XML-RPC y selecciona solo eventos «new release» para los paquetes en la lista de vigilancia. En el caso de npm, el proyecto usa el conjunto download-counts para formar el watchlist y lee el registro mediante el flujo _changes de CouchDB, tras lo cual extrae nuevas versiones publicadas desde la última pasada.

Para cada nuevo lanzamiento el monitor descarga la versión antigua y la nueva del paquete, construye un diff unificado en Markdown y lo envía a Cursor Agent CLI en modo ask. El prompt obliga al modelo a evaluar los cambios como «benign» o «malicious» y a explicar brevemente la conclusión. Si el veredicto es malicioso, la herramienta publica una alerta en Slack. Los registros se escriben tanto en la consola como en un archivo de registro diario. El estado del sondeo se guarda en last_serial.yaml para que, después de un reinicio, el trabajo continúe desde el punto correcto.

El README enumera de forma bastante directa los tipos de indicadores que orientan al modelo. Entre ellos, la ofuscación mediante base64, exec, eval o XOR; llamadas de red a hosts inesperados; escritura de archivos en directorios de autoinicio y persistencia; lanzamiento de procesos y comandos de shell; ocultación de datos en archivos multimedia; robo de tokens y credenciales; y señales de typosquatting. Desde un punto de vista práctico, esto significa que el proyecto se centra no en las vulnerabilidades en general, sino en los síntomas de sustitución maliciosa o compromiso de un lanzamiento.

Cómo usarlo en la práctica

En modo de ejecución única se puede analizar los últimos eventos en aproximadamente diez minutos con el comando python monitor.py --once. Para el modo continuo, el proyecto permite definir el tamaño del watchlist y el intervalo de sondeo, por ejemplo vigilar el top-1000 de paquetes con un intervalo de cinco minutos o el top-15000 con alertas en Slack. Scripts separados permiten comparar manualmente dos versiones de un paquete, ejecutar solo el análisis de un archivo diff o ver por separado qué se está publicando ahora en PyPI sin la canalización completa de análisis por LLM.

La utilidad práctica radica en que el proyecto es fácilmente modular. Se puede usar como monitor continuo de registros, como una utilidad para diffs entre dos versiones de un paquete, o como una capa alrededor de Cursor Agent CLI para emitir un veredicto sobre un diff ya preparado. Esa modularidad hace al proyecto más útil que un «monolito para un único escenario».

Supply Chain Monitor es más adecuado para equipos de seguridad que vigilan amenazas a la escala del ecosistema y no solo sus propias dependencias. El proyecto encaja especialmente donde es necesario observar la cúpula de PyPI y npm, recibir rápidamente alertas sobre publicaciones sospechosas y ver de inmediato la explicación de por qué un lanzamiento parece malicioso. Para equipos de threat intelligence y AppSec, este formato puede ser útil como un radar externo sobre las dos mayores ecosistemas de paquetes.

Cómo instalar y ejecutar

Se requiere Python 3.9+ y Cursor Agent CLI instalado.

Instalación de dependencias:

pip install -r requirements.txt

Instalación de Cursor Agent CLI:

curl https://cursor.com/install -fsS | bash

Verificación:

agent --version

A continuación hay que autenticarse en Cursor y configurar Slack en el archivo etc/slack.json.

Ejemplos de ejecución:

# ejecución única
python monitor.py --once

# monitorización continua
python monitor.py --top 1000 --interval 300

# con alertas en Slack
python monitor.py --top 15000 --interval 300 --slack

Fortalezas y limitaciones

Supply Chain Monitor no es una herramienta para la comprobación local de dependencias de un desarrollador, sino un monitoreo externo de paquetes populares en los dos principales registros. Su fortaleza es integrar en una sola cadena la observación de publicaciones, la generación de diffs, el análisis con LLM y las alertas. Tras el caso con axios, el proyecto ya es difícil de considerar solo un experimento. Al mismo tiempo, sigue siendo una herramienta con dependencia evidente del Cursor Agent CLI y con limitaciones de capacidad. Para equipos de AppSec y threat intelligence esto se presenta como un radar útil para PyPI y npm, pero no como una solución autónoma y exhaustiva al problema cadena de suministro de software.