Seguridad de la cadena de suministro en npm y PyPI: controles concretos después de Shai-Hulud

Por Felipe Traina · 28/9/2026 · 7 min · seguridad, supply-chain, npm, pypi, devsecops

En septiembre de 2025, CISA publicó una alerta sobre un gusano autorreplicante, conocido como "Shai-Hulud", que había comprometido más de 500 paquetes de npm. El malware buscaba credenciales en el entorno donde se instalaba: tokens personales de GitHub y claves de API de AWS, Google Cloud y Azure. Las exfiltraba y después usaba la identidad del desarrollador comprometido para autenticarse en npm, inyectar código en otros paquetes y publicar versiones maliciosas. Así se propagaba solo.

El caso resume el problema de la cadena de suministro de software: el código que corre en tus laptops, en tu CI y en producción incluye cientos de paquetes que nadie del equipo revisó, y basta con que un mantenedor pierda sus credenciales para que una versión maliciosa llegue a miles de proyectos en horas. Esta guía reúne controles concretos para npm y PyPI, todos basados en documentación oficial.

Dos lados del problema: consumir y publicar

Hay dos superficies distintas:

  1. Como consumidor: evitar instalar una versión maliciosa y limitar el daño si ocurre.
  2. Como publicador: evitar que alguien publique en tu nombre si te roban credenciales.

La mayoría de los equipos solo piensa en la primera, pero cualquier empresa que publique un SDK, una CLI o una librería interna en un registro público está en la segunda.

Consumir: instalaciones reproducibles

La base es que lo que se instala en CI y producción sea exactamente lo que se revisó. Eso significa lockfile versionado en el repo e instalación estricta:

# npm: instala exactamente lo que dice package-lock.json y falla si no coincide con package.json
npm ci

# Python con pip: exigir hashes para cada paquete
pip install --require-hashes -r requirements.txt

# Python con uv: fallar si el lockfile quedaría desactualizado
uv sync --locked

CISA recomendó justamente revisar los lockfiles (package-lock.json, yarn.lock) para identificar paquetes afectados, incluidos los transitivos, y fijar versiones conocidas como seguras. Sin lockfile, esa revisión es imposible.

Consumir: no instalar lo que se publicó hace cinco minutos

Una versión maliciosa solo puede retirarse después de que alguien la detecta, y en ese intervalo cualquier instalación la descarga. Esperar unos días antes de adoptar versiones nuevas reduce esa exposición, y hoy las principales herramientas lo soportan de forma nativa:

# .npmrc: solo instalar versiones publicadas hace más de 7 días
min-release-age=7
# excepción para paquetes internos
min-release-age-exclude[]=@miempresa/*

# pyproject.toml con uv: ignorar artefactos subidos en los últimos 7 días
[tool.uv]
exclude-newer = "7 days"

En npm, min-release-age se expresa en días. Existe también before, que acepta una fecha exacta. Un detalle a tener en cuenta: si la ventana bloquea una corrección de seguridad que npm audit fix querría instalar, npm mantiene la versión vulnerable, avisa y termina con error. Para esos casos está min-release-age-exclude. pnpm tiene una opción equivalente, minimumReleaseAge; revisá su documentación para la unidad y las exclusiones.

Consumir: controlar los scripts de instalación

Los scripts preinstall, install y postinstall son uno de los vectores clásicos: se ejecutan con los permisos de quien instala, en su máquina o en el runner de CI. Opciones en npm:

Una combinación razonable para equipos: política allowScripts versionada en el repo y strict-allow-scripts activado en CI.

Consumir: verificar firmas y limitar credenciales

# Verifica las firmas del registro de los paquetes instalados (npm >= 8.15.0)
npm audit signatures

Además, el daño de un paquete malicioso depende de qué encuentre al ejecutarse. Shai-Hulud buscaba tokens de GitHub y claves de nube. Por eso:

Publicar: trusted publishing en lugar de tokens

Si tu organización publica paquetes, el control más importante es dejar de usar tokens de larga duración para publicar. Tanto npm como PyPI soportan trusted publishing con OIDC: el registro confía en una identidad de tu CI (repositorio y workflow concretos) y emite credenciales efímeras en cada ejecución. En PyPI, el token que se obtiene es válido solo por 15 minutos.

En npm, trusted publishing requiere npm CLI 11.5.1 o superior y Node 22.14.0 o superior. Hoy soporta GitHub Actions, GitLab CI/CD y CircleCI, solo con runners en la nube, y hasta 10 trusted publishers por paquete. Con GitHub Actions o GitLab, npm genera automáticamente atestaciones de provenance. Un workflow mínimo en GitHub Actions:

name: publish
on:
  release:
    types: [published]
permissions:
  id-token: write   # necesario para OIDC
  contents: read
jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "24"
          registry-url: "https://registry.npmjs.org"
      - run: npm ci
      - run: npm publish

Después, en la configuración del paquete en npmjs.com, se registra ese repositorio y archivo de workflow como trusted publisher. Una vez que funcione, revocá los tokens de publicación viejos.

Publicar: una aprobación humana antes de salir

npm agregó staged publishing: en lugar de publicar directamente, el paquete queda en una etapa intermedia y un mantenedor debe aprobarlo con 2FA. Requiere npm CLI 11.15.0 o superior, y el paquete tiene que existir previamente en el registro.

npm stage publish          # sube la versión a la etapa (no requiere 2FA)
npm stage list             # lista versiones pendientes
npm stage approve <id>     # la publica, con verificación 2FA

Combinado con trusted publishing, el CI puede preparar la versión, pero publicarla requiere una persona con segundo factor. Es exactamente el tipo de control que corta la propagación automática de un gusano que usa credenciales robadas.

Qué hacer con esto

Para todos los equipos

Si publicás paquetes

¿Cuántos días pasan hoy entre que se publica una versión nueva de una dependencia y que llega a tu entorno de producción?

Lecturas relacionadas

Fuentes

← Volver al blog