Bumblebee: por qué Perplexity abrió su playbook de seguridad interno (y por qué tu laptop importa más que tu server)
Arranco con el detalle que reencuadra toda la herramienta. Cuando un worm de supply-chain pega en el registry de npm, el payload malicioso casi nunca se dispara cuando descargás el paquete: se dispara en el npm install, a través de un postinstall script que corre automáticamente. Lo que significa que cualquier scanner que llame al package manager para chequear si estás expuesto ya ejecutó exactamente el código que estaba buscando. Salís a cazar el worm, y el worm corre.
Esa sola observación es la tesis de diseño detrás de Bumblebee, el scanner read-only de endpoints que Perplexity abrió como open-source el 22 de mayo bajo Apache 2.0. Es un binario de Go de ~10MB, stdlib puro, cero dependencias non-stdlib, y ya va por 4.400 stars en GitHub. Pero el número de stars no es la historia. La historia es que un AI lab top-tier decidió abrir su playbook de seguridad interno — y que ese playbook responde una pregunta que tu tooling actual, calladito, no puede responder.
La pregunta que tu stack de seguridad no contesta
Imaginate el momento en que sale un advisory nombrando un paquete comprometido. Tu CISO pregunta una sola cosa: ¿qué máquinas de desarrollo tienen esto instalado ahora mismo?
Pensarías que podés contestar eso. No, no limpiamente. Los SBOMs documentan lo que entró en un build artifact. El EDR vigila qué procesos corren y qué toca la red. Ninguno de los dos mira el estado raw on-disk de la laptop de un dev — los lockfiles, los manifests, las editor extensions, los browser add-ons, los caches del package manager desperdigados por todo el home directory. Ese quilombo local es justo donde vive la exposición, y es el punto ciego entre tus dos herramientas de seguridad más caras.
Esto dejó de ser abstracto el 11 de mayo, cuando el grupo que Google rastrea como UNC6780 metió código malicioso en paquetes usados por TanStack, SAP y Zapier, entre otros. Uno de los paquetes afectados venía tirando 12 millones de descargas por semana. El compromiso se propagó en el instante en que los devs corrieron el install — postinstall scripts haciendo su trabajo antes de que nadie se diera cuenta. Las organizaciones que corrían Bumblebee detectaron máquinas expuestas en minutos, según los reportes; los equipos que dependían de revisión manual o scans semanales tardaron días en siquiera dimensionar el blast radius. En un incidente activo, la diferencia entre minutos y días es la diferencia entre un evento contenido y una brecha.
Read-only como restricción deliberada
Bumblebee lee la metadata directamente — lockfiles, manifests, registros de paquetes instalados — y nunca invoca npm, pnpm, pip ni ningún package manager. Eso no es una optimización de performance. Es el punto entero. Leer el estado on-disk no puede disparar el payload, así que el scanner se queda inerte sin importar lo que tengas colgando en tu árbol de dependencias.
Cubre cuatro superficies que normalmente requieren cuatro herramientas separadas: ecosistemas de paquetes de lenguajes (npm, pnpm, Yarn, Bun, PyPI, Go modules, RubyGems, Composer), editor extensions de la familia VS Code, browser extensions en Chromium y Firefox, y — la que más importa acá — configs de servidores MCP.
La cuarta superficie: por qué los configs MCP son la parte interesante
Acá es donde dirigiría la atención de un lector senior. Bumblebee inventaría los archivos JSON locales que le dicen a los asistentes de IA a qué servicios externos tienen permitido llegar — mcp.json, .mcp.json, claude_desktop_config.json, ~/.claude.json, ~/.gemini/settings.json, y los equivalentes de Cline y Cursor. (Para que conste: los configs non-JSON como el config.toml de Codex o el YAML de Continue todavía no se parsean en la v0.1.)
Pensá en lo que esos configs efectivamente otorgan. Un servidor MCP le da a un agente de IA acceso a mail, calendarios, bases de datos, repositorios de código. Un connector envenenado deslizado en uno de esos archivos no solo compromete tu entorno — convierte a tu asistente de IA en algo que puede filtrar credenciales o correr comandos en tu nombre, sin hacer ruido. Y la mayoría de la gente que configura MCP no tiene una idea real de esa exposición. Casi nada en el ecosistema de seguridad actual audita estos archivos. Bumblebee sí, y ese es el gap que lo hace digno de tu atención en lugar de ser apenas otro scanner.
Cómo corre, en concreto
Tres perfiles, mapeados a tres situaciones reales:
- baseline — un barrido de inventario diario a través de package roots, toolchains, editor y browser extensions, y configs MCP. El que cableás a cron, launchd, o tu MDM.
- project — un barrido apuntado a directorios de desarrollo específicos como
~/codeo~/src, para auditar un entorno puntual. - deep — respuesta a incidentes. Barre roots provistos por el operador contra un exposure catalog. Construido para el momento “nos acabamos de enterar de un hit — ¿quién está expuesto?”.
El output es NDJSON, así que entra directo en lo que ya uses para inventario de flota. Requiere Go 1.25+, y los threat catalogs los aportás vos — lo que significa que la herramienta no está atada a la visión de Perplexity sobre qué cuenta como amenaza. macOS y Linux por ahora.
Los criterios de decisión
Un par de límites honestos, planteados como aquello que deberían informar más que como advertencias. La v0.1 es solo JSON-config del lado de MCP, así que si tu equipo se estandariza en Codex o Continue, esto todavía no cubre esa superficie — tenelo en cuenta al evaluar si encaja en tu stack hoy. Y es un colector de inventario, no una herramienta de remediación: te dice quién está expuesto, rápido, pero actuar sobre eso sigue siendo trabajo de tu pipeline. Para la mayoría de los equipos esa es la división de tareas correcta — la parte difícil en un incidente nunca fue el fix, fue saber dónde aplicarlo.
Lo que me resulta realmente notable es la postura. Una empresa conocida por un motor de búsqueda eligió publicar su tooling interno de seguridad de endpoints, como un binario que podés leer línea por línea, mientras los worms de npm siguen cayendo. Es una apuesta a que el problema de supply-chain ya está lo suficientemente feo como para que el tooling defensivo compartido le gane a la ventaja propietaria. Dado que los ataques a máquinas de desarrollo vienen subiendo fuerte este año, según los reportes — y que tu laptop, con sus credenciales vivas y su acceso permanente, es discutiblemente un blanco más jugoso que tus servidores de producción — es difícil discutirle a la apuesta.
¿Ya estás escaneando tus configs de MCP, o es un punto ciego en tu stack de seguridad?