Blog

Cómo Proteger Dependencias NPM: Guía Completa de Seguridad en la Cadena de Suministro para Desarrolladores de APIs

Ashley Innocent

Ashley Innocent

1 April 2026

Cómo Proteger Dependencias NPM: Guía Completa de Seguridad en la Cadena de Suministro para Desarrolladores de APIs

Apidog para empresas

Despliegue local

SSO & RBAC

Conforme con SOC 2

Explorar Apidog Enterprise

TL;DR

Los ataques a la cadena de suministro de NPM se dispararon a más de 3,000 paquetes maliciosos solo en 2024, y el compromiso de Axios en marzo de 2026 demostró que incluso los 10 principales paquetes no están seguros. Esta guía cubre cada capa de defensa que los desarrolladores de API necesitan: aplicación de lockfiles, bloqueo de scripts postinstall, verificación de procedencia, herramientas de análisis de comportamiento y opciones arquitectónicas que reducen su superficie de ataque.

Introducción

El ataque a la cadena de suministro de Axios el 31 de marzo de 2026, no fue el primer compromiso de npm. No será el último. Pero con 83 millones de descargas semanales y un RAT multiplataforma desplegado a través de una única cuenta de mantenedor secuestrada, fue la llamada de atención más ruidosa que ha recibido el ecosistema de JavaScript.

Esto es lo que lo diferencia del consejo habitual de "actualizar tus dependencias": el ataque de Axios eludió todas las defensas tradicionales. El código malicioso no estaba en Axios en sí. Fue inyectado a través de una dependencia fantasma que activó un hook `postinstall`. Los lockfiles no ayudaron si ejecutaste npm install durante la ventana de ataque. La fijación de versiones no ayudó si aún no la habías fijado.

Los desarrolladores de API están especialmente expuestos. Tus scripts de prueba, pipelines de CI/CD, servidores de prueba (mock servers) y clientes HTTP, todos extraen de npm. Un único paquete comprometido en tu cadena de herramientas puede filtrar claves de API, credenciales de bases de datos y tokens de la nube desde tu máquina de desarrollo.

💡
Apidog elimina un vector de ataque importante al proporcionar un cliente HTTP integrado para pruebas de API, por lo que no necesitas Axios, node-fetch o got en tu pila de pruebas. Descarga Apidog gratis para reducir tu superficie de dependencia de npm mientras sigues las estrategias de defensa a continuación.
button

Esta guía cubre siete capas de protección, desde la higiene básica del lockfile hasta el análisis de comportamiento avanzado.

Capa 1: aplicación de lockfiles

Por qué los lockfiles son importantes

Un lockfile registra la versión exacta de cada paquete y dependencia transitiva en el momento de la instalación. Sin un lockfile, npm install resuelve la última versión que coincide con tu rango semver. Si tu package.json dice "axios": "^1.14.0" y existe una versión maliciosa 1.14.1 en el registro, obtendrás la versión maliciosa.

Las reglas

Siempre haz commit de tu lockfile. Ya sea package-lock.json (npm), yarn.lock (Yarn), pnpm-lock.yaml (pnpm) o bun.lock (Bun), debe estar en el control de versiones.

Usa instalaciones congeladas en CI/CD. Nunca ejecutes npm install en entornos automatizados. Usa el equivalente de lockfile congelado:

# npm
npm ci

# yarn
yarn install --frozen-lockfile

# pnpm
pnpm install --frozen-lockfile

# bun
bun install --frozen-lockfile

npm ci elimina node_modules e instala estrictamente desde el lockfile. Si el lockfile no coincide con package.json, falla. Esto evita sorpresas en la resolución.

Revisa las diferencias del lockfile en las solicitudes de extracción. Cuando una PR modifica package-lock.json, verifica qué cambió. Las nuevas dependencias, las actualizaciones de versión y los cambios en las URL de registro merecen un escrutinio. Herramientas automatizadas como Socket.dev pueden señalar cambios sospechosos en el lockfile durante las revisiones de PR.

La brecha del lockfile

Los lockfiles protegen contra la resolución inesperada de versiones, pero no protegen contra la primera instalación. Si inicializas un proyecto o agregas una nueva dependencia durante una ventana de ataque, la versión maliciosa queda bloqueada. Por eso los lockfiles son la Capa 1, no la única capa.

