Nombres engañosos y paquetes nuevos sospechosos

El primero vive del error humano: se publica un paquete con un nombre que se confunde con otro muy usado (una letra de menos, dos letras cambiadas de orden, un guion donde no iba) y se espera a que alguien lo escriba mal. Se le suele llamar suplantación por errata, y el paquete falso a menudo exporta las mismas funciones que el bueno para que nada falle y nadie mire.

El segundo vive de la configuración: un equipo usa un paquete interno con un nombre sin ámbito y su gestor consulta también el registro público. Si alguien publica en el registro público un paquete con ese mismo nombre y una versión más alta, y el rango declarado la admite, el gestor puede preferir la pública. Se le llama confusión de dependencias. Se evita poniendo los paquetes internos bajo un ámbito propio (en npm, un prefijo como @empresa/) asociado al registro interno, y reservando ese ámbito en el público.

Abre el laboratorio y lee encargo.txt y solicitud-de-cambio-231.txt. Compara cada nombre nuevo con los que el portal ya usa y con metadatos-registro.txt. Las señales de un paquete sospechoso se leen juntas: creado hace días, pocas versiones publicadas en poco tiempo, una cuenta de publicador recién creada, sin repositorio enlazado y muy pocas descargas frente al paquete al que se parece.

Lee npmrc.txt y la entrada del paquete interno en bloqueo-extracto.txt. El campo resolved dice de dónde se descargó cada paquete; la configuración dice qué nombres van al registro interno. Un paquete sin el prefijo de ámbito no lo cubre esa regla, y el rango que escribió el desarrollador no tiene techo.

Muchos paquetes maliciosos no esperan a que la aplicación los use: actúan al instalarse, a través de los scripts que el gestor ejecuta en ese momento, y eso ocurre en el portátil de quien desarrolla y en la integración continua, donde suele haber credenciales. El archivo de bloqueo de npm marca las entradas que traen scripts de instalación, lo que permite verlo en la revisión del cambio sin abrir el paquete. Lee otra vez las entradas nuevas del bloqueo y el resumen de revision-aislada.txt.

Rechazar este cambio resuelve el día. Lo que evita el siguiente es un control que no dependa de que alguien lea con atención cada nombre. Mira cómo está configurado el registro interno y qué nombres cubre.