Hace unos años dediqué veinte minutos a un pull request que cambiaba exactamente un paquete en composer.lock. Leí el changelog, repasé el diff de vendor buscando algo raro y comprobé quién tenía permisos de commit en el repo original. Durante esa misma revisión, mi editor actualizó once extensiones en segundo plano. No me di cuenta de ninguna, sigo sin saber qué cambió y ese contraste me ronda desde entonces.

La herramienta que escribe nuestro código, que abre todos los archivos del repo, vendor y el .env incluidos, y que se ejecuta con mi propia cuenta de usuario es la única parte de la cadena de herramientas que la mayoría de los equipos deja al gusto de cada uno. Creo que nos estamos equivocando. Las extensiones del editor van en el mismo saco que los paquetes de Composer: se declaran por proyecto, se revisan cuando cambian y son del equipo, no de quien las instaló primero.

Este año nos dio la razón. El 18 de mayo se publicó Nx Console 18.95.0 tanto en el Visual Studio Marketplace como en Open VSX con código malicioso dentro. Lo retiraron rápido, pero hubo una ventana. Por las mismas fechas, GitHub reveló que el dispositivo de un empleado había sido comprometido a través de una extensión de VS Code de terceros envenenada, y que lo que decía el atacante, haber llegado a unos 3,800 repositorios internos, coincidía a grandes rasgos con sus propias conclusiones. Cinco meses después, los detalles importan menos que la forma en que ocurrió. Nadie instaló una herramienta dudosa de un desconocido. Un nombre en el que la gente confiaba desde hacía años publicó una versión, y en escritorio el host de extensiones puede hacer todo lo que puede hacer el editor: leer y escribir en disco, abrir conexiones de red, lanzar procesos. Una empresa que ejecuta composer audit en cada build de CI puede seguir teniendo una puerta abierta de par en par en cada portátil.

El mejor argumento en mi contra es bueno, y yo he estado de su lado. Cada desarrollador elige sus herramientas, y un editor bloqueado trae recuerdos de aquella imagen corporativa de escritorio que tuvo fijado un navegador prehistórico durante años. Las extensiones publican correcciones constantemente, así que congelarlas significa convivir con fallos conocidos, algunos de ellos de seguridad. Y una agencia de cuatro personas no tiene un equipo de plataforma que se dedique a curar nada. Más de una vez me he instalado a escondidas un tema más bonito saltándome la política, y lo volvería a hacer.

Pero un lockfile no congela nada. composer.lock nunca nos ha impedido actualizar. Lo que hace es convertir una actualización en un cambio visible que alguien acepta a propósito. La versión para el editor puede ser muy ligera. El equipo acuerda un conjunto compartido y corto para el proyecto, por ejemplo tu servidor de lenguaje de PHP, el adaptador de Xdebug y lo que ejecute Pint o php-cs-fixer al guardar. Todo lo que quede fuera de ese conjunto está permitido, pero corre de tu cuenta. Cuando algo del conjunto compartido cambia, recibe el mismo vistazo de treinta segundos que una subida menor de un paquete: ¿el publicador sigue siendo quien creemos?, ¿esta versión se parece a las anteriores? Eso no lo va a detectar todo. Pero significa que alguien miró, que ya es más de lo que pasa hoy.

Sabemos hacerlo, y eso es lo que casi me hace gracia. El mundo PHP pasó una década sacudiéndose la fama de aquella época en que se copiaban scripts de foros directamente a public_html, y Composer junto con Packagist volvieron la higiene de dependencias tan rutinaria que ya casi ni pensamos en ella. Quienes trabajan con Go tienen una base de datos de checksums entre ellos y sus módulos, y les tengo un poco de envidia. Nuestros editores no tienen nada parecido entre nosotros y un publicador al que acaban de robarle el token, así que por ahora la única protección que tenemos son los hábitos del propio equipo.

Lo que esto cuesta de verdad es quizá una hora al mes de atención de alguien, más una conversación incómoda sobre quién es el dueño de la lista. Me quedo con ese trato. «Que todo el mundo tenga cuidado con las extensiones» es un consejo que nadie puede poner en práctica. «¿Quién aprueba los cambios en el conjunto compartido del editor?» es una pregunta que puedes zanjar en el standup del lunes.

Así que me gustaría saber cómo lo gestiona tu equipo. ¿La configuración de tu editor vive junto a composer.json como una decisión del proyecto, con una persona concreta que la revisa, o crees que el editor debe seguir siendo personal y que la verdadera defensa está en otro sitio, como credenciales más restringidas o contenedores de desarrollo aislados? Y si tu equipo ha intentado gobernar las extensiones y lo ha dejado, ¿qué hizo que todo se viniera abajo?