La suplantación tipográfica en los registros de paquetes es la práctica de publicar paquetes maliciosos con nombres que son variaciones tipográficas de paquetes legítimos y populares, aprovechando la tendencia de los desarrolladores a escribir mal los nombres de los paquetes, aceptar una sugerencia incorrecta del autocompletado o copiar y pegar desde documentación que contiene un error. El paquete suplantado suele estar diseñado para parecer legítimo en su página del registro, con la misma descripción, el mismo archivo léame e incluso la misma interfaz de código que el paquete genuino, mientras ejecuta en silencio funciones maliciosas: exfiltrar variables de entorno, instalar puertas traseras o establecer un acceso persistente al entorno del desarrollador.
El mecanismo de exposición transitiva es el riesgo concreto que hace especialmente peligrosa la suplantación tipográfica. Un desarrollador que revisa con cuidado los paquetes que instala directamente puede estar ejecutando paquetes suplantados sin saberlo, porque un paquete legítimo que instaló dependía de un paquete suplantado, que a su vez estaba incluido en el árbol de dependencias de un paquete de confianza. Las dependencias transitivas, las dependencias de sus dependencias, no se revisan con el mismo escrutinio que las dependencias directas. Un paquete suplantado que se introduce en el árbol de dependencias de un paquete popular llega a todos los consumidores de ese paquete sin que ninguno de ellos lo haya elegido directamente.
El problema de la ausencia de CVE agrava el riesgo. Las herramientas de análisis de seguridad que detectan vulnerabilidades conocidas por su identificador CVE no señalarán un paquete suplantado: los paquetes suplantados no son vulnerabilidades conocidas en el sentido tradicional. Son código malicioso sin ningún CVE asignado, sin ninguna entrada en NVD y sin firma en las bases de datos de vulnerabilidades tradicionales. El análisis de SCA que ofrece una cobertura integral de las vulnerabilidades conocidas en paquetes legítimos no ofrece ninguna cobertura frente a paquetes maliciosos que se hacen pasar por legítimos.
Por qué es importante
La suplantación tipográfica es importante para TPRM porque los productos de software de sus proveedores se construyen sobre árboles de dependencias que pueden incluir paquetes suplantados sin que el proveedor lo sepa, porque el paquete suplantado era una dependencia transitiva, porque no tenía ningún CVE y porque sus análisis de SCA, por definición, no detectan paquetes maliciosos. El SBOM que enumera todos los componentes no distingue los paquetes legítimos de los suplantados: un «lodash-utils» suplantado aparece en el SBOM junto a los paquetes legítimos.
- Los paquetes suplantados no tienen CVE: los análisis de vulnerabilidades de SCA no los detectan
- Dependencias transitivas no revisadas con el mismo escrutinio que las directas
- El SBOM incluye paquetes suplantados: el inventario no distingue los maliciosos de los legítimos
- Evaluación de la legitimidad de los paquetes ausente de la revisión de dependencias
- Monitoreo del registro en busca de variaciones de nombres de paquetes no implementado
Cómo se ve una buena práctica
Los programas maduros de defensa contra la suplantación tipográfica implementan comprobaciones de legitimidad de los paquetes junto con el análisis de vulnerabilidades (verificando la antigüedad del paquete, su historial de descargas, la reputación de quien lo mantiene y revisando el código de las dependencias recién agregadas) y monitorean la aparición de nuevos paquetes con nombres similares a los de las dependencias internas y externas de uso común.
- Comprobaciones de legitimidad de los paquetes: antigüedad, número de descargas y reputación de quien los mantiene para los paquetes nuevos
- Proceso de revisión de nuevas dependencias: revisión humana de los paquetes recién agregados
- Monitoreo del registro en busca de variantes suplantadas de los paquetes de uso común
- Fijación de dependencias: especificación de versiones exactas que impide la sustitución inesperada de paquetes
- Verificación de paquetes en tiempo de compilación: verificación de hash de todos los paquetes resueltos
Herramientas
Seguridad de los paquetes: Socket.dev para la detección de paquetes maliciosos en tiempo real; Snyk para la puntuación del riesgo de la cadena de suministro
Socket.dev ofrece una inspección profunda de paquetes que va más allá del análisis de CVE: analiza el código de los paquetes en busca de comportamiento malicioso, detecta patrones de suplantación tipográfica y evalúa señales de legitimidad del paquete, como la reputación de quien lo mantiene y la evolución del código. Para los profesionales de TPRM, preguntar si los proveedores usan Socket o herramientas equivalentes que detecten paquetes maliciosos más allá del análisis de CVE constituye una pregunta concreta sobre la defensa contra la suplantación tipográfica.
Desafíos de gobernanza
El desafío de gobernanza de la suplantación tipográfica es la escala del ecosistema de dependencias. Un proyecto de software moderno puede tener cientos de dependencias directas y miles de dependencias transitivas: revisarlas todas manualmente no es viable. La solución de gobernanza son herramientas automatizadas que puntúan los paquetes según señales de legitimidad y señalan las anomalías para su revisión humana, combinadas con la fijación de dependencias, que impide cambios inesperados de paquetes entre compilaciones.
- Implemente socket.dev o un equivalente para detectar paquetes maliciosos más allá de CVE
- Implemente la fijación de dependencias: uso obligatorio de archivos de bloqueo que impide la deriva de versiones
- Revise las nuevas dependencias directas antes de agregarlas a producción
- Monitoree las variantes suplantadas de los paquetes de uso común
- Incluya la detección de paquetes maliciosos en la evaluación de la seguridad de la compilación del proveedor
Si usted forma parte de un equipo pequeño
Habilite Socket.dev o la acción de revisión de dependencias de GitHub en sus repositorios de producción. Estas herramientas analizan señales de legitimidad de los paquetes (cambios en el código, comportamiento de quienes los mantienen, scripts de instalación) y señalan los paquetes con características sospechosas. Ejecútelas sobre su árbol de dependencias actual y revise los paquetes señalados. Los paquetes que Socket señala como sospechosos son los que un análisis basado en CVE nunca sacaría a la luz.
- Habilite Socket.dev o la revisión de dependencias de GitHub en los repositorios de producción
- Revise los paquetes señalados por el análisis de legitimidad
- Imponga el uso de archivos de bloqueo: fijación de dependencias
- Agregue comprobaciones de legitimidad a la evaluación de la seguridad de la compilación del proveedor
Qué exigir
Pregunte directamente:
"Más allá del análisis de CVE, ¿cómo detectan los paquetes maliciosos que no tienen un CVE asignado, en concreto los paquetes suplantados u otros paquetes maliciosos en su árbol de dependencias? ¿Y usan herramientas que analicen señales de legitimidad de los paquetes más allá de las bases de datos de vulnerabilidades?"
Evidencia que debe esperar
- Detección de paquetes maliciosos más allá del análisis de CVE
- Proceso de evaluación de la legitimidad de los paquetes
- Fijación de dependencias y aplicación obligatoria de archivos de bloqueo
- Enfoque de revisión de las dependencias transitivas
A un proveedor que confirma el análisis de vulnerabilidades mediante SCA se le debe preguntar por la detección de paquetes maliciosos. El SCA analiza vulnerabilidades conocidas. Los paquetes suplantados no son vulnerabilidades conocidas: son código malicioso sin CVE. Herramientas distintas, modelo de amenazas distinto.
Cómo demostrarlo
- Implementación de herramientas de legitimidad de paquetes
- Implementación de la fijación de dependencias
- Registros del proceso de revisión de paquetes nuevos
- Capacidad de detección de paquetes maliciosos
Conclusión clave
lodash: legítimo, 47 millones de descargas semanales. lodash-utils: suplantado, 43,000 descargas, siete meses en npm, 312 implementaciones en producción en empresas que nunca lo instalaron directamente. Ningún CVE. Ninguna alerta de SCA. Solo código que se ejecutó. Los paquetes suplantados no son entradas de bases de datos de vulnerabilidades: son código malicioso que parece un paquete legítimo. El análisis de CVE detecta vulnerabilidades conocidas en paquetes legítimos. No ofrece ninguna cobertura frente a paquetes maliciosos. Las herramientas de análisis de legitimidad (Socket.dev, el análisis del comportamiento de los paquetes) aportan la cobertura complementaria para el modelo de amenazas que el análisis de CVE no aborda.