Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- npm audit solo puede comparar tu árbol con los datos de los avisos, por lo que una versión maliciosa publicada hace una hora no se detectará.
- Para subsanar esa carencia se necesita más de una herramienta, ya que los escáneres de comportamiento, las comprobaciones de procedencia y los registros filtrados abarcan cada uno una parte diferente de la misma.
- El control que determina el resultado es aquel que decide, en primer lugar, qué elementos de tu construcción se pueden resolver.
npm audit hace bien una cosa: compara tu árbol de dependencias con una base de datos de vulnerabilidades conocidas y te indica cuáles coinciden. Para todo lo que ya está documentado, resulta útil. En cuanto a lo que aún nadie ha documentado, audit no tiene nada que decir, y si realizas la instalación durante ese periodo, el código queda en tu árbol antes de que haya un aviso con el que compararlo.
Nunca se diseñó para detectar un paquete malicioso antes de que esa amenaza apareciera en los datos de avisos que comprueba. Encontrar una alternativa a npm audit que realmente cubra esa laguna implica analizar qué es lo que determina qué versiones puede resolver tu compilación, y no solo lo que se señala a posteriori.
Qué comprueba realmente «npm audit» y hasta dónde llega
npm audit compara tu árbol de dependencias con los datos de avisos de la Base de datos de avisos de GitHub, que alimenta los datos de auditoría de npm desde 2021. Se trata de una búsqueda de avisos, no de una inspección del contenido de los paquetes ni de su comportamiento en tiempo de ejecución. Si una versión se ha actualizado hace una hora y aún no hay ningún aviso que la cubra, audit no tiene nada con lo que comparar esa versión, por lo que no se marcará como problema.
No se trata de un error. Es la propia naturaleza de la herramienta. La vulnerabilidad de Axios, que duró aproximadamente tres horas en marzo de 2026, muestra cómo se manifiesta esto en la práctica. Dos versiones con puerta trasera, la 1.14.1 y la 0.30.4, se pusieron en circulación y se propagaron a través de las instalaciones mientras que los datos del aviso aún no indicaban nada. Una vez que se publicó el aviso, la auditoría pudo detectar esas versiones dondequiera que hubieran llegado, incluidos los árboles en los que la instalación ya se había producido. Lo que no pudo hacer fue alertar durante el periodo en que realmente importaba.
Hay una segunda comprobación, más específica, que conviene conocer. Al ejecutar «npm audit signatures» se verifican las firmas del registro de los paquetes descargados y, cuando existen, sus certificados de procedencia. Todos estos controles se llevan a cabo en diferentes momentos del proceso, lo cual resulta más fácil de apreciar si se comparan uno al lado del otro.
| Categoría | Lo que atrapa | Cuando actúa |
|---|---|---|
| npm audit | Vulnerabilidades conocidas registradas en los datos de los avisos que comprueba | Una vez que los datos de la recomendación lo incluyan |
| Escáneres de comportamiento y estáticos | Nuevos paquetes sospechosos, scripts y ofuscación | Después de la publicación, antes o después de la instalación |
| Comprobaciones de firmas del Registro | Faltan firmas o estas no son válidas, lo que podría indicar que se ha manipulado el documento | Cuando se verifican las firmas |
| Comprobaciones de procedencia | Si el origen declarado de un paquete y su flujo de trabajo de compilación coinciden con su certificación | Cuando se verifican las certificaciones |
| Registros revisados y reconstruidos | Artículos que no superan la verificación de la procedencia o el análisis de malware | Antes de que la compilación pueda resolverlos |
Herramientas de análisis estático y de comportamiento
Cuando los datos de auditoría coinciden con los de asesoramiento, las herramientas de análisis de comportamiento examinan el propio paquete. Analizan qué ha cambiado entre versiones: una nueva dependencia que ha aparecido sin motivo aparente, un script de instalación que no estaba en la última versión, código ofuscado o llamadas de red que nadie ha solicitado.
Lo que detectan y que la auditoría de npm no puede detectar
Un paquete totalmente nuevo, o una versión publicada hace unos minutos sin ningún aviso previo, es uno de los casos para los que se ha diseñado esta herramienta. No necesita un CVE para señalar un script de postinstalación sospechoso que se conecta a un dominio desconocido, o una diferencia que introduce cientos de kilobytes de código ofuscado en una biblioteca de caché sin que haya motivo para ello. Ese es su valor fundamental: detectar comportamientos en lugar de esperar a que otra persona los catalogue primero.
En qué aspectos aún se quedan cortos
Estas herramientas requieren un ajuste previo para que la señal merezca la pena ser tratada, y los falsos positivos alimentan ese tipo de «fatiga de alertas» que acaba con que alguien silencie el canal. Además, no verifican el origen de un paquete, sino solo lo que parece hacer, por lo que una carga útil que permanezca inactiva durante el periodo de análisis puede seguir pasando.
La mayoría de ellas también comparan los datos con lo que ya se ha publicado en el registro, lo que significa que te avisan de que algo va mal una vez que ya se ha registrado allí. Eso supone una mejora real respecto a tener que esperar a recibir los datos de los avisos, pero no es lo mismo que decidir qué se permite instalar en tu compilación.
Para tener una visión más amplia de las limitaciones de este tipo de herramientas, consulta qué es lo que no ofrecen las herramientas de la cadena de suministro.
Verificación de la procedencia y la firma
Las firmas y la procedencia responden a dos preguntas que la auditoría no resuelve: si el artefacto que has descargado se verifica correctamente y dónde se ha compilado.
Qué es lo que realmente confirma la herramienta «npm audit»
Las certificaciones de procedencia de npm utilizan Sigstore para vincular un artefacto publicado con el repositorio de origen y el flujo de trabajo de compilación que lo generó. Al ejecutar «npm audit signatures» se comprueba que la firma del registro de un paquete sea válida y, cuando exista una certificación, que el paquete incluya una certificación válida que lo vincule con el repositorio de origen y el flujo de trabajo de compilación registrado en él.
Por qué una firma válida no equivale a un veredicto de seguridad
Se trata de comprobaciones reales y útiles. Una firma de registro no válida puede indicar que se trata de un artefacto manipulado, y la procedencia puede revelar que un paquete carece de historial de compilación o que su certificación apunta a una fuente distinta de la que creías que estabas obteniendo.
Lo que tampoco hace es evaluar si el código en sí es seguro. La procedencia indica de dónde procede algo, no qué hace una vez que se está ejecutando. Una cadena de procesamiento que haya sido comprometida de forma imperceptible puede seguir generando una compilación con una certificación totalmente válida, ya que dicha certificación describe con exactitud una compilación real de código genuinamente malicioso. Considera una comprobación de procedencia limpia como un factor más a la hora de tomar una decisión sobre la confianza, no como el objetivo final.
Registros que realizan una comprobación antes de que se resuelva el dominio
Esto nos lleva al aspecto que la mayoría de los equipos dan por sentado que ya tienen cubierto.
Servidor proxy o espejo frente a un registro que inspecciona y reconstruye
Muchos equipos utilizan un registro npm privado como proxy o réplica frente al público, ya sea Verdaccio con un enlace ascendente o un repositorio proxy configurado en Nexus o Artifactory. Esos productos pueden hacer mucho más que almacenar en caché, pero en esa configuración su función es actuar como punto de control para el tráfico de salida y como único lugar donde se determina qué fuentes están permitidas. La inspección no forma parte de ello. Si nada en la ruta verifica el artefacto, un paquete malicioso procedente de una fuente superior seguirá siendo malicioso cuando se sirva desde tu caché.
El otro tipo de registro procesa lo que pasa por él: filtra el artefacto, verifica su origen y, en algunos casos, lo recompila a partir de ese código fuente en lugar de ofrecer lo último que haya publicado el registro público. SecureChain de TuxCare, por ejemplo, recompila los paquetes de npm a partir del código fuente y los filtra antes de que estén disponibles en su registro. Se trata de una garantía sustancialmente diferente, y es el elemento que permite pasar de controlar la procedencia de los paquetes a controlar lo que realmente se instala.
¿Qué cambia cuando se vuelve a compilar un paquete a partir del código fuente?
La reconstrucción a partir del código fuente elimina un modo de fallo que el escaneo por sí solo no puede detectar, concretamente un artefacto publicado que no coincide con lo que realmente hay en el repositorio de origen. Si la versión que resuelve tu compilación se reconstruye a partir del código fuente esperado en un proceso controlado, un archivo tar manipulado que se haya subido directamente al registro público con un token robado no podrá entrar en esa ruta, siempre y cuando el código fuente en sí siga estando limpio. Se trata de una garantía más limitada que la de que «nunca ocurra nada malo», pero es una garantía real, y se mantiene independientemente de que se redacte o no un aviso de seguridad.
Por qué el apilamiento de herramientas sigue dejando un desfase temporal
Si sumas todo eso, habrás cubierto un amplio abanico de aspectos: auditoría de npm para detectar vulnerabilidades conocidas, análisis de comportamiento de los nuevos paquetes y comprobaciones de firmas y procedencia. Lo que nada de esto cambia por sí solo es qué artefactos puede incorporar tu gestor de paquetes en primer lugar.
Los scripts de instalación de dependencias se han ejecutado tradicionalmente en el momento en que se instala un paquete, a menudo antes de que un escáner haya detectado nada y antes de que una persona lo haya revisado. Eso es lo que hizo que el ataque a Axios fuera tan eficaz, ya que las versiones con puerta trasera incorporaban una dependencia totalmente nueva cuyo script de postinstalación ejecutaba el dropper. A partir de la versión 12 de npm, los scripts de instalación de dependencias están bloqueados por defecto, a menos que el proyecto los incluya en su política «allowScripts», lo que cierra parte de esa vía; sin embargo, los scripts de instalación de una dependencia comprometida aún pueden aprobarse por error.
Si aún no te has adentrado en cómo funciona ese modelo de confianza, en esta guía paso a paso sobre cómo instalar paquetes de npm de forma segura se explican los mecanismos de los scripts de ciclo de vida y sus valores predeterminados actuales. El bloqueo de scripts determina si los scripts de instalación de una dependencia se ejecutan después de que npm la haya seleccionado y descargado. No decide si se puede seleccionar una versión maliciosa en absoluto.
Esa es la distinción que conviene tener en cuenta. Estas comprobaciones, por sí solas, no modifican la fuente del paquete desde la que se resuelve tu compilación, y una forma de cambiarlo es trasladar la decisión al registro al que apuntan tus compilaciones.
Solucionar el problema antes de que npm audit lo detecte
SecureChain no es un sustituto de la auditoría. Se trata de un registro diferente desde el que se resuelven tus dependencias de npm. Sustituye el registro público de npm por un repositorio seleccionado y recompilado a partir del código fuente, que filtra los paquetes antes de que estén disponibles para su instalación, de modo que lo que descarga tu compilación ya ha pasado por una verificación del código fuente y un análisis de malware. Para los equipos que buscan algo más que una detección basada únicamente en avisos, esto traslada la decisión a una fase anterior del proceso, donde la falta de avisos tiene mucha menos importancia.
La cobertura abarca desde la adopción hasta el desarrollo, la puesta en marcha y más allá del fin de la vida útil, con los paquetes activos actualizados mediante parches conforme al SLA y el servicio «Endless Lifecycle Support» que toma el relevo una vez que cesa el mantenimiento por parte del desarrollador original. Cada paquete incluye la procedencia SLSA de nivel 3, una SBOM y datos VEX, sin que sea necesario modificar el flujo de trabajo.
Para conocer más a fondo los riesgos que se esconden tras las dependencias transitivas, ve el seminario web bajo demanda o habla con el equipo sobre SecureChain.
PREGUNTAS FRECUENTES
¿Cuál es una buena alternativa a npm audit?
No es algo que se pueda sustituir directamente. «npm audit» sigue siendo una forma razonable de realizar un seguimiento de los avisos conocidos en un árbol desde el que ya estás resolviendo dependencias. Las opciones más eficaces cambian el punto en el que se toma la decisión, filtrando los paquetes antes de que tu compilación pueda descargarlos, algo que la comparación con avisos no puede hacer por su propio diseño.
¿Detecta npm audit los paquetes maliciosos?
Solo comprueba lo que figura en los datos de los avisos. El malware sí que es objeto de avisos, que el equipo de seguridad de npm y el proyecto «malicious-packages» de OpenSSF introducen en la base de datos de avisos de GitHub, aunque GitHub documenta que Dependabot, y no audit, es la vía de alerta para esos casos. En cualquier caso, audit no puede detectar una versión maliciosa recién publicada a partir de su comportamiento, ya que compara los datos con los de los avisos en lugar de inspeccionar el paquete.
¿Sigue mereciendo la pena ejecutar «npm audit» con un registro filtrado?
Principalmente por cuestiones de visibilidad. Un registro filtrado y actualizado continuamente modifica el grado en que el trabajo de corrección depende de la auditoría, pero al ejecutarlo sigues pudiendo saber qué avisos conocidos afectan a lo que ya está en tu árbol.
¿Cuál es la diferencia real entre un registro privado y un registro filtrado?
Un registro privado puede configurarse como poco más que un proxy o un servidor espejo que controla la procedencia de los paquetes. Un registro filtrado inspecciona —y, en algunos casos, recompila— lo que realmente se distribuye, lo que supone una garantía diferente y más sólida.
¿Significa que, si la comprobación de la procedencia da resultados satisfactorios, el paquete se puede instalar sin riesgo?
No. Una procedencia válida vincula un artefacto con la fuente y el flujo de trabajo registrados en su certificación. No demuestra que dicha fuente o dicho flujo de trabajo no hayan sido alterados, por lo que un paquete debidamente certificado puede seguir siendo malicioso.
