La confusión de dependencias es un ataque a la cadena de suministro que explota el comportamiento de resolución de paquetes de las herramientas de compilación y los gestores de paquetes. Cuando un entorno de desarrollo está configurado para resolver paquetes tanto de registros públicos (npm, PyPI, Maven Central) como de registros privados o internos, muchos gestores de paquetes preferirán, por defecto o por un error de configuración, un paquete público con un número de versión más alto a un paquete privado con el mismo nombre y una versión más baja. Un atacante que identifica el nombre de un paquete interno (mediante ofertas de empleo, repositorios de GitHub, mensajes de error o documentación) puede publicar en el registro público un paquete malicioso con ese nombre y un número de versión más alto. El sistema de compilación resuelve la versión pública, ejecuta el código del atacante y el compromiso ocurre durante una instalación rutinaria de dependencias, no a través de una vulnerabilidad del propio software.
El mecanismo de descubrimiento es la primera fase del ataque. Los atacantes identifican los nombres de paquetes internos a través de múltiples canales: ofertas de empleo que mencionan los marcos de herramientas internas, repositorios públicos de GitHub donde los nombres de paquetes internos aparecen en archivos de configuración, mensajes de error que incluyen nombres de paquetes cuando no se encuentran los paquetes internos, documentación que menciona herramientas internas y contribuciones de código abierto de empleados que revelan las convenciones de nomenclatura de los paquetes internos. El nombre del paquete no es un secreto: existe en los archivos de compilación, en los documentos de configuración y en la memoria institucional del equipo de desarrollo. Tratarlo como confidencial no es una defensa viable.
El mecanismo de prioridad de resolución es la vulnerabilidad técnica. Los gestores de paquetes como npm, pip y Maven están diseñados para resolver la versión más alta de un paquete que coincida con el rango de versiones especificado. Cuando se configuran registros públicos y privados a la vez, muchas implementaciones consultan los registros públicos y aplican reglas de precedencia de versiones que permiten que un paquete público con un número de versión más alto sustituya a un paquete privado con el mismo nombre. Este comportamiento es configurable (se puede imponer la prioridad del registro privado), pero no es la configuración predeterminada en muchas configuraciones habituales.
Por qué es importante
La confusión de dependencias es importante para TPRM porque es un ataque a la cadena de suministro al que sus proveedores pueden ser vulnerables, en particular los proveedores de software y de herramientas de desarrollo que usan registros de paquetes internos junto con dependencias públicas. Un proveedor cuyo entorno de compilación es vulnerable a la confusión de dependencias puede sufrir el compromiso de su canalización de compilación sin que se explote ninguna vulnerabilidad tradicional, lo que produce artefactos de software que contienen código del atacante pero superan la revisión de código y el análisis de seguridad estándar.
- Vulnerabilidad del entorno de compilación del proveedor a la confusión de dependencias sin evaluar
- La configuración de prioridad del registro privado no se incluye en las preguntas de seguridad a los proveedores
- Exposición de los nombres de paquetes internos en fuentes públicas sin evaluar
- Configuración de la resolución de dependencias fuera del alcance de la evaluación de TPRM
- Vectores de ataque en tiempo de compilación sin evaluar junto con la seguridad en tiempo de ejecución
Cómo se ve una buena práctica
Los programas maduros de seguridad de la cadena de suministro de software evalúan la configuración del entorno de compilación de los proveedores en busca de vulnerabilidades de confusión de dependencias: en concreto, si se impone la prioridad del registro privado, si los nombres de paquetes internos están reservados en los registros públicos y si los entornos de compilación están configurados para rechazar paquetes de fuentes inesperadas.
- Imposición de la prioridad del registro privado: los paquetes privados se resuelven antes que los públicos
- Reserva de los nombres de paquetes internos en los registros públicos como medida defensiva
- Aislamiento del entorno de compilación: acceso restringido a la red durante las compilaciones
- Verificación de la integridad de los paquetes: verificación de hashes para todos los paquetes resueltos
- Auditoría de la resolución de dependencias: revisión de la configuración de resolución de registros
Herramientas
Detección de confusión de dependencias: Confused, Protect de Socket.dev para pruebas de confusión de dependencias
Las herramientas de prueba de confusión de dependencias pueden identificar nombres de paquetes internos que no están registrados en los registros públicos y que, por tanto, son posibles objetivos de ataques de confusión de dependencias. Para los profesionales de TPRM, preguntar si los proveedores han comprobado la disponibilidad de sus nombres de paquetes internos en los registros públicos y si los han reservado de forma defensiva es una pregunta concreta sobre la mitigación de la confusión de dependencias.
Desafíos de gobernanza
El desafío de gobernanza de la confusión de dependencias es la complejidad de la configuración. Configurar correctamente la prioridad de registros de los gestores de paquetes en todos los entornos de desarrollo, canalizaciones de CI/CD y estaciones de trabajo de los desarrolladores requiere políticas y una aplicación deliberadas: la configuración predeterminada suele ser insegura. La solución de gobernanza consiste en estándares explícitos de configuración de registros aplicados de forma coherente en todos los entornos de compilación.
- Imponga la prioridad del registro privado en todas las configuraciones de los gestores de paquetes
- Reserve de forma defensiva los nombres de paquetes internos en los registros públicos
- Audite la configuración de registros en todos los entornos de compilación
- Pruebe la confusión de dependencias con herramientas de detección automatizadas
- Incluya la resolución de dependencias en la evaluación de seguridad de la compilación de los proveedores
Si usted forma parte de un equipo pequeño
Para sus proveedores de software más críticos, haga una pregunta que su cuestionario de seguridad estándar no aborda: ¿usan registros de paquetes privados junto con registros públicos y, de ser así, cómo garantizan que sus sistemas de compilación resuelvan primero desde los registros privados para evitar la confusión de dependencias? Un proveedor que usa registros públicos y privados sin imponer explícitamente la prioridad del registro privado es vulnerable al ataque. Pregunte si han verificado que sus nombres de paquetes internos no estén registrados por terceros en los registros públicos.
- Pregunte si el proveedor usa registros privados y públicos, y cómo tiene configurada la prioridad de resolución
- Pregunte si los nombres de paquetes internos se han reservado en los registros públicos
- Pregunte por las pruebas de confusión de dependencias en el entorno de compilación
- Incluya la configuración de registros en la evaluación de seguridad de la compilación
Qué exigir
Pregunte directamente:
“¿Usan registros de paquetes privados junto con registros públicos en su entorno de compilación? ¿Cómo garantizan que los paquetes privados se resuelvan con prioridad para evitar ataques de confusión de dependencias, en los que un paquete público con una versión más alta sustituye a sus paquetes internos?”
Evidencia que debe esperar
- Documentación de la configuración de prioridad de registros
- Reserva de los nombres de paquetes internos en los registros públicos
- Resultados de las pruebas de confusión de dependencias
- Aislamiento del entorno de compilación respecto del acceso a redes externas
A un proveedor que confirma prácticas de compilación seguras se le debe preguntar específicamente por la mitigación de la confusión de dependencias. La seguridad del entorno de compilación incluye la configuración de registros, no solo la revisión de código y el análisis estático.
Cómo demostrarlo
- Auditoría de la configuración de prioridad de registros
- Verificación de la reserva de los nombres de paquetes internos
- Registros de las pruebas de confusión de dependencias
- Estándares de configuración del entorno de compilación
Conclusión clave
Nombre del paquete interno: en una oferta de empleo. Registro público: el atacante registró el mismo nombre con una versión más alta. Sistema de compilación: resolvió el paquete público. Aplicaciones de 23: el código del atacante se ejecutó durante la instalación de dependencias. No se explotó ninguna vulnerabilidad. No se eludió ninguna revisión de código. El mecanismo de resolución hizo lo que estaba configurado para hacer. Imponer la prioridad del registro privado lo impide: el paquete privado se resuelve primero sin importar el número de versión. Reservar el nombre en los registros públicos lo impide: el atacante no puede registrar un paquete con el nombre que la empresa ya tiene. Ambas son decisiones de configuración, no reformas de la arquitectura.