flawopen.com/Referencia/Dependency Confusion
Dependency Confusion: cómo se confunden los orígenes de paquetes
Imagina que tu equipo pide un componente en un catálogo de proveedores, pero dos proveedores usan el mismo nombre de producto. Si las reglas no identifican al proveedor autorizado, la compilación puede recibir un componente inesperado. Dependency Confusion es este fallo de selección de origen: la compilación resuelve un paquete desde un registro o espacio de nombres en el que la organización no pretendía confiar.
Cómo ocurre Dependency Confusion
El comportamiento depende del gestor y su configuración. Un caso concreto es pip: su documentación advierte que combinar un --index-url privado con un --extra-index-url público puede permitir que se elija un paquete público con el mismo nombre. npm selecciona un registro según el scope del paquete o su configuración predeterminada; no compara universalmente las versiones privadas y públicas para elegir la mayor. La causa común es una política de origen ambigua. Si se instala el paquete y sus scripts están habilitados, se ejecutan con los permisos disponibles para esa tarea de compilación.
[global]
index-url = https://packages.example.internal/simple
extra-index-url = https://pypi.org/simple
corp-auth-utils@corp:registry=https://packages.example.internal/repository/npm/
{
"dependencies": {
"@corp/billing-engine": "1.2.0"
}
}Una ruta de fallo de Dependency Confusion
- 1El nombre de un paquete interno o espacio de nombres se descubre fuera de la organización.
- 2Un registro público contiene un paquete con el mismo nombre sin scope, o la política configurada permite que ese origen responda a la solicitud.
- 3El resolvedor selecciona el origen no previsto; el lockfile o la revisión pueden no detectar el cambio si falta, se regenera o se acepta sin inspección.
- 4Si los scripts de instalación o compilación están habilitados, el código del paquete se ejecuta con los permisos de la tarea. El impacto depende de las credenciales, la red y el aislamiento; ejecutar como root no es inherente a esta clase de ataque.
Controles de ingeniería defensiva
- ✓Haz explícita la política de origen: usa scopes o espacios de nombres de la organización cuando estén disponibles, dirígelos al registro previsto y evita recurrir a fuentes públicas para nombres privados. En Python, no combines un índice privado con
--extra-index-urlpara paquetes privados; usa un proxy controlado o un único índice autoritativo. - ✓Controla la propiedad del espacio de nombres: reserva los nombres de la organización en los registros cuando sea posible, pero no sustituyas la política del resolvedor por la reserva. Inventaría los nombres internos y vigila las colisiones públicas.
- ✓Revisa y exige lockfiles: guarda el lockfile y usa el modo de instalación congelado/CI del gestor (en npm,
npm ci). Revisa cambios en nombres, URL de registros, versiones y valores de integridad. Un lockfile mejora la repetibilidad, pero no demuestra que el origen sea el editor esperado. - ✓Limita la ejecución de compilación: desactiva scripts de dependencias cuando el proyecto pueda funcionar sin ellos y revisa las excepciones. Usa credenciales breves y con privilegios mínimos; aísla la compilación de los secretos de producción y limita la salida de red.