Capa 2: deshabilitar scripts postinstall

El principal vector de ataque

El ataque a Axios, el ataque a ua-parser-js, el ataque a event-stream y docenas de otros, todos utilizaron el mismo mecanismo: un script postinstall que ejecuta código arbitrario durante npm install. Este hook se ejecuta antes de que se ejecute el código de tu aplicación, antes de que revises el paquete y antes de que cualquier herramienta de seguridad en tiempo de ejecución pueda intervenir.

Bloquear scripts globalmente

Agrega a tu .npmrc:

ignore-scripts=true

O configúralo a través de la CLI:

npm config set ignore-scripts true

Esto evita que todos los scripts de ciclo de vida (preinstall, install, postinstall, prepare) se ejecuten durante la instalación del paquete.

Manejar paquetes que necesitan scripts

Algunos paquetes requieren scripts postinstall para la compilación nativa (como bcrypt, sharp o sqlite3). Tienes dos opciones:

Opción 1: Ejecutar scripts selectivamente después de la instalación

npm ci --ignore-scripts
npm rebuild bcrypt sharp

Opción 2: Usar una lista blanca (npm 10+)

Crea un .scriptsrc.json que solo permita a los paquetes de confianza ejecutar scripts:

{
  "allowScripts": {
    "bcrypt": true,
    "sharp": true
  }
}

Opción 3: Usar binarios precompilados

Muchos paquetes que antes necesitaban compilación nativa ahora ofrecen binarios precompilados. sharp, por ejemplo, distribuye binarios precompilados para la mayoría de las plataformas, eliminando la necesidad de compilación postinstall. Revisa tus dependencias; es posible que necesites menos excepciones de scripts de lo que piensas.

La advertencia de PackageGate

En enero de 2026, los investigadores revelaron seis vulnerabilidades de día cero llamadas "PackageGate" que afectaban a npm, pnpm, vlt y Bun. Un hallazgo: las dependencias basadas en Git pueden llevar archivos de configuración que permiten la ejecución de código incluso cuando los scripts de ciclo de vida están deshabilitados. Si tu package.json hace referencia a URLs de Git para las dependencias, ignore-scripts por sí solo no es suficiente. Fija esas dependencias a hashes de commit específicos y audita el contenido del repositorio.

Capa 3: fijar versiones exactas

Deja de usar rangos semver

El comportamiento predeterminado de npm install --save agrega paquetes con un prefijo de intercalación (caret):

{
  "axios": "^1.14.0"
}

El ^ significa "compatible con 1.14.0", lo que se resuelve a la última versión 1.x.x. Durante el ataque de Axios, eso significó resolverse a 1.14.1.

Fija versiones exactas en su lugar:

{
  "axios": "1.14.0"
}

Configura npm para guardar versiones exactas por defecto:

# .npmrc
save-exact=true
save-prefix=''

Usar anulaciones para dependencias transitivas

Tus dependencias directas tienen sus propias dependencias. Si una dependencia transitiva está comprometida, fijar tu dependencia directa no ayuda. Usa anulaciones para controlar la resolución transitiva:

{
  "overrides": {
    "axios": "1.14.0",
    "plain-crypto-js": "npm:empty-npm-package@1.0.0"
  }
}

Para Yarn:

{
  "resolutions": {
    "axios": "1.14.0"
  }
}

Para pnpm:

{
  "pnpm": {
    "overrides": {
      "axios": "1.14.0"
    }
  }
}

La contrapartida

La fijación exacta significa que no obtendrás actualizaciones de parches automáticas. Tendrás que actualizar las versiones manualmente, lo que genera una sobrecarga de mantenimiento. La contrapartida es deliberada: estás eligiendo actualizaciones controladas en lugar de automáticas. Para proyectos sensibles a la seguridad, esta contrapartida vale la pena.

Capa 4: verificar la procedencia del paquete

Qué significa la procedencia

La atestación de procedencia de npm vincula un paquete publicado a su código fuente y entorno de compilación utilizando firmas de Sigstore registradas en un libro mayor de transparencia pública. Cuando un paquete se publica desde una pipeline de CI/CD con la procedencia habilitada, el paquete incluye prueba criptográfica de:

Cómo verificar la procedencia

npm audit signatures

