Dependency Confusion y Typosquatting: Defensa Practica para Equipos Dev

En 2021 un investigador facturo mas de 130 mil dolares en bug bounty publicando paquetes con nombres internos de Apple, Microsoft, PayPal y decenas de empresas en npm y PyPI publicos. El ataque no uso ningun zero-day: solo exploto la precedencia que los gestores de paquetes dan al registry publico cuando el nombre existe en ambos lados. Cinco anos despues, equipos Basilisk siguen encontrando ese vector abierto en 7 de cada 10 pipelines auditados. Dependency confusion y typosquatting no son curiosidades academicas, son la puerta barata para comprometer un build entero y, por consecuencia, a todo cliente que recibe ese artefacto.

El mecanismo del dependency confusion es simple y cruel. Tienes un paquete interno llamado acme-payments-sdk alojado en un Nexus o Artifactory privado. Un atacante descubre ese nombre en un package.json filtrado, un post de Stack Overflow o una capa docker publica, y publica acme-payments-sdk@99.0.0 en npmjs.com. La proxima vez que el pipeline ejecuta npm install sin un lockfile estricto, el resolver elige la version mayor. Listo, codigo arbitrario corriendo en tu CI con credenciales AWS, tokens de GitHub y acceso al registry interno. Lo vimos en campo en pruebas parecidas a Pentest de APIs REST y GraphQL: Checklist Tecnico para Bug Bounty Legal, donde la superficie de build era mas explotable que la propia API.

El typosquatting juega en otra liga. En vez de asumir el nombre real, el atacante registra colorss, requets, python-dateutill, lodahs. Investigacion de Phylum en 2024 catalogo mas de 11 mil paquetes maliciosos en PyPI usando ese patron en doce meses. Los payloads varian: robo de variables de entorno, mineria, instalacion de RAT, exfiltracion via DNS. La primera defensa es cultural: code review obligatorio en cualquier cambio de dependencia. Herramientas como Socket, Snyk Advisor y deps.dev ya senalan paquetes recien publicados, sin historico de mantenedor o con patrones sospechosos en el install script.

Los lockfiles resuelven el 80 por ciento del problema si se usan en serio. package-lock.json, yarn.lock, pnpm-lock.yaml, poetry.lock, Cargo.lock y go.sum amarran no solo la version sino el hash. Configura npm ci, pnpm install --frozen-lockfile, pip install --require-hashes y cargo --locked en los pipelines. Nada de npm install suelto en produccion. Combinado con un .npmrc que defina registry=https://nexus.interno/repository/npm-group/ y always-auth=true, reduces drasticamente la chance del resolver ir al registry publico por error. El patron mental se parece al que discutimos en Supply Chain Security: Firma con Sigstore y SBOM Real en CI/CD al hablar de SBOM y atestaciones.

El scoping es el arma definitiva contra dependency confusion en JavaScript. Migra todos los paquetes internos a @acme/payments-sdk, @acme/auth, @acme/billing. En el .npmrc, define @acme:registry=https://nexus.interno/. Ahora npm solo resuelve ese scope en el registry interno, aunque alguien publique @acme/payments-sdk en npmjs (Microsoft reserva scopes comunes desde 2021). En Python, usa indexes separados explicitos con pip --index-url para internos y --extra-index-url solo cuando necesario, o mejor, espeja todo via devpi o Artifactory. Para Go, GOPRIVATE=git.acme.com bloquea consultas a proxy.golang.org. Este hardening dialoga directo con Hardening de Linux Server: CIS Benchmark Aplicado sin Romper Produccion sobre principio de menor privilegio.

En el lado del CI, aisla. Cada job de build debe correr con tokens efimeros, sin acceso a produccion, con salida de red filtrada por egress proxy permitiendo solo registry interno, github.com y endpoints conocidos. OIDC con credenciales short-lived en GitHub Actions o GitLab CI elimina secrets largos. Agrega un step de verificacion pre-install: scripts/check-deps.sh que ejecuta npm audit signatures, valida que ninguna dependencia fue publicada en los ultimos 7 dias sin aprobacion manual, y chequea paquetes contra una allowlist. El equipo de Datadog publico un reporte en 2025 mostrando que 62 por ciento de los compromisos de supply chain habrian sido bloqueados con esas tres reglas combinadas.

El monitoreo continuo cierra el ciclo. Configura alertas en Sigstore Rekor para cualquier publicacion con tu nombre de organizacion, registra dominios tipo-squatting de tu producto (acme-cloud, acme-coud, acmecloud), y manten un inventario de SBOMs firmados via cosign para cada release. Cuando un paquete sospechoso aparezca, ya tienes evidencia para el takedown y datos para el incident response, en el estilo que mostramos en DFIR en Linux: Triaje en Vivo con UAC y Velociraptor. Entrena al equipo para reportar cualquier warning de install script nuevo, sin reflejo de ignorar. Takeaway practico: hoy mismo, audita tus .npmrc, .pip.conf y go env. Si no puedes responder en 30 segundos de que registry viene cada dependencia, ya estas vulnerable.