Los desarrolladores usan un asistente de código con IA que sugiere un paquete que no está en su lista aprobada. ¿Cuál es el riesgo y qué haces?

Este escenario evalúa si tratas la salida de una IA como entrada no confiable y la conectas con controles de cadena de suministro, en lugar de simplemente prohibir la herramienta.

El riesgo

OWASP incluye la desinformación (LLM09:2025) entre los principales riesgos de los LLM y menciona la generación de código inseguro: los modelos pueden sugerir «bibliotecas de código inseguras o inexistentes». La página describe a atacantes que publican paquetes maliciosos con nombres a menudo alucinados, que los desarrolladores pueden instalar sin saberlo. La sobreconfianza, «los usuarios depositan una confianza excesiva en el contenido generado sin verificar su exactitud», lo agrava.

Qué haces

Primero, no instales el nombre desconocido: comprueba que el paquete existe, quién lo mantiene, cuándo se creó y si encaja con lo que necesita el código. A largo plazo, estructura el control: dirige las instalaciones a través de un proxy de registro interno con lista de permitidos, fija versiones con lockfiles, ejecuta análisis de composición de software y exige revisión de los cambios de dependencias en pull requests.

Alineación con las mitigaciones de OWASP

OWASP recomienda verificación cruzada y supervisión humana, validación automática de salidas clave, prácticas de codificación segura y formación de los usuarios sobre los límites de los LLM.

Por qué los distractores tientan

«El modelo lo validó» es justo el fallo de sobreconfianza. «Probar en producción» y «prohibir todo» son los extremos.

Lo que buscan los entrevistadores

Nombrar la alucinación de paquetes, tratar la salida como no confiable y proponer controles por capas y proporcionados.