Esto verifica que los paquetes instalados tienen atestaciones de procedencia válidas. Los paquetes publicados manualmente desde la máquina de un desarrollador no tendrán procedencia.

Las versiones maliciosas de Axios carecían de vinculación de procedencia OIDC y no tenían commits de GitHub correspondientes. Si la verificación automatizada de procedencia hubiera sido una práctica estándar, el ataque habría levantado sospechas de inmediato.

Habilitar la procedencia para tus propios paquetes

Si publicas paquetes npm, habilita la procedencia en tu CI/CD:

# Ejemplo de GitHub Actions
- uses: actions/setup-node@v4
  with:
    node-version: 20
    registry-url: https://registry.npmjs.org
- run: npm publish --provenance
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Agrega a tu .npmrc:

provenance=true

Limitaciones

La procedencia es opcional. La mayoría de los paquetes npm aún no la tienen. Y la procedencia solo prueba dónde se construyó un paquete. No prueba que el código fuente sea seguro. Una pipeline de CI/CD comprometida podría publicar un paquete malicioso con procedencia válida.

Capa 5: usar herramientas de análisis de comportamiento

Más allá del escaneo de vulnerabilidades

Las herramientas tradicionales como npm audit y Snyk verifican contra bases de datos de vulnerabilidades conocidas (CVEs). Detectan problemas reportados, pero pasan por alto los ataques de día cero. El compromiso de Axios no estaba en ninguna base de datos de CVE cuando se publicó.

Las herramientas de análisis de comportamiento examinan lo que hacen los paquetes, no lo que se ha informado sobre ellos.

Socket.dev

Socket analiza el comportamiento del paquete durante la instalación y el tiempo de ejecución. Marca:

Escaneo de seguridad de Socket.dev

Cuando se integra con GitHub, Socket comenta en las PR cuando las nuevas dependencias exhiben comportamientos sospechosos. La dependencia plain-crypto-js del ataque de Axios habría activado múltiples alertas de Socket: código ofuscado, solicitudes de red durante el postinstall y escrituras en el sistema de archivos fuera del directorio del paquete.

# Instalar Socket CLI
npm install -g @socketsecurity/cli

# Escanear tu proyecto
socket scan

Snyk

Snyk proporciona gestión de vulnerabilidades con puntuaciones de riesgo, datos de madurez de exploits y orientación para la corrección. Es más fuerte para vulnerabilidades conocidas, pero más débil para la detección de comportamiento de día cero.

# Instalar Snyk CLI
npm install -g snyk

# Probar tu proyecto
snyk test
Escaneo de seguridad de Snyk

Enfoque en capas

Usa ambos. Socket detecta anomalías de comportamiento que Snyk pasa por alto. Snyk detecta vulnerabilidades conocidas con un contexto más rico del que proporciona Socket. Agrega npm audit como línea base:

# Línea base
npm audit

# Análisis de comportamiento
socket scan

# Gestión de vulnerabilidades
snyk test

Ejecuta los tres en CI/CD como compuertas. Cualquier hallazgo crítico debe bloquear la compilación.

Capa 6: minimizar tu superficie de dependencia

La pregunta más profunda

Cada paquete en tu node_modules es una decisión de confianza. El ataque de Axios comprometió un paquete con 83 millones de descargas semanales. El proyecto promedio de Node.js tiene cientos de dependencias transitivas. Cada una es un vector de ataque potencial.

La defensa más efectiva es tener menos dependencias que defender.

Audita tu árbol de dependencias

# Contar tus dependencias totales
npm ls --all | wc -l

# Buscar duplicados
npm ls --all | sort | uniq -c | sort -rn | head -20

Haz estas preguntas para cada dependencia:

Alternativas nativas para paquetes comunes

Paquete Alternativa nativa Disponible desde
axios, node-fetch, got fetch (global) Node.js 18
uuid crypto.randomUUID() Node.js 19
dotenv --env-file flag Node.js 20.6
chalk util.styleText() Node.js 21.7
glob fs.glob() Node.js 22
path-to-regexp Native URL pattern API Node.js 23

Específicamente para pruebas de API

Los flujos de trabajo de pruebas de API comúnmente dependen de bibliotecas de clientes HTTP, bibliotecas de aserciones, ejecutores de pruebas y servidores de prueba (mock servers). Cada dependencia es una superficie de ataque.

