ATALAIALos equipos que escanean cada dependencia de un lockfile suelen dejar que los desarrolladores instalen cualquier extensión de editor que quieran. Y sin embargo una extensión está más cerca de las joyas de la corona que la mayoría de paquetes: se ejecuta cada día en el portátil que guarda el código fuente, las claves SSH y las credenciales cloud.
Este artículo explica cómo funcionan realmente las extensiones, a qué pueden acceder y una forma práctica de conseguir un inventario y una allowlist sin empezar una pelea.
Cómo se ejecutan las extensiones del editor
En la mayoría de los editores populares, las extensiones son paquetes de JavaScript, a veces con binarios nativos, que el editor carga en un proceso extension host. Ese proceso se ejecuta como el usuario que ha iniciado sesión. Normalmente no hay un aviso de permisos por extensión como el que mostraría una app de móvil.
En la práctica, una extensión puede:
- Leer y escribir cualquier fichero que pueda el usuario, no solo los del workspace abierto.
- Lanzan procesos, incluidos shells, compiladores y gestores de paquetes.
- Hacer peticiones de red salientes a cualquier host.
- Leer variables de entorno, que a menudo incluyen tokens exportados en el perfil del shell.
- Acceden a secretos y ajustes guardados en el editor, y se enganchan a terminales y al control de versiones.
Algunos editores ofrecen un modo restringido para espacios de trabajo no fiables, que limita lo que se ejecuta al abrir una carpeta desconocida. Es útil, pero protege contra repositorios hostiles, no contra una extensión que ya has instalado y en la que confías.
La ruta de actualización es el riesgo real
Una extensión que revisaste el año pasado no es la extensión que se ejecuta hoy. Por defecto, los marketplaces empujan las actualizaciones automáticamente, y las cuentas de los publishers pueden cambiar de manos o verse comprometidas. El patrón es el mismo que en los ataques a registries de paquetes.
- ConfianzaUna extensión útil gana con el tiempo una gran base de instalaciones.
- CambioLa cuenta del publicador se vende, sufre phishing o pasa a un nuevo maintainer.
- ActualizaciónSale una nueva versión con código extra. Los editores la instalan en silencio.
- EjecutarEn el siguiente arranque se ejecuta con los permisos del desarrollador en cada máquina que lo tenga.
- AlcanzarLee tokens, claves o código fuente y los envía hacia fuera.
Los nombres parecidos son la otra vía: una extensión con un icono familiar y un nombre que difiere en un carácter de otra popular. Ambas son razones por las que «viene del marketplace» no es una revisión.
Inventaria las extensiones de todo un equipo
No puedes poner en allowlist lo que no has visto. Empieza recopilando lo que hay instalado hoy. La mayoría de los editores de la familia VS Code exponen una CLI para esto:
# List installed extensions with versions
code --list-extensions --show-versions
# Extensions also live on disk, one folder per extension@version
ls ~/.vscode/extensionsLos IDEs de JetBrains guardan los plugins en una carpeta por versión dentro del directorio de configuración o de application support del usuario, y otros editores siguen patrones parecidos. Escribe un script pequeño que recoja la lista y el nombre del equipo, y pide a la gente que lo ejecute, o distribúyelo con tu herramienta de gestión de dispositivos si tienes una.
#!/usr/bin/env sh
# collect-extensions.sh: print host, editor and extension@version as CSV
host=$(hostname)
for cli in code codium cursor; do
command -v "$cli" >/dev/null 2>&1 || continue
"$cli" --list-extensions --show-versions 2>/dev/null \
| sed "s/^/$host,$cli,/"
doneCombina las salidas en una sola hoja y ordénala por ID de extensión. Lo normal es ver una cola larga: un núcleo que comparte casi todo el mundo y muchas instalaciones únicas.
Construye una allowlist que la gente acepte
Una allowlist que bloquea a medio equipo el primer día acabará esquivándose. Constrúyela a partir del inventario.
| Bucket | Qué entra | Acción |
|---|---|---|
| Core | Soporte de lenguajes, linters y formatters que usa mucha gente | Revisa una vez, aprueba, fija el ID del publisher |
| De nicho pero justificado | Herramientas que unas pocas personas necesitan para su trabajo | Revisión rápida, aprobación por equipo |
| Desconocido | Instalaciones sueltas que nadie sabe explicar | Pregunta al propietario; elimínalo si no se usa |
| Arriesgado | Publisher sin verificar, código ofuscado, uso amplio de red sin motivo claro | Quitar y sugerir una alternativa |
En cada revisión, comprueba el publisher, el repositorio de código si lo hay, el número de instalaciones y la antigüedad, en qué declara activarse y si incluye binarios nativos. Registra la extensión por su ID completo, no por el nombre visible, para que no se cuelen imitaciones.
Varios editores admiten ajustes de políticas que limitan las instalaciones a extensiones aprobadas o desactivan la actualización automática. Úsalos cuando la lista sea estable y plantéate escalonar las actualizaciones de las extensiones clave en vez de aceptar cada release en cuanto sale.
Qué hacer el lunes
- Ejecuta
code --list-extensions --show-versionsen tu propio equipo y lee la lista. ¿Hay algo que no reconozcas? - Comparte el script de recopilación con el equipo y reúne los resultados en un solo sitio.
- Clasifica en los cuatro grupos de arriba. Aprueba primero el conjunto básico; cubre la mayoría de las instalaciones.
- Escribe un proceso de un párrafo para pedir una extensión nueva, con un revisor con nombre y un plazo de respuesta corto.
- Repite el inventario cada mes. Lo que hay que vigilar es la deriva, no la primera foto.
Las extensiones son herramientas de la línea como cualquier otra. Saber cuáles hay en cada banco y quién las aprobó es todo el trabajo.
Dónde encaja en la línea
En la torre (en desarrollo):