Slopsquatting: comprobar un paquete de Composer que ha propuesto la IA

Hola, bienvenido. En esta lección vamos a ver el primero de los 6 fallos de invoices. Está en la última tarea del plan del agente, que propone instalar un paquete de Composer que no existe. A esto se le llama slopsquatting. Un modelo de IA se inventa el nombre de un paquete, alguien registra ese nombre en Packagist con su código dentro y espera a que otro lo instale siguiendo la propuesta del agente. Vamos a ver por qué pasa, cómo se comprueba un paquete antes de instalarlo y qué hace Composer por su cuenta desde la 2.10, y vamos a terminar reescribiendo la tarea.

Partimos de invoices tal como lo dejamos en la lección anterior, con Sail levantado y composer qa en verde. Esta es la tarea que el agente dejó sin marcar en docs/plan.md:

Fíjate en que no hay nada raro en ella. El vendor es laravel, el nombre dice justo lo que hace el paquete y la orden viene lista para copiar. Si el agente hubiera seguido trabajando, su siguiente paso habría sido ejecutarla. El problema es que laravel/invoice-pdf no existe en Packagist: el agente se lo ha inventado.

Un paquete alucinado es una dependencia que un modelo de IA propone con toda naturalidad y que no existe en el repositorio de paquetes. El modelo no consulta Packagist antes de escribir el nombre. Lo compone con lo que le parece más probable, y en Laravel lo más probable es el vendor más conocido del ecosistema seguido de 2 palabras de la tarea. laravel/invoice-pdf es exactamente eso.

¿Y por qué es un problema de seguridad y no un simple error que salta al instalar? Porque el nombre inventado se repite. En 2025 se presentó en USENIX Security un estudio que generó 576.000 muestras de código en Python y JavaScript con 16 modelos distintos, y encontró más de 205.000 nombres de paquete inventados diferentes. Y muchos se repiten: al repetir 10 veces la misma pregunta, el 43 % de los nombres inventados salía en las 10 respuestas, y el 58 % salía más de una vez. Además, casi 1 de cada 5 lo generaba más de un modelo. Es decir, el modelo vuelve a dar el mismo nombre inventado una y otra vez.

Ahí es donde entra quien ataca. Si un nombre inventado se repite, basta con registrarlo en el repositorio de paquetes con código dentro y esperar a que un agente lo proponga y alguien lo instale. ¿Y qué gana con eso? Su código dentro de tu proyecto, con los mismos permisos que tu aplicación. El autoload de Composer carga el código del paquete y Laravel descubre sus service providers, así que se ejecuta en tu máquina, en CI y en producción. Y lo hace con acceso al .env, a la base de datos y a las claves de los servicios. En Paquetes maliciosos en Packagist↗ (se abre en una pestaña nueva) tienes un caso real de 2024, con paquetes que se hacían pasar por utilidades de Laravel y abrían un acceso remoto en cada arranque de la aplicación.

La cadena de suministro tiene más frentes, como composer.lock, los tags que se reescriben, allow-plugins o autoload.files. En esta lección nos quedamos con el que abre un agente: el paquete que propone sin comprobarlo.