Apidog elimina las dependencias de las pruebas de API

Apidog reemplaza toda la pila con una única plataforma:

Mover tu flujo de trabajo de pruebas de API a Apidog elimina docenas de dependencias npm de tu infraestructura de pruebas. Menos dependencias significa menos decisiones de confianza y menos vectores de ataque.

Prueba Apidog gratis para consolidar tu pila de pruebas de API.

button

Capa 7: monitoreo de red y tiempo de ejecución

Bloquear dominios maliciosos conocidos

Después de cualquier ataque a la cadena de suministro, bloquea la infraestructura de comando y control a nivel de red:

# Agregar a /etc/hosts
echo "0.0.0.0 sfrclak.com" | sudo tee -a /etc/hosts

Para entornos de CI/CD, restringe el acceso saliente a la red a dominios conocidos y seguros. La mayoría de los procesos de compilación solo necesitan acceso al registro de npm, a tu host de git y a tus objetivos de despliegue. Todo lo demás debe ser bloqueado por defecto.

Usar StepSecurity Harden-Runner para CI/CD

Harden-Runner de StepSecurity monitorea los flujos de trabajo de GitHub Actions en tiempo real. Detectó que el dropper de Axios contactaba a C2 dentro de 1.1 segundos desde el inicio de npm install. La herramienta proporciona:

# GitHub Actions
- uses: step-security/harden-runner@v2
  with:
    egress-policy: audit  # o 'block' para modo estricto

Monitoreo de procesos en tiempo de ejecución

Para máquinas de desarrollo, considera herramientas de detección y respuesta de endpoints (EDR) que señalen procesos hijo sospechosos generados por Node.js. El RAT de Axios generó osascript (macOS), cscript (Windows) y python3 (Linux) desde dentro del proceso de instalación de npm. Estos patrones de procesos hijo son detectables.

Configuración `.npmrc` recomendada

Aquí tienes un archivo .npmrc endurecido de seguridad que combina las capas anteriores:

# Fijar versiones exactas
save-exact=true
save-prefix=

# Deshabilitar scripts de ciclo de vida
ignore-scripts=true

# Habilitar la procedencia para la publicación
provenance=true

# Usar el registro oficial
registry=https://registry.npmjs.org/

# Requerir 2FA para la publicación
auth-type=web

# Umbral de nivel de auditoría
audit-level=moderate

Haz commit de este archivo en tu repositorio para que cada miembro del equipo use las mismas configuraciones de seguridad.

Ejemplo de pipeline de seguridad CI/CD

Aquí tienes un flujo de trabajo de GitHub Actions que aplica las siete capas:

name: Secure Build
on: [push, pull_request]

jobs:
  security-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: step-security/harden-runner@v2
        with:
          egress-policy: audit  # o 'block' para modo estricto

      - uses: actions/setup-node@v4
        with:
          node-version: 22

      # Capa 1+2: Lockfile congelado, sin scripts
      - run: npm ci --ignore-scripts

      # Capa 3: Verificar que no haya versiones inesperadas
      - run: npm ls --all > deps.txt

      # Capa 4: Verificar la procedencia
      - run: npm audit signatures

      # Capa 5: Análisis de comportamiento
      - run: npx socket scan

      # Capa 5: Escaneo de vulnerabilidades
      - run: npx snyk test

      # Capa 1: Auditoría de línea base
      - run: npm audit --audit-level=moderate

      # Reconstruir solo dependencias nativas permitidas
      - run: npm rebuild sharp bcrypt

Qué viene a continuación para la seguridad de npm

Procedencia obligatoria para paquetes populares

npm está discutiendo la posibilidad de exigir la atestación de procedencia para paquetes que superen un cierto umbral de descargas. Esto evitaría la publicación manual basada en tokens que permitió el ataque de Axios.

Aprobación de lanzamiento por dos personas

Al igual que las transacciones financieras que requieren doble autorización, los paquetes de alta descarga pueden requerir que un segundo mantenedor apruebe los lanzamientos. Una sola cuenta comprometida no sería suficiente.

Alcance de permisos en tiempo de ejecución

Deno ya restringe lo que los scripts pueden acceder (red, sistema de archivos, variables de entorno) a menos que se conceda explícitamente. Node.js está explorando modelos de permisos similares. Cuando esto se implemente, los scripts postinstall necesitarían permiso explícito para realizar solicitudes de red o acceder al sistema de archivos.

Convergencia de gestores de paquetes

El modelo de aislamiento estricto de pnpm (los paquetes solo pueden acceder a sus dependencias declaradas) previene muchos ataques de confusión de dependencias. A medida que npm adopte una rigurosidad similar, la superficie de ataque se reducirá.

Preguntas Frecuentes

¿Qué es un ataque a la cadena de suministro en npm?

Un ataque a la cadena de suministro en npm se dirige a la cadena de dependencia del software en lugar de directamente a tu aplicación. Los atacantes comprometen cuentas de mantenedores de paquetes, inyectan código malicioso en paquetes populares o publican paquetes de 'typosquatting' con nombres similares. Cuando instalas o actualizas dependencias, el código malicioso se ejecuta en tu máquina o en tu pipeline de CI/CD, robando credenciales, instalando puertas traseras o exfiltrando datos.

¿Es suficiente npm audit para proteger contra ataques a la cadena de suministro?

No. npm audit verifica contra una base de datos de vulnerabilidades conocidas (CVEs). Los ataques de día cero como el compromiso de Axios no están en ninguna base de datos de CVE cuando ocurren. Necesitas herramientas de análisis de comportamiento como Socket.dev que examinen lo que hacen los paquetes, no lo que se ha informado sobre ellos. Usa npm audit como línea base, no como tu única defensa.

¿Debería dejar de usar npm por completo?

No. npm sigue siendo el ecosistema de paquetes más grande, y la mayoría de los paquetes son seguros. El objetivo es reducir tu exposición a través de la fijación de versiones exactas, la aplicación de lockfiles, el bloqueo de scripts y la minimización de dependencias. Considera si cada dependencia es necesaria y usa alternativas nativas siempre que sea posible.

¿Cómo ayuda Apidog a reducir el riesgo de la cadena de suministro de npm?

Apidog proporciona un cliente HTTP integrado, ejecutor de pruebas, servidor de prueba (mock server) y generador de documentación para el desarrollo de API. Esto elimina la necesidad de paquetes npm como Axios, node-fetch, Jest, Express (para mocks) y otras dependencias de prueba. Menos dependencias npm significa menos vectores de ataque en tu flujo de trabajo de desarrollo de API.

¿Qué es la procedencia de paquetes en npm?

La procedencia de paquetes utiliza Sigstore para vincular criptográficamente un paquete publicado a su repositorio de código fuente y entorno de compilación de CI/CD. Prueba dónde y cómo se construyó un paquete. Puedes verificar la procedencia con npm audit signatures. Los paquetes publicados manualmente desde máquinas de desarrolladores carecen de procedencia, lo cual es una señal de alerta para paquetes de alta descarga.

¿Cuántos paquetes npm son maliciosos?

Snyk identificó más de 3,000 paquetes npm maliciosos en 2024. Para el cuarto trimestre de 2025, Sonatype bloqueó 120,612 ataques de malware en un solo trimestre en npm, PyPI y otros registros. El número está creciendo. La mayoría de los paquetes maliciosos son 'typosquatting' de baja descarga, pero compromisos de alto perfil como Axios demuestran que los paquetes populares no son inmunes.

¿Qué es la vulnerabilidad PackageGate?

PackageGate es un conjunto de seis vulnerabilidades de día cero reveladas en enero de 2026 que afectan a npm, pnpm, vlt y Bun. Un hallazgo muestra que las dependencias basadas en Git pueden contener archivos de configuración que permiten la ejecución de código incluso cuando los scripts de ciclo de vida están deshabilitados. Esto significa que ignore-scripts por sí solo no es suficiente si tus dependencias hacen referencia a repositorios de Git. Fija las dependencias de Git a hashes de commit específicos.

Conclusiones clave

Cada dependencia es una decisión de confianza. Cuantas menos dependencias tengas, menor será tu superficie de ataque. Cuantas más capas de verificación apliques, más difícil será para un atacante pasar desapercibido. Construye tus defensas en profundidad, no de forma aislada.

button

Practica el diseño de API en Apidog

Descubre una forma más fácil de construir y usar APIs

Registrarse gratisDescargar