Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Cada npm install es un acto de confianza. ¿Alguna vez te has quedado mirando fijamente a tu node_modules carpeta y me pregunté: ¿Qué hay realmente aquí dentro?? En el desarrollo de software moderno, nos encontramos en una situación extraña en la que somos responsables de un iceberg invisible de código que no hemos escrito nosotros. Gran parte de ese código llega en forma de dependencias transitivas, paquetes que nadie del equipo ha elegido directamente. Cuando ese código se implementa en producción, esa responsabilidad se convierte en ansiedad. SecureChain ofrece una capa de protección para gestionar parte de esa presión procedente de terceros.
El «iceberg» de la dependencia transitiva
Antes de instalar un paquete que aparece como dependencia directa, quizá te interese consultar las estrellas de GitHub, el perfil del responsable del mantenimiento y los perfiles de los colaboradores. La biblioteca rara vez viene sola. Un paquete transitivo viene de la mano porque una dependencia directa lo requiere. Piensa en ello como «paquetes de tus paquetes», o incluso «paquetes de paquetes de tus paquetes». Pueden tener varias capas de profundidad y permanecer intactos.
Este iceberg tiene mucha profundidad, y el juego de palabras es totalmente intencionado. Una aplicación web «básica» puede superar fácilmente los 1.000 paquetes almacenados en tu node_modules. Las dependencias transitivas ocultas en lo más profundo son el lugar preferido de los ataques a la cadena de suministro. Amplían de forma espectacular el código de terceros que se hereda, y las auditorías manuales rara vez llegan tan lejos.
El problema no es que las dependencias transitivas sean malas; el desarrollo moderno depende de ellas. El problema es que el código que heredas crece más rápido que el código que revisas.
Cuando lo malicioso parece legítimo
La preocupación surge de esos paquetes que parecen legítimos, pero que en realidad son maliciosos. Como desarrolladores, recurrimos en gran medida a la memoria muscular para realizar nuestro trabajo. Y ahora, con la IA, el proceso de realizar el trabajo ni siquiera requiere eso. Los asistentes de programación a veces sugieren nombres de paquetes que no existen. Eso abre una nueva vía denominada «slopsquatting»: registrar el nombre que un modelo sigue «alucinando» y esperar.
A continuación se incluye una lista de algunos de los más habituales.
Typosquatting
Los ataques de «typosquatting» se basan en que los atacantes registran paquetes con nombres casi indistinguibles de las bibliotecas legítimas y populares, apostando a que alguien escribirá mal, leerá por encima o confiará en una sugerencia. Estos paquetes suelen imitar la funcionalidad del objetivo, por lo que a primera vista no parece que haya ningún problema. Entre las tácticas más comunes se incluyen:
- Sustitución de caracteres: Intercambiar letras, como en
lodashylodahs, un paquete realmente malicioso que atacaba carteras de criptomonedas. Los nuevos nombres de npm deben estar en minúsculas y ser compatibles con las URL, por lo que los nombres similares recurren a trucos que eluden esas reglas, como un1en lugar de unl. - Imitación de espacios de nombres o ámbitos: registro de paquetes con ámbito cuyos nombres se asemejan mucho a los de las bibliotecas oficiales, lo cual difiere del ataque de resolución de registros que se describe a continuación.
- Variaciones de formato: Recurriendo a trucos de separación silábica (p. ej.,
crossenvvs.cross-env) o modificando la forma plural.
Dado que estos paquetes pueden ejecutar código arbitrario durante la instalación, pueden robar claves de API, variables de entorno o credenciales de AWS antes de que nadie revise el código fuente.
Confusión de dependencias
Los ataques de «confusión de dependencias» se dirigen a organizaciones que utilizan una combinación de registros públicos y privados. Un atacante puede aprovechar esta configuración publicando un paquete malicioso con el mismo nombre que uno interno, normalmente asignándole un número de versión superior. Si la configuración de tu compilación no está estrictamente aislada, el sistema podría resolver el nombre del paquete con la versión pública del atacante en lugar de con la interna, lo que provocaría la ejecución automática del código malicioso al instalarlo.
Nada de esto es teórico. Alex Birsan lo demostró en 2021, al publicar paquetes que llevaban el nombre de bibliotecas internas y comprobar cómo se resolvían dentro de los sistemas de Apple, Microsoft y docenas de otras organizaciones.
Para quienes no estén familiarizados con el tema, los paquetes con ámbito (p. ej., @my-org/cool-package) utiliza un @ símbolo a las dependencias del espacio de nombres. La vulnerabilidad de tu organización suele depender de cómo configures tu registro, el ámbito, los proxies y los archivos de bloqueo. Los sistemas que nunca se han sometido a auditorías sobre estos comportamientos de enrutamiento son los que corren mayor riesgo. Para proteger tu pipeline, asegúrate de que la resolución de paquetes sea determinista. Asigna los ámbitos privados a tu registro interno en .npmrc de forma explícita, para que tu gestor de paquetes no resuelva ese ámbito de forma inesperada a través del registro público:
@my-org:registry=https://registry.internal.example.com/Reclamar ámbitos coincidentes en npmjs.com también evita que los atacantes publiquen contenido bajo una identidad que ya te pertenece. Ten en cuenta que la definición de ámbitos es, ante todo, una convención de nomenclatura, no un control de seguridad. Si el mismo nombre de dependencia puede resolverse desde dos lugares diferentes, será otra persona la que tome esa decisión por ti.
Scripts de ciclo de vida
Package.json ganchos del ciclo de vida como, por ejemplo, preinstall, install,y postinstall se ejecutan automáticamente durante la instalación de las dependencias, mucho antes de que nadie del equipo de desarrollo haya echado un vistazo a su contenido.
Estas cargas útiles se dirigen a los objetivos de mayor valor: infraestructura bancaria, servidores de compilación y similares. Extraen información confidencial, entre la que se incluye .env archivos, tokens de AWS y claves SSH: precisamente lo que siempre nos dicen que nunca debemos subir al control de versiones.
Algunos scripts analizan primero el entorno, comprobando si hay entornos aislados o sistemas sometidos a una vigilancia estrecha, y retrasan su ejecución hasta que llegan a un lugar menos protegido.
Shai-Hulud puso de manifiesto la magnitud que esto alcanza. La ola de septiembre de 2025 utilizó postinstall para recopilar tokens de npm y credenciales en la nube de cientos de paquetes, y luego se volvió a publicar con lo que había robado. La oleada de noviembre adelantó la ejecución, llevándola a preinstall, por lo que la carga útil se ejecutó antes de que finalizara la instalación. Las variantes posteriores se ocultaban dentro de dependencias opcionales, ejecutaban la carga útil y, a continuación, provocaban un error que npm tolera.
Dicho esto, el comportamiento predeterminado por fin ha cambiado. pnpm En la versión 10 se dejó de ejecutar automáticamente los scripts del ciclo de vida de las dependencias, por lo que todo lo que se deba compilar debe figurar en onlyBuiltDependencies. npm v12, lanzada el 8 de julio de 2026, adoptó la misma postura: los scripts de dependencias no se ejecutan a menos que el paquete raíz allowScripts la normativa se lo permita, y npm approve-scripts --allow-scripts-pending enumera todo lo que está pendiente de una decisión.
Hay un inconveniente. Un script no aprobado se omite con una advertencia y la instalación sigue devolviendo el código de salida 0, lo que puede dejar una dependencia nativa a medio compilar y provocar un fallo posterior en la compilación o en tiempo de ejecución. Confirma el allowScripts bloquear y configurar strict-allow-scripts=true En CI, los scripts sin revisar provocan que la compilación falle. Si utilizas npm 11 o una versión anterior, el parámetro que se indica a continuación se encarga de ello por ti:
npm install --ignore-scriptsÚtil, sí. Completo, no. Nada de esto aborda la ejecución en el momento de la importación, y un paquete malicioso cuyo código de nivel superior se ejecuta en el momento en que tu aplicación llama a require() se cuela sin problemas entre las medidas de protección del script de instalación.
Se nos impone una enorme presión a la hora de asumir la responsabilidad por el código que lanzamos al mercado. En el Informe sobre el panorama del código abierto de 2026 de TuxCare, entre los encuestados cuyas organizaciones habían notificado un incidente de ciberseguridad, el 61,4 % afirmó que había un parche DISPONIBLE y que nunca se había aplicado. Esa cifra debería ser extremadamente baja. Saber que existe un riesgo no es lo mismo que eliminarlo.
La profundidad de las dependencias complica aún más las cosas. Una corrección que se haya aplicado en el código original no tiene ningún efecto sobre la copia fijada cuatro niveles más abajo en tu árbol.
La revisión manual sigue siendo parte del proceso, pero auditar manualmente un gráfico de ese tamaño no es realista. La falta de visibilidad sobre lo que estás lanzando puede comprometer —y de hecho comprometerá— tu pila tecnológica.
Cómo superar la ansiedad con SecureChain
La gestión del riesgo de dependencia debe formar parte de la política. Llevar a cabo esa gestión a gran escala puede resultar abrumador para cualquier equipo. SecureChain cambia la ruta de consumo. En lugar de obtener los paquetes directamente del registro público, tus compilaciones se descargan de un registro de paquetes gestionado por TuxCare, en el que los paquetes se han recompilado, firmado y parcheado según un calendario publicado.
Cada registro sigue siendo una decisión basada en la confianza. Lo que cambia es que una mayor parte de esa confianza pasa a ser verificable.
Fortalecimiento del código fuente
Cada paquete, incluidas las dependencias transitivas, se vuelve a compilar a partir del código fuente en entornos aislados y reforzados, y se somete a un análisis para detectar malware conocido y código sospechoso, en lugar de redistribuir cualquier artefacto publicado por el desarrollador original.
Actualizaciones continuas
SecureChain proporciona correcciones en el marco del SLA a medida que surgen vulnerabilidades CVE. En el caso de los paquetes cuyo ciclo de vida útil ha finalizado en el origen, el servicio Endless Lifecycle Support (ELS) sigue incorporando correcciones críticas y de alta gravedad a las versiones que ya utilizas.
Configura tu gestor de paquetes para que utilice SecureChain, o el gestor de repositorios que ya utilices, ya que es compatible con Artifactory y Nexus. El resultado es una cadena de procedencia diseñada para garantizar el cumplimiento verificable del nivel 3 de SLSA, documentos VEX que indican qué CVE afectan a una versión de paquete y SBOM legibles por máquina para todos los componentes compatibles, con una cobertura que sigue ampliándose. Nada de esto sustituye a unas buenas prácticas de seguridad. Sigue siendo necesario contar con archivos de bloqueo, reglas de registro con ámbito limitado y credenciales de CI con privilegios mínimos.
Conclusión
Puedes reducir en parte la ansiedad que supone publicar código que no has escrito tú. La seguridad es una tarea y una política continuas. Nunca se trata de una mentalidad ni de una práctica del tipo «configúralo y olvídate». Comprender las dependencias transitivas y reconocer los problemas que se derivan de ellas te ayudará a publicar código de producción en buen estado.
El objetivo no es dejar de confiar en el código abierto. Todos dependemos de él. El objetivo es dejar de tratar esa confianza como si fuera invisible.
El uso de herramientas como SecureChain puede aliviar en parte esa pesada carga que todos soportamos. Ve un paso por delante y protege TU cadena de suministro.
