Nombres de paquetes alucinados y de aspecto similar: comprobar una dependencia antes de que un agente la instale

Objetivo

Impedir que un agente instale un paquete cuyo nombre generó de memoria sin confirmar que ese nombre pertenece al proyecto al que se refiere.

Requisitos previos

Acceso a un registro (PyPI, npm u otro) desde un entorno aislado (sandbox); la capacidad de detenerse y preguntar antes de la instalación.

Pasos

1. Tratar cada nombre de paquete que sugiere el modelo como una afirmación por verificar. El artículo «We Have a Package for You!» (Spracklen et al.) estudió la alucinación de paquetes en código generado por LLM y descubrió que los modelos recomiendan paquetes que no existen; un atacante que registre ese nombre recibe las instalaciones.
2. Resolver el nombre contra el registro antes de instalar. Si no existe, no buscar «la coincidencia más cercana»: volver a la documentación de la biblioteca que realmente se necesita.
3. Si existe, confirmar la identidad: la propia documentación o el repositorio del proyecto nombran exactamente ese paquete; el enlace al repositorio en los metadatos del registro apunta de vuelta a ese proyecto.
4. Comprobar si hay señales de un paquete usurpado o de aspecto similar: primera versión muy reciente, una única versión publicada, muy pocas descargas en comparación con el nombre al que se parece, un nombre a una sola edición de distancia de un paquete popular, una descripción copiada de otro proyecto.
5. Inspeccionar qué se ejecuta en el momento de la instalación. npm ejecuta scripts de ciclo de vida como preinstall y postinstall durante npm install; instalar con --ignore-scripts (la opción ignore-scripts de npm) lo evita, al precio de romper los paquetes que realmente necesitan un paso de compilación. Para Python, preferir wheels (--only-binary) para que no se ejecute código de compilación.
6. Fijar la versión confirmada y el hash en el archivo de bloqueo (lock file) para que las ejecuciones posteriores no puedan desviarse hacia otro artefacto.
7. Reportar el resultado de la comprobación, junto con el paquete, la versión y la evidencia de identidad, en la descripción del cambio.

Resultado esperado

Ningún paquete entra en un proyecto basándose únicamente en un nombre generado por el modelo; los paquetes de aspecto similar se detectan antes de que se ejecuten sus scripts de instalación.

Límites y base de verificación

Un paquete legítimo puede verse comprometido a través de la propia cuenta de su mantenedor; las comprobaciones de identidad no detectan eso. Los recuentos de descargas pueden inflarse artificialmente. Las tasas del artículo dependen de los modelos y las instrucciones (prompts) que probó, y no se repiten aquí.