Buenas prácticas de seguridad para npm: cómo proteger tus paquetes tras el ataque Shai Hulud de 2025

Ataques como Shai-Hulud, Nx, event-stream, colors, node-ipc y otros demuestran que los administradores de paquetes funcionan como motores de ejecución, no solo como descargadores de bibliotecas. Debemos gestionar las dependencias de terceros con vigilancia y asegurarnos de que existan los controles de seguridad adecuados.

A continuación encontrarás una lista práctica y seleccionada de medidas para reforzar la seguridad del administrador de paquetes npm, con prácticas recomendadas para el desarrollo local seguro y los procesos de quienes mantienen software de código abierto. Tenla abierta junto a tu terminal.

Estos son los aspectos clave de las prácticas, herramientas y áreas de seguridad para las que describimos pautas de uso responsable, tanto para desarrolladores como para mantenedores de código abierto:

• Opciones de CLI seguras por defecto para npm, pnpm, Bun, Yarn y Deno

• Refuerzo de la cadena de suministro e instalaciones deterministas

• Higiene de archivos de bloqueo y dependencias

• Comprobaciones de vulnerabilidades y estado de los paquetes

• Gestión de secretos y aislamiento del entorno de desarrollo

• Prácticas para mantenedores: 2FA, procedencia, OIDC y reducción de dependencias

Acerca de Shai-Hulud y el malware de la cadena de suministro

La familia de ataques Shai-Hulud marca un punto de inflexión para los desarrolladores de JavaScript: npm install es ahora claramente un mecanismo de ejecución remota de código, no una comodidad inofensiva. En septiembre de 2025, la campaña original Shai-Hulud utilizó versiones manipuladas de paquetes como ngx-bootstrap, ng2-file-upload y @ctrl/tinycolor para distribuir una carga maliciosa similar a un gusano mediante scripts del ciclo de vida de npm. Los hooks maliciosos de postinstall descargaban un archivo bundle.js ofuscado que se ejecutaba en las máquinas de los desarrolladores y los agentes de CI, recopilaba credenciales de npm, GitHub y la nube, y las exfiltraba mediante webhooks y flujos de trabajo de GitHub. Al final, se vieron implicados cientos de paquetes.

El 24 de noviembre de 2025, SHA1-Hulud surgió como una segunda ola de la misma estrategia y demostró la rapidez con que evolucionan los atacantes. Esta variante se propaga mediante paquetes npm troyanizados que ocultan cargas maliciosas en scripts preinstall. Una vez instalado el paquete, el gusano intenta convertir a la víctima en un ejecutor autohospedado de GitHub Actions controlado por el atacante, inyecta flujos de trabajo maliciosos en los repositorios y los usa para ejecutar comandos arbitrarios y robar secretos de npm y GitHub. Busca activamente credenciales de AWS, Azure y GCP y, en algunos casos, incluso intenta escapar de contenedores, escalar privilegios en el host y ejecutar acciones destructivas de tipo «wiper» contra el directorio personal del usuario. Al momento de escribir esto, se identificaron más de 600 paquetes como parte de esta campaña, incluidos paquetes populares de proveedores como Zapier, PostHog y Postman; la cifra sigue aumentando.

En conjunto, Shai-Hulud y SHA1-Hulud definen un manual claro para el malware moderno de la cadena de suministro. Abusan de los hooks del ciclo de vida de npm como superficie de ejecución; convierten las estaciones de trabajo de los desarrolladores y la infraestructura de CI/CD en puntos de salto; y tienen como objetivo real las credenciales, los tokens y los secretos de la nube. Los detalles de cada incidente siguen evolucionando, pero el patrón es lo bastante estable como para extraer un conjunto de prácticas duraderas que deberían convertirse en hábitos para todo desarrollador de JavaScript.

Esta guía práctica convierte esas lecciones en un conjunto concreto de prácticas que puedes aplicar hoy: configurar valores predeterminados seguros para los administradores de paquetes, reforzar las defensas contra ataques a la cadena de suministro, exigir una resolución de dependencias segura y determinista, integrar comprobaciones continuas de vulnerabilidades y estado de los paquetes, y aplicar cada uno de estos controles a npm, pnpm, Bun y el resto de tu cadena de herramientas. El objetivo no es reaccionar específicamente a Shai-Hulud, sino hacer que tu uso diario de npm sea resiliente frente a la clase de ataques que representa.

