Veltron Onopen
Mira qué se ejecuta al abrir un repositorio.
Clonas algo, o un agente lo clona por ti, y lo abres. Antes de leer una línea, una tarea de VS Code puede dispararse, un hook de agente puede lanzar una shell, un servidor MCP puede descargar y ejecutar un paquete que ningún lockfile fija.
¿Si abro esto, qué se ejecuta en mi máquina?
Salida real de onopen sobre un repositorio de prueba.
Lo medimos
25.1% de los repositorios más populares de GitHub ejecutan algo antes de que leas una línea.
De los que traen configuración de un agente de IA, el 62.3%. Escaneamos 9,997 repositorios sin clonar ni ejecutar ninguno, y publicamos el programa y los datos.
Leer el estudioInstalación
Tres formas de tenerlo
Onopen 0.5.2 está publicado. No hay que compilar nada a mano, ni crear una cuenta, ni aceptar términos.
cargo install onopen --lockedCompila desde la fuente con las versiones exactas del lockfile.
cargo binstall onopenDescarga el binario del release en lugar de compilarlo. Linux, macOS Intel, macOS ARM y Windows.
uses: NULVEC/onopen@v0Los hallazgos llegan a la pestaña Security de GitHub, sobre el diff que alguien ya está leyendo.
Cada binario del release lleva checksums y attestation de procedencia de GitHub: se puede comprobar que salió del commit que dice y no de la máquina de nadie. Una herramienta cuyo argumento es que sepas qué vas a ejecutar no tiene por qué pedirte que te fíes.
El hueco
La configuración también ejecuta
Los escáneres de dependencias leen código y versiones. Una parte creciente de los ataques de cadena de suministro no vive ahí: vive en la configuración, que casi todas las herramientas tratan como texto inerte.
- VS Code, Cursor, Claude Code, Gemini CLI, npm, Composer y Bundler aceptan archivos de configuración que pueden llevar un comando de shell.
- Varios lo ejecutan al abrir la carpeta o al arrancar una sesión de agente, detrás de un aviso de confianza que casi nadie lee.
- La superficie de los agentes apareció hace meses y ningún escáner estaba apuntado a ella.
- La defensa que se recomienda hoy es revisar la configuración a mano. Eso no es una defensa.
Cobertura
Qué lee
Diez escáneres, cada uno sobre una familia de archivos. Ninguno ejecuta nada.
Tareas con runOn: folderOpen, incluidas las de un workspace multi-raíz, ajustes que le pasan un binario a una extensión e inyección de entorno en terminales.
Tareas que JetBrains lanza al abrir el proyecto, File Watchers que corren al cambiar un archivo, Lisp que Emacs evalúa al visitar uno, y el rc local de Vim.
Hooks de comando, comandos de entorno de Cursor y listas de permisos que quitan el aviso.
Servidores que se lanzan al iniciar la sesión, y los que bajan y ejecutan con npx o uvx sin lockfile.
Scripts de instalación, código propio de pnpm y Yarn que corre al arrancar, aprobaciones de build y dependencias traídas fuera del registro.
Archivos de setup que son código ejecutable, backends de build locales e imports que ocurren solos al arrancar el intérprete.
Build scripts, y los campos que sustituyen el compilador, el enlazador o el runner por algo del propio repositorio.
Hooks que se disparan al entrar en el directorio, y los shell hooks de un entorno de desarrollo de Nix.
initializeCommand, que corre en el anfitrión y no dentro del contenedor, más el resto del ciclo de vida.
core.hooksPath redirigido, hooks vivos en el clon, scripts esperando a que alguien los conecte y entradas locales de pre-commit.
Cómo se ordena
Tres niveles, y solo uno rompe la build
Se ejecuta al abrir, al iniciar sesión de agente o al instalar. Sin que hagas nada más. Es el único que devuelve código de salida 1.
Se ejecuta, pero después de un acto deliberado: instalar, depurar, commitear, construir el contenedor.
No se ejecuta solo, pero amplía la superficie o quita un aviso que habría mostrado algo.
Lo que no hace
No hace falta confiar en nosotros
Es una herramienta de seguridad que te pide correr un binario sobre tus repositorios. Esa desconfianza es sana, así que la respuesta no es pedir confianza sino quitarle motivo.
Nunca ejecuta lo que encuentra. Lee y analiza, nada más.
Nunca abre una conexión de red. Sin telemetría, sin consultas, sin actualizaciones automaticas.
Sin cuentas, sin servidor y sin plan de pago.
Código abierto desde el primer commit. Se puede leer entero.
Honestidad
Lo que no cubre, y por qué
Onopen reporta rutas de ejecución, no intenciones. Un postinstall que compila un módulo nativo y uno que se lleva tu .npmrc aparecen los dos: la herramienta te dice dónde mirar, no juzga lo que encuentra.
Tampoco reporta cada comando de cada sistema de build, y es una decisión, no un olvido. No inspecciona comandos de Gradle, CMake, Make o Docker, workflows de CI alojados, ni instrucciones en prosa como CLAUDE.md o AGENTS.md. Un Makefile ejecuta comandos porque para eso existe, así que reportarlos dispararía sobre casi todos los repositorios que escanee, y un escáner que se dispara en el caso corriente enseña a saltarse su salida. Con la prosa es peor: no hay forma fiable de distinguir un CLAUDE.md que dice ejecuta los tests de uno que dice otra cosa, sin entender el texto.
Corre uno ahora
Sobre cualquier repositorio que tengas a mano. Tarda menos que leer esta página.
Ver el código