Cómo detectar dependencias falsas con slopsquatting

El slopsquatting es un vector de ataque que aprovecha las alucinaciones de la IA cuando inventa nombres de paquetes que no existen. Si trabajas con Python y confías en el código generado por IA sin verificar cada dependencia, esta amenaza te afecta directamente. Aquí aprenderás a detectarla y mitigarla antes de que un atacante la explote.

Por qué la IA inventa dependencias que no existen

Todo parte de un archivo requirements.txt con un import que suena perfectamente normal: un paquete llamado request utils. El problema es que no existe. La IA lo inventó en algún momento y nadie lo notó porque el nombre es plausible [00:12].

Lo interesante es que estas alucinaciones no son aleatorias, son predecibles. Cuando le pides a la IA código para cierta tarea, tiende a proponer el mismo nombre de paquete una y otra vez, entre distintas ejecuciones e incluso entre distintos usuarios [00:40].

Esa predictibilidad es justo lo que permite el ataque. Un atacante registra el paquete inventado en un repositorio real y le inyecta código malicioso.

¿Qué es el slopsquatting? Es un ataque en el que alguien registra un nombre de paquete que la IA inventa de forma repetida y le inserta código malicioso. Como el nombre parece legítimo, los desarrolladores lo instalan sin sospechar.

Qué es la confusión entre registros

Otro riesgo asociado es la cross-registry confusion, o confusión entre registros. Aquí la IA recomienda, por ejemplo, un paquete real de Node pero asume que también existe en Python [01:10].

Ese patrón es exactamente lo que identifica el atacante: un nombre que vive en un ecosistema pero que la IA traslada a otro donde nunca existió. La defensa específica es verificar cada dependencia contra el registro real antes de confiar en ella.

Cómo auditar dependencias contra PyPI antes de confiar

En la rama preparada para la clase hay un requirements.txt con una dependencia sospechosa: request_ai_utils. No es oficial, la IA simplemente la inventó [00:52].

El primer paso es correr un script de auditoría, llamado audit dependencies, que verifica si esa dependencia realmente existe en PyPI [01:30]. El resumen confirma que no existe y que no se trata de un typo, sino de un nombre completamente inventado.

Este escenario es peligroso por una razón concreta: si alguien registra esa dependencia en PyPI con código malicioso, cualquier pip install desde ese repositorio ejecutará ese código.

¿Cómo verifico si un paquete de Python existe de verdad? Consulta el paquete directamente contra el registro oficial de PyPI, no contra la memoria de la IA. Un script de auditoría automatizado confirma si el nombre está registrado o fue inventado.

Qué mitigaciones aplicar en tu repositorio

La mitigación principal es eliminar el import inventado. Pero puedes reforzar tu proyecto con varias prácticas complementarias [02:05]:

• Fijar versiones con hashes que ya conoces.
• Agregar verificación contra los registros como auditoría continua.
• Incorporar el script de auditoría como paso obligatorio antes de aceptar cambios en requirements.txt.
• Establecer que cada dependencia se verifique manualmente.
• Revisar el historial de cambios del archivo de requerimientos.

Cada una de estas prácticas reduce la superficie de ataque, pero la clave es que tú las evalúes dentro de tu propio contexto y decidas cuáles funcionan.

Cómo usar un prompt de auditoría de cadena de suministro

Para implementar y proponer mitigaciones, se construyó un prompt integrado con el script de auditoría. Su propósito es realizar una auditoría continua actuando como un auditor de seguridad de cadena de suministro para un servicio de PyPA [02:50].

El prompt genera un reporte de riesgo en Markdown con reglas estrictas. No debe inventar información, ni revisar reputación remota fuera de la evidencia, ni incluir datos que no estén en los archivos adjuntos. La existencia de una dependencia debe basarse en la salida del auditor, nunca en la memoria o en suposiciones.

Como evidencia se adjuntan dos archivos: el requirements.txt y la salida del script ejecutado.

Qué restricciones incluye el prompt de seguridad

El prompt impone límites claros para evitar falsos positivos y recomendaciones peligrosas [03:40]:

• No afirmar que el paquete es malicioso solo porque no existe.
• No recomendar instalar la dependencia sospechosa.
• No proponer controles que requieran herramientas externas no mencionadas.
• Declarar de forma explícita cuando falte evidencia.

Unos minutos después, el reporte identifica que la dependencia no existe, muestra la evidencia y explica el riesgo de slopsquatting. También sugiere mitigaciones específicas para el proyecto, como eliminar la dependencia y volver obligatoria la verificación manual.

Por qué la verdad de una dependencia la da el registro

Aquí está el punto central: si tu IA inventa dependencias y las apruebas a ciegas, estás certificando contenido falso dentro de tu código [04:30].

Si tuvieras clientes, no solo certificas ese contenido, también abres la puerta a los atacantes. La verdad sobre una dependencia no la provee la IA, la provee el registro. Por eso la auditoría continua contra PyPI usando hashes anclados a estándares de desarrollo seguro es la práctica que cierra ese hueco.

Existe otra vulnerabilidad distinta: la que aparece cuando el punto de contacto no es el requirements.txt, sino tu propio código, ese que se abre cuando tu app llama a un LLM. ¿Ya revisaste cómo la IA maneja las dependencias en tus propios proyectos? Cuéntame en los comentarios qué prácticas de verificación aplicas hoy.