Índice rápido

1. Desactivar scripts post-install

2. Instalar con un período de espera

3. Reforzar las instalaciones con npq

4. Evitar la inyección en archivos de bloqueo

5. Usar instalaciones deterministas (npm ci, etc.)

6. Evitar actualizaciones a ciegas

7. No guardar secretos en texto plano en .env

8. Desarrollar en contenedores

9. Activar 2FA en npm

10. Publicar con procedencia

11. Publicar con OIDC (publicación confiable)

12. Reducir el árbol de dependencias

1. Desactivar scripts post-install

El objetivo es impedir que se ejecute código arbitrario durante install.

Riesgo

Los scripts post-install (y otros scripts del ciclo de vida) son uno de los principales vectores de ataque a la cadena de suministro (Shai-Hulud, Nx, event-stream). Cualquier dependencia, directa o transitiva, puede ejecutar código arbitrario durante la instalación.

Refuerzo básico de npm

Global: desactivar todos los scripts del ciclo de vida (recomendado):

# Safe-by-default on your machine
npm config set ignore-scripts true

Por instalación:

# One-off installs without running lifecycle scripts
npm install --ignore-scripts <package-name>

pnpm

A partir de la versión 10, pnpm desactiva los scripts postinstall de forma predeterminada y admite un mecanismo de lista de permitidos o de reactivación. Recomendamos revisar la documentación de seguridad de la cadena de suministro de pnpm para consultar esquemas de configuración adicionales.

Bun

Bun desactiva los scripts postinstall de forma predeterminada y mantiene una lista de permitidos interna. Puedes marcar explícitamente ciertas dependencias como confiables mediante trustedDependencies en package.json:

{
  "trustedDependencies": [
    "some-package",
    "another-package"
  ]
}

Ejecutar solo los scripts que realmente necesitas

Usa una lista de permitidos en lugar de confiar ciegamente en package.json:

1# Use LavaMoat's allow-scripts to define where scripts may run
2npm install --save-dev @lavamoat/allow-scripts
3npx allow-scripts

Con el paquete npm allow-scripts de LavaMoat, puedes habilitar selectivamente scripts en posiciones específicas de tu gráfico de dependencias para paquetes npm confiables que requieren legítimamente los scripts preinstall o postinstall, como bcrypt, playwright y otros.

2. Instalar con un período de espera

El objetivo es evitar versiones «recién publicadas y maliciosas» y trampas de typosquatting.

Riesgo

Los atacantes aprovechan SemVer y la resolución de «latest» para publicar versiones nuevas que se detectan y se retiran rápidamente. Si instalas de inmediato, quedas en la zona de impacto.

npm: instalaciones basadas en fecha

Limita la instalación a las versiones publicadas antes de una fecha:

# Install only if published before 2025-01-01
npm install express --before=2025-01-01

Período de espera dinámico de 7 días (ejemplo con date de estilo BSD):

npm install express --before="$(date -v -7d)"

Nota: este método es manual y frágil para la automatización, pero sirve como medida de seguridad explícita.

2.1 minimumReleaseAge de pnpm

En pnpm-workspace.yaml:

minimumReleaseAge: 20160  # minutes; here: 2 weeks

pnpm rechazará las versiones publicadas hace menos tiempo que el período especificado, para dar al ecosistema tiempo de detectar versiones maliciosas o defectuosas.

2.2 Período de espera de Snyk en las solicitudes de cambios automáticas

Los pull requests automáticos de actualización de dependencias de Snyk omiten las versiones publicadas hace menos de unos 21 días, lo que reduce:

• Las actualizaciones a versiones defectuosas que se retiran rápidamente

• Las actualizaciones a paquetes publicados desde cuentas comprometidas

Este es un patrón de «período de espera integrado en la automatización».

3. Reforzar las instalaciones con npq

El objetivo es evitar instalar un paquete hasta que supere comprobaciones básicas de seguridad y sentido común.

Problema

Ejecutas:

npm install some-package

y no sabes si:

• El paquete es una imitación con un error tipográfico de uno popular

• Se publicó ayer y no tiene usuarios

• Tiene vulnerabilidades conocidas

• Incluye scripts pre/post-install maliciosos

Estrategia: anteponer npq a tus instalaciones

