Mejores Prácticas de Seguridad en npm
El ecosistema de npm es el registro de paquetes más grande del mundo, y esa escala lo convierte en un objetivo de alto valor. Ataques como Shai-Hulud, event-stream y eslint-scope han demostrado la misma verdad incómoda: instalar un paquete puede ejecutar código arbitrario en tu máquina antes de que hayas leído una sola línea de su código fuente. Estas mejores prácticas de seguridad en npm te ayudan a reducir ese riesgo en cada etapa: instalación, desarrollo y publicación.
Puntos Clave
- Deshabilita los scripts post-install globalmente y permite únicamente los paquetes que realmente los necesiten.
- Establece un período de espera para nuevas versiones para que las versiones recién publicadas (y potencialmente maliciosas) nunca lleguen automáticamente a tus builds.
- Siempre commitea tu lockfile y usa
npm cien pipelines de CI para instalaciones reproducibles y resistentes a manipulaciones. - Protege las cuentas de maintainers con 2FA basado en WebAuthn y publica mediante trusted publishing OIDC para eliminar tokens de larga duración.
Por Qué la Seguridad de la Cadena de Suministro en npm Importa Ahora
Los ataques a la cadena de suministro no explotan tu código. Explotan tu confianza en el código de otros. Cuando un paquete comprometido llega a tu node_modules, puede robar credenciales, exfiltrar variables de entorno o propagarse aún más. El gusano Shai-Hulud por sí solo provocó la eliminación de más de 500 paquetes del registro en un solo incidente. El escaneo de vulnerabilidades por sí solo no detectará esta clase de ataque—necesitas defensa en profundidad.
Gestión Segura de Dependencias: Fortalece tus Instalaciones
Deshabilita los Scripts Post-Install
Los scripts post-install son el vector de ataque más común en ataques a la cadena de suministro de npm. Deshabítalos globalmente:
npm config set ignore-scripts true
npm config set allow-git none # npm CLI 11.10.0+
La configuración allow-git=none es importante porque una dependencia basada en git puede incluir su propio .npmrc que silenciosamente vuelve a habilitar los scripts de ciclo de vida, evitando ignore-scripts por completo.
Si usas pnpm, la versión 10+ deshabilita los scripts post-install por defecto. Usa pnpm-workspace.yaml para permitir explícitamente los paquetes que legítimamente los necesitan:
allowBuilds:
esbuild: true
core-js: false
Habilita strictDepBuilds: true para convertir cualquier script de build no revisado en un fallo que bloquee el CI en lugar de una advertencia silenciosa. Bun también bloquea los scripts post-install por defecto, con opt-in mediante trustedDependencies en package.json.
Cuando realmente necesites scripts de ciclo de vida, usa @lavamoat/allow-scripts para crear una lista de permitidos auditable en lugar de habilitar scripts globalmente.
Añade un Período de Espera para Nuevas Versiones
Los paquetes maliciosos a menudo se descubren y despublican en cuestión de horas o días. Omitir las versiones más recientes le da tiempo a la comunidad para detectar problemas antes de que te lleguen:
npm config set min-release-age 3
Esto le indica a npm que ignore cualquier versión de paquete publicada hace menos de tres días. Para actualizaciones automáticas de dependencias, herramientas como Renovate y Dependabot soportan configuraciones equivalentes de minimumReleaseAge.
Commitea tu Lockfile y Usa npm ci
Siempre commitea package-lock.json. En entornos de CI, reemplaza npm install con:
npm ci
npm ci instala exclusivamente desde el lockfile, falla si hay alguna discrepancia, y nunca resuelve silenciosamente una versión diferente. Esta es la base de builds reproducibles y seguros en pipelines automatizados.
No Actualices a Ciegas
npm audit y npm outdated son señales útiles, pero trátalas como una entrada, no como una solución completa. Antes de actualizar cualquier dependencia, revisa el changelog. Evita actualizaciones masivas que omitan este paso—cada actualización de versión es un cambio potencial en la superficie de ataque.
Discover how at OpenReplay.com.
Flujos de Trabajo Seguros en npm para Maintainers de Paquetes
Habilita 2FA—y Actualiza a WebAuthn
Los secuestros de cuentas son el mecanismo principal detrás de los ataques a la cadena de suministro en el registro. Habilita 2FA en tu cuenta de npm con protección en modo escritura:
npm profile enable-2fa auth-and-writes
GitHub cada vez más fomenta passkeys y autenticación basada en WebAuthn, que son significativamente más resistentes al phishing que el 2FA tradicional basado en TOTP. Una llave de hardware o passkey es significativamente más difícil de phishear que un código TOTP, así que cambiar cuanto antes vale la pena.
Publica con Trusted Publishing (OIDC)
Los tokens de npm de larga duración son un riesgo. Trusted publishing mediante OIDC permite que GitHub Actions o GitLab CI se autentiquen directamente con npm usando credenciales de corta duración y con alcance de flujo de trabajo—sin necesidad de token almacenado. También genera automáticamente attestations de provenance, dando a los consumidores prueba criptográfica de dónde y cómo se construyó un paquete.
Esta es la dirección hacia la que se dirige el ecosistema. GitHub ha señalado planes para eliminar gradualmente los tokens legacy y hacer del trusted publishing la ruta predeterminada para la automatización.
Verifica lo que Instalas
No asumas que el registro oficial es seguro. Usa Socket o npq para examinar paquetes en busca de comportamiento sospechoso antes de la instalación. Verifica el número de descargas, la actividad del repositorio y el historial del maintainer—especialmente para paquetes sugeridos por asistentes de codificación con IA, que pueden alucinar nombres de paquetes que los atacantes luego registran (una técnica llamada slopsquatting).
Conclusión
Ninguna herramienta individual previene todos los ataques a la cadena de suministro de npm. Las prácticas que más importan son por capas: deshabilita los scripts de ciclo de vida, aplica lockfiles, añade un período de espera para nuevas versiones, usa npm ci en CI, y migra la publicación a OIDC con 2FA. Cada capa reduce el riesgo de forma independiente. Juntas, hacen que tu flujo de trabajo sea significativamente más difícil de comprometer.
Preguntas Frecuentes
Sí, algunos paquetes como esbuild o sharp requieren scripts post-install para descargar binarios específicos de la plataforma. En lugar de volver a habilitar scripts globalmente, usa un enfoque de lista de permitidos con la configuración allowBuilds de pnpm o allow-scripts de LavaMoat para otorgar permiso solo a paquetes específicos y confiables que genuinamente necesitan pasos de build.
No. npm audit verifica vulnerabilidades conocidas en avisos publicados, pero no puede detectar ataques novedosos a la cadena de suministro como typosquatting, secuestros de cuentas o código malicioso inyectado en paquetes que de otro modo serían legítimos. Trata audit como una señal útil dentro de una estrategia de defensa en capas más amplia que incluya aplicación de lockfile, restricciones de scripts y herramientas de escaneo pre-instalación.
npm install lee package.json, resuelve rangos de dependencias y puede modificar el lockfile. npm ci lee únicamente desde package-lock.json, instala versiones exactas y falla inmediatamente si el lockfile falta o es inconsistente con package.json. Siempre usa npm ci en pipelines de integración continua para garantizar builds reproducibles y resistentes a manipulaciones.
Los tokens de npm tradicionales son secretos de larga duración almacenados en entornos de CI, haciéndolos objetivos atractivos para robo. OIDC trusted publishing genera credenciales de corta duración con alcance de flujo de trabajo vinculadas a un repositorio y ejecución de acción específicos. No se almacena ningún secreto en ninguna parte, y cada operación de publicación está vinculada criptográficamente a su fuente, produciendo attestations de provenance verificables automáticamente.
Understand every bug
Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.