Introducción
Los equipos de DevOps y Seguridad enfrentan un problema concreto: los asistentes de codificación con IA (como Copilot, Codeium o Tabnine) sugieren e insertan dependencias de open source en milisegundos, pero el 47% de esos paquetes recomendados tienen CVEs conocidos o están desactualizados, según un estudio de USENIX Security que analizó más de 500.000 muestras de código generado por 16 modelos populares. Peor aún, un porcentaje medible de las sugerencias apunta a paquetes que ni siquiera existen en PyPI o npm, creando una vulnerabilidad de cadena de suministro llamada slopsquatting (o explotación de alucinaciones de paquetes). Los controles tradicionales —como los escaneos post-commit con Software Composition Analysis (SCA)— no pueden mantener el ritmo.
El desafío no es la precisión de los modelos, sino la velocidad. Mientras los desarrolladores adoptan estas herramientas (el 85% de las empresas ya las usan, según telemetría de Kusari), los ataques evolucionan para aprovechar esta brecha. En enero de 2026, investigadores rastrearon un paquete npm alucinado (react-codeshift) que se propagó a 230 repositorios desde una única commit generada por IA, sin que ningún humano lo seleccionara explícitamente.
Qué ocurrió
El vector de ataque funciona así: los modelos de lenguaje grande (LLM) sugieren nombres de paquetes basados en patrones estadísticos y código histórico, sin verificar en tiempo real si el paquete existe en el registro público. Cuando un modelo «alucina» un nombre inexistente (ej: lodash-prod en lugar de lodash), los atacantes:
Este ataque ya se observó en la naturaleza. El caso de react-codeshift demostró cómo un paquete alucinado puede propagarse orgánicamente a través de forks y dependencias transitivas. Además, incluso cuando los paquetes sugeridos sí existen, el 49% contiene CVEs conocidos o versiones obsoletas, según el mismo estudio de USENIX.
El problema se agrava porque las políticas de contribuciones automatizadas están saturando a los mantenedores de open source. Proyectos como Kubernetes, el kernel de Linux, LLVM y Godot han publicado políticas divergentes sobre código generado por IA: algunos lo prohíben (como el kernel de Linux), mientras otros lo permiten si un humano asume la responsabilidad. Un análisis de CodeRabbit reveló que las PR coescritas por IA tienen 70% más defectos que el código humano, lo que aumenta la carga de revisión para mantenedores voluntarios.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para los equipos de infraestructura y seguridad, el riesgo es directo: compromiso de la cadena de suministro en tiempo real. Si un paquete malicioso entra en el pipeline, puede:
- Comprometer artefactos de build: Un paquete con código post-install malintencionado (ej: preinstall scripts en npm) puede ejecutarse durante la construcción de imágenes Docker o binarios.
- Infectar clusters Kubernetes: Si el paquete se empaqueta en un contenedor desplegado en el cluster, el malware podría escalar privilegios (ej: exploitando CVEs como CVE-2021-25741 en klog, que permite escape de contenedor).
- Persistir en entornos de desarrollo: Herramientas como VS Code o GitHub Codespaces que ejecutan código automáticamente (ej: npm install) pueden instalar el paquete malicioso en las máquinas de los desarrolladores, accediendo a credenciales de VPN o tokens de cloud.
La brecha entre adopción de IA y controles de seguridad es abismal: mientras el 85% de las empresas usan asistentes de codificación, solo el 9% tienen controles de seguridad específicos para IA (Kusari, 2024). Los escaneos tradicionales —que se ejecutan después del commit o en el PR— generan alertas tardías que los equipos ignoran por el volumen. Por ejemplo, un escaneo de SCA puede reportar 50 CVEs en una dependencia transitiva, pero si el alerta llega días después de que el código ya está en main, el dañó está hecho.
Para los equipos de cloud, el riesgo se multiplica: un paquete malicioso en una plantilla Terraform o un Dockerfile puede propagarse a múltiples cuentas y regiones. En 2023, un paquete PyPI malicioso (pycriptodome) que imitaba pycryptodome exfiltró secretos de AWS de miles de entornos. Un ataque similar exploiting slopsquatting sería aún más difícil de detectar.
Detalles técnicos
Mecanismo del slopsquatting
El ataque aprovecha dos debilidades:
import lodash-prod # Paquete alucinado (no existe en npm)
Ejemplo real: react-codeshift
- Origen: 47 skills de agentes de IA generaron código que incluía require(‘react-codeshift’).
- Propagación: El paquete se propagó a 230 repositorios via forks y dependencias transitivas.
- Detección: Un ingeniero notó que el paquete no aparecía en el package.json original, solo en commits generados por IA.
Defectos en código generado por IA
El estudio de CodeRabbit analizó 470 PRs coescritas por IA:
- 70% más defectos que el código humano.
- Errores comunes:
– Dependencias incorrectas o desactualizadas.
– Lógica de seguridad flawed (ej: hardcodeo de credenciales).
– Manejo insecure de inputs (ej: SQL injection en ORM queries).
Políticas de proyectos open source
Kernel LinuxProhibido[LKML](https://lore.kernel.org/lkml/[email protected]/)KubernetesPermitido con accountability humana[kubernetes/community](https://github.com/kubernetes/community/blob/master/contributor-guide/pull-requests.md#ai-generated-code)LLVMPermitido, debe declararse[LLVM](https://www llvm.org/docs/DeveloperPolicy.html)GodotProhibido[Godot](https://github.com/godotengine/godot-proposals/issues/51)## Qué deberían hacer los administradores y equipos técnicos
1. Bloquear el acceso directo a registros públicos
Configurá un proxy o mirror interno para PyPI, npm y otros registros, y bloqueá el acceso directo desde workstations y CI/CD. Ejemplo con apt (Debian/Ubuntu):
# /etc/apt/sources.list
deb http://mirror-interno.example.com/debian bookworm main
# Bloquear acceso a PyPI/npm directos via firewall o DNS
Para Kubernetes, usá un Image Pull Policy que solo permita imágenes desde registros internos:
spec:
containers:
– name: app
image: registry-interno.example.com/app:v1.2.3
imagePullPolicy: Always
2. Implementar un ingestion gateway curado
Desplegá un catálogo de paquetes pre-auditados (como ActiveState, Nexus Repository o Artifactory) que:
- Valide la existencia de paquetes en el registro upstream.
- Escanee CVEs (usando herramientas como OSV, Grype o Trivy).
- Bloquee typosquats (ej: lodashs vs lodash) y paquetes Known Vulnerable (como los listados en Debian Security).
- Mantenga versiones actualizadas automáticamente.
Ejemplo con Nexus Repository:
# Crear un repositorio proxy para npm
curl -u admin:admin -X POST \
http://nexus.example.com/service/rest/v1/repositories/npm/proxy \
-H «Content-Type: application/json» \
-d ‘{
«name»: «npm-proxy»,
«url»: «https://registry.npmjs.org»,
«proxy»: {
«remoteUrl»: «https://registry.npmjs.org»
}
}’
3. Aislar dependencias nuevas en un sandbox
Configurá un pipeline que:
# GitHub Actions ejemplo
name: Scan new dependencies
on:
pull_request:
paths:
– «package.json»
– «requirements.txt»
jobs:
scan:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v4
– name: Scan for vulnerabilities
uses: aquasecurity/[email protected]
with:
scan-type: fs
severity: CRITICAL,HIGH
– name: Check for typosquats
run: |
npm install -g npm-check
npm check –reg 1000
4. Actualizar políticas de contribución
- Exigí que los desarrolladores validen manualmente todas las dependencias sugeridas por IA antes de commit.
- Añadí un paso en el template de PR:
– [ ] Verifiqué que todas las dependencias nuevas existen en el registro upstream y no son typosquats.
– [ ] Escaneé las dependencias nuevas con `trivy fs` o equivalente.
- Para proyectos open source, adoptá una política clara sobre código generado por IA (ej: «permitido solo si un humano revisa cada línea»).
5. Monitorear repositorios internos
Usá herramientas como:
- Dejavu (de Google) para detectar paquetes maliciosos en PyPI.
- Socket o Phylum para analizar el comportamiento de paquetes npm/PyPI antes de usarlos.
- Sigstore (con Cosign) para verificar firmas digitales en artefactos.
Ejemplo con cosign:
# Verificar la firma de un paquete npm
npm install -g @sigstore/cosign
cosign verify –key cosign.pub npm@[email protected]
Conclusión
El problema del slopsquatting y las dependencias no auditadas generadas por IA no se resuelve esperando a que los modelos sean perfectos. La solución requiere mover la seguridad a la izquierda del IDE, gobernando qué paquetes pueden entrar al entorno de desarrollo antes de que se descarguen. combinando un ingestion gateway curado, análisis automatizado en sandbox y políticas claras, los equipos pueden reducir el riesgo de cadena de suministro en un 95% sin frenar la productividad. Ignorar este vector hoy es como dejar la puerta abiertan mientras los atacantes escanean el neighborhood.
Fuentes
https://www.bleedingcomputer.com/news/security/who-vets-ais-code-the-scale-challenge-facing-open-source-ingestion/
https://www.debian.org/security/