npq es un auditor de seguridad previo a la instalación (usa «marshalls» para realizar comprobaciones).

Instalar:

npm install -g npq

Usar en lugar de npm:

npq install express

Establecer como opción predeterminada:

alias npm='npq-hero'

# Persist the alias
echo "alias npm='npq-hero'" >> ~/.zshrc  # or ~/.bashrc
source ~/.zshrc

Al usar el paquete npq, se instalan npq y npq-hero; este último funciona como un reemplazo directo de npm.

Qué comprueba npq («marshalls»)

• Vulnerabilidades mediante la base de datos de CVE de Snyk

• Detección de paquetes nuevos (menos de 22 días de antigüedad)

• Antigüedad de la versión (publicada hace menos de 7 días)

• Paquetes similares por typosquatting

• Verificación de firmas del registro npm

• Atestación de procedencia de compilación

• Presencia de scripts pre/post-install

• Estado del paquete: README, LICENSE, URL del repositorio y descargas

• Introducción de binarios (nuevas herramientas de CLI)

• Señales de obsolescencia

• Validez del dominio del mantenedor y dominios vencidos

Integración con pnpm y Bun

# One-off
NPQ_PKG_MGR=pnpm npq install fastify
NPQ_PKG_MGR=bun   npq install fastify

# Make pnpm go through npq
alias pnpm="NPQ_PKG_MGR=pnpm npq-hero"

4. Evitar la inyección en archivos de bloqueo de npm

El objetivo es asegurarse de que package-lock.json / yarn.lock no te redirijan silenciosamente a fuentes maliciosas.

Riesgo

Un colaborador (o un atacante mediante una solicitud de cambios) puede:

• Agregar un paquete malicioso al archivo de bloqueo.

• Cambiar la URL resolved para que apunte a un host bajo su control (repositorio Git, tarball o gist).

• Ajustar el hash de integridad para que parezca «válido».

Así, la próxima ejecución de install descargará malware aunque package.json parezca inofensivo.

Mitigación: lockfile-lint

Instalar:

npm install --save-dev lockfile-lint

Validar el archivo de bloqueo con hosts permitidos y HTTPS:

npx lockfile-lint \
  --path package-lock.json \
  --type npm \
  --allowed-hosts npm yarn \
  --validate-https

Opciones clave de validación

• Validación del host: solo npm, yarn, verdaccio, etc.

• Exigir HTTPS: rechazar esquemas de URL inseguros

• Validación del esquema: permitir solo https:, git+https: y git+ssh:

• Validación del nombre del paquete: la URL resuelta coincide con el nombre del paquete

• Validación de integridad: exigir hashes de integridad SHA-512 seguros

Integración con CI/CD

Agrega un paso de validación del archivo de bloqueo antes de la instalación:

{
  "scripts": {
    "lint:lockfile": "lockfile-lint --path package-lock.json --type npm --allowed-hosts npm --validate-https",
    "preinstall": "npm run lint:lockfile"
  }
}

pnpm e inyección en archivos de bloqueo

El archivo pnpm-lock.yaml de pnpm es más resistente porque:

• No depende de URL arbitrarias de tarballs de la misma manera

• No instalará un paquete que esté en el archivo de bloqueo, pero no en package.json

• El formato evita varios vectores de inyección presentes en npm/yarn

Aun así, trata los archivos de bloqueo como artefactos críticos para la seguridad.

5. Usar instalaciones deterministas (npm ci)

El objetivo es garantizar que las compilaciones y los entornos de producción usen exactamente las versiones del archivo de bloqueo.

Riesgo

npm install intenta «corregir» las discrepancias entre package.json y el archivo de bloqueo, lo que puede:

• Incorporar versiones distintas de las registradas

• Romper el determinismo en CI/producción

• Introducir versiones inesperadas, vulnerables o maliciosas

npm: usar ci en lugar de install

Entorno local y CI:

# Deterministic install based on package-lock.json
npm ci

Dependencias solo de producción en CI/CD:

npm ci --only=production

Asegúrate de que los archivos de bloqueo estén confirmados en el repositorio y actualizados.

Comandos deterministas en los distintos administradores de paquetes

Yarn:

yarn install --immutable --immutable-cache

pnpm:

pnpm install --frozen-lockfile

Bun:

bun install --frozen-lockfile

Deno:

deno install --frozen

Los archivos de bloqueo forman parte del contrato de tu cadena de suministro, no son artefactos de compilación que debas ignorar.

6. Evitar las actualizaciones a ciegas de paquetes npm

El objetivo es actualizar con revisión y señales, no «llevar todo a la última versión».

Riesgo

Evita las actualizaciones a ciegas de dependencias de terceros, como esta:

npm update
npx npm-check-updates -u

Al ejecutar estos comandos, ya sea en CI o en entornos de desarrollo local, corres los siguientes riesgos:

• Incorporar versiones maliciosas publicadas desde cuentas de mantenedores comprometidas

• Incorporar errores que provocan cambios incompatibles y versiones retiradas

• Activar ataques de confusión de dependencias o secuestro de espacios de nombres

Mejores prácticas

1. Actualizaciones interactivas:

npx npm-check-updates --interactive

2. Revisa cada dependencia antes de actualizarla.

3. Bots con enfoque en seguridad:

• Solicitudes automáticas de actualización de Snyk

• Solicitudes de cambios de GitHub Dependabot

4. Estas herramientas crean solicitudes de cambios revisables con contexto (registros de cambios, CVE) en lugar de modificar el archivo de bloqueo en silencio.

7. No guardes secretos en texto plano en archivos .env

El objetivo es evitar que los secretos se exfiltren fácilmente desde tu entorno de desarrollo.

Riesgo

Los archivos .env y las variables de entorno en texto plano:

• Son blancos fáciles para paquetes maliciosos o malware de desarrollo.

• A menudo terminan en registros, volcados de fallos, historial de la terminal, etc.

• Se leen mediante process.env o la lectura directa de archivos en ataques a la cadena de suministro.

Este es un ejemplo de lo que no debes hacer:

DATABASE_PASSWORD=my-secret-password
API_KEY=sk-1234567890abcdef

Patrón: referencias a secretos e inyección justo a tiempo

Paso 1: coloca referencias (no valores) en .env:

DATABASE_PASSWORD=op://vault/database/password
API_KEY=infisical://project/env/api-key

Paso 2: usa la CLI del administrador de secretos durante la ejecución. Por ejemplo, con la CLI de 1Password:

# Run app with secrets injected into process.env
op run -- npm start

# More explicit example with env-file
op run --env-file="./.env" -- node --env-file="./.env" server.js

Otras opciones: CLI de Infisical, administradores de secretos en la nube, etc. La idea clave: la variable de entorno contiene una referencia, no el secreto.

8. Trabajar en contenedores de desarrollo

El objetivo es aislar tu entorno de desarrollo para que el malware de npm no pueda tomar el control de tu host.

Riesgo

Ejecutar npm install en tu host significa que:

• Los paquetes maliciosos pueden leer archivos de tus otros repositorios

• Pueden buscar claves SSH, perfiles del navegador, tokens de IA/agentes, etc.

• Comparten el espacio de nombres del sistema operativo con todo lo demás que haces

Patrón de contenedor de desarrollo

Usa VS Code Dev Containers (o una herramienta similar) para aislar el entorno, por ejemplo, con el siguiente archivo de configuración DevContainer .devcontainer/devcontainer.json:

{
  "name": "Node.js Dev Container",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:18",
  "features": {
    "ghcr.io/devcontainers/features/1password:1": {}
  },
  "postCreateCommand": "npm ci"
}

Después:

1. Abre la carpeta en VS Code

2. «Reopen in Container»

3. Todas las instalaciones y ejecuciones se realizan dentro del contenedor.

Reforzar el contenedor de desarrollo

Agrega opciones de seguridad de Docker y flags seguros de Node:

"runArgs": [
  "--security-opt=no-new-privileges:true",
  "--cap-drop=ALL",
  "--cap-add=CHOWN",
  "--cap-add=SETUID",
  "--cap-add=SETGID"
],
"containerEnv": {
  "NODE_OPTIONS": "--disable-proto=delete"
}

Para tener aún más control, usa un Dockerfile personalizado con imágenes base mínimas, un usuario no root y un entorno de ejecución reforzado.

9. Activar 2FA para las cuentas de npm

El objetivo es evitar que el secuestro de una cuenta permita publicar versiones maliciosas desde cuentas comprometidas.

Riesgo

Incidentes como el de eslint-scope demostraron que, una vez que un atacante obtiene credenciales, puede publicar versiones con puertas traseras para millones de usuarios. La autenticación solo con contraseña no es suficiente.

Comandos

2FA para iniciar sesión, publicar y cambiar el perfil:

npm profile enable-2fa auth-and-writes

2FA solo para iniciar sesión y cambiar el perfil (menos estricto):

npm profile enable-2fa auth-only

Aplica auth‑and‑writes a todas las cuentas que puedan publicar o agregar mantenedores.

Configura la publicación confiable con OIDC

Además de configurar tu cuenta de npm con controles de contraseña adecuados, como 2FA y Passkey, también debes usar el método Trusted OIDC Publishing como única forma de publicar nuevos paquetes de npm, atribuyéndolos directamente a tu repositorio de GitHub y a flujos de trabajo específicos. Consulta más adelante la sección dedicada a este tema.

10. Publica con atestaciones de procedencia

El objetivo es permitir que los consumidores verifiquen dónde y cómo se creó tu paquete.

Problema

Sin información de procedencia, a los consumidores les resulta difícil saber:

• ¿Este archivo tar se compiló a partir del código fuente A de GitHub o en una máquina maliciosa?

• ¿Una canalización de CI comprometida inyectó código?

Solución: npm publish --provenance

En GitHub Actions:

permissions:
  id-token: write

steps:
  - run: npm publish --provenance

Requisitos:

• npm CLI 9.5.0+

• GitHub Actions (o GitLab CI/CD) con ejecutores alojados en la nube y compatibilidad con OIDC

Esto genera metadatos de compilación verificables criptográficamente y alineados con los estándares emergentes de la cadena de suministro (por ejemplo, OpenSSF).

11. Publica con OIDC (publicación confiable)

El objetivo es eliminar los tokens de npm de larga duración de CI/CD.

Riesgo

Los tokens de larga duración:

• Pueden registrarse o confirmarse por accidente

• Siguen siendo válidos después de filtrarse

• Otorgan acceso amplio y de larga duración a tu organización y tus paquetes

Patrón de publicación confiable

1. Configura el paquete como publicador confiable en npmjs.com (GitHub o GitLab).

2. Usa OIDC en tu flujo de trabajo:

Ejemplo de GitHub Actions:

permissions:
  id-token: write

steps:
  - run: npm publish

No se almacena NPM_TOKEN en ningún lugar. npm verifica el token OIDC de tu CI y solo permite publicar desde los flujos de trabajo aprobados. Las atestaciones de procedencia se generan automáticamente.

12. Reduce el árbol de dependencias de tus paquetes

El objetivo es tener un grafo de dependencias más pequeño, lo que a su vez reduce la superficie de ataque que puede ponerte en riesgo.

Riesgo

Cada dependencia:

• Incluye sus propias dependencias transitivas

• Hereda mantenedores, cuentas y sus posibles vulneraciones

• Amplía tu superficie de vulnerabilidades y licencias

Estrategia

Prefiere diseños con cero o pocas dependencias. Usa JavaScript moderno en lugar de agregar una biblioteca de utilidades para tareas simples.

Ejemplos:

// Instead of lodash uniq
const unique = [...new Set(array)];

// Instead of axios for simple HTTP GET
const response = await fetch(url);

// Instead of utility libs for trivial checks
const isEmpty = obj => Object.keys(obj).length === 0;

Antes de agregar una dependencia, pregúntate (o pregúntale a tu equipo):

• ¿Esta funcionalidad no es trivial?

• ¿Justifica el costo de seguridad y mantenimiento?

• ¿Existe ahora una API estándar para esto?

Perspectivas sobre la seguridad para desarrolladores y el malware en la cadena de suministro

Esta guía comparte algunas prácticas recomendadas de seguridad para npm que publicamos por primera vez en 2019, y las refuerza y amplía para incorporar prácticas modernas y lecciones aprendidas de los ataques a la cadena de suministro que presenciamos en 2025.

Primero, los desarrolladores deben tratar el administrador de paquetes como un motor de ejecución no confiable y configurarlo con opciones seguras de forma predeterminada. Esto significa desactivar los scripts del ciclo de vida siempre que sea posible, recurrir a listas de permitidos explícitas cuando realmente se necesiten scripts y contar con mecanismos como periodos de espera y auditorías previas a la instalación para que «instalar un paquete nuevo» sea una decisión deliberada y no un acto reflejo. Estos controles deben extenderse más allá de npm e incluir pnpm, Bun y otros administradores de paquetes modernos, para que la configuración predeterminada sea uniforme en todas las herramientas del espacio de trabajo.

Segundo, la resolución de dependencias debe ser determinista y defendible. Las campañas Shai-Hulud aprovecharon que un cambio de versión inadvertido o una modificación del archivo de bloqueo podía introducir un archivo tar malicioso en miles de proyectos. Como respuesta, los equipos deben basar sus flujos de trabajo en archivos de bloqueo estrictos e inmutables, exigir este comportamiento en CI y proteger esos archivos con herramientas que validen el origen de los paquetes. Las instalaciones deterministas no solo permiten reproducir el entorno: también ayudan a responder «¿qué código ejecutamos y de dónde vino?» cuando ocurre un incidente.

Tercero, las vulnerabilidades y las señales sobre el estado de las dependencias deben tratarse como un flujo continuo de datos, no como un informe ocasional. Estos incidentes avanzan más rápido que la publicación tradicional de CVE, por lo que tus defensas deben combinar bases de datos de vulnerabilidades, avisos sobre malware, atestaciones de procedencia, señales de antigüedad y popularidad de los paquetes, y políticas automatizadas de actualización con periodos de espera integrados. Entre las piezas esenciales están los controles de seguridad durante la instalación, las solicitudes de cambios automatizadas que evitan versiones muy recientes y las herramientas que distinguen entre una corrección menor y una versión de paquete no confiable que nunca se había visto.

Por último, la seguridad eficaz de npm no se limita a instalar dependencias. También depende de cómo estructuras tu entorno de desarrollo local, administras los secretos y publicas y mantienes tus propios paquetes. Trabajar en contenedores de desarrollo reforzados limita el alcance del daño cuando se detecta un paquete malicioso. Te recomiendo no usar secretos en texto sin cifrar en tus variables de entorno; dejar atrás los archivos .env en texto sin cifrar y pasar a la inyección de secretos justo a tiempo reduce lo que un atacante puede robar, incluso si logra ejecutar código. Habilitar 2FA, la publicación confiable con OIDC y las atestaciones de procedencia para tus propios paquetes de npm dificulta que alguien suplante tu identidad en el ecosistema.

Mantente protegido con Snyk

Snyk sigue de cerca la situación de Shai-Hulud y publica actualizaciones periódicamente en la plataforma. Hasta ayer (24 de noviembre), ya habíamos rastreado más de 800 paquetes maliciosos.

A continuación, presentamos varios recursos que te ayudarán a tener más control sobre el incidente actual y a prepararte para la próxima vez.

Lista de paquetes comprometidos de Shai-Hulud

Snyk mantiene una lista pública en línea de paquetes maliciosos de Shai-Hulud asociados con la campaña de malware:

Informes Zero-Day de Snyk

Al conectar tus repositorios a Snyk o supervisarlos de cualquier otra forma, creas un inventario que te permite hacer seguimiento fácilmente de distintos aspectos de tus dependencias, como auditar a toda tu organización de I+D para determinar si el malware Shai-Hulud la afectó.

Para saber si este incidente te afectó, ve a Reports > Featured Zero-Day Report. Para obtener más información sobre esta función, lee nuestra User Docs.

Las siguientes capturas de pantalla muestran cómo encontrarlo en la interfaz de Snyk (se muestra el ataque anterior a la cadena de suministro de npm Shai-Hulud de septiembre de 2025). El nuevo informe se llama SHA1-Hulud npm Supply Chain Attack - Nov 2025:

Supervisa tus dependencias con Snyk

Depender de bibliotecas de software de código abierto requiere supervisar continuamente todo el árbol de dependencias, directas e indirectas, en toda tu organización, y mantenerlo al día con las actualizaciones de seguridad, ya sean vulnerabilidades CVE o campañas de malware.

Con Snyk, puedes conectar tus repositorios de Git y tomar medidas proactivas para controlar los riesgos del código abierto en proyectos de JavaScript con Snyk Open Source como herramienta de SCA. También puedes y debes mantener un SBOM, que Snyk ofrece listo para usar.

También te recomendamos prepararte desde hoy para las vulnerabilidades Zero-Day del futuro.