Vet – una herramienta para ejecutar scripts de shell remotos de forma más segura

 (getvet.sh)
10 puntos por GN⁺ 2025-07-02 | 1 comentarios | Compartir por WhatsApp
  • vet es una herramienta CLI que convierte la ejecución de scripts remotos de instalación con curl | bash en un proceso más seguro de "descargar → revisar → aprobar la ejecución"
  • Ofrece defensas por etapas, como revisión de cambios en el script (diff), lint basado en shellcheck (análisis estático) y aprobación manual (ejecutar tras confirmar)
  • Con un solo comando (vet https://example.com/install.sh), permite revisar automáticamente riesgos potenciales, manipulación, errores tipográficos y vulnerabilidades antes de ejecutar un script remoto
  • La instalación también admite tanto el método de "descargar y luego revisar" como el de curl | sh, y es posible inspeccionar directamente el código de instalación del propio vet
  • Es una solución confiable que permite prevenir riesgos de seguridad en entornos de desarrollo y operación sin perder automatización ni comodidad

Problema: ejecución indiscriminada de scripts remotos de instalación

  • Muchos proyectos y herramientas de código abierto recomiendan instalarse con scripts remotos como curl -sSL https://example.com/install.sh | bash
  • Este método conlleva riesgos de seguridad críticos, como ejecución de código malicioso o ejecución de archivos parciales, debido a manipulación del script, hackeo del servidor o errores de red

La solución de vet: ejecución interactiva segura

  • vet envuelve la ejecución de scripts remotos en el siguiente proceso de seguridad de 4 pasos
    • 1. Fetch: descarga de forma segura el script remoto en una ubicación temporal
    • 2. Diff & Review: muestra los cambios (diff) comparados con ejecuciones previas para revisar visualmente el código nuevo o modificado
    • 3. Lint: realiza análisis estático automático con shellcheck (si está instalado) para detectar bugs, vulnerabilidades y patrones anómalos
    • 4. Confirm: antes de la ejecución real, solicita al usuario la aprobación final mediante una respuesta yes/no
  • Comando único: 
    vet https://example.com/install.sh

Cómo instalarlo

Método recomendado y seguro (descargar → revisar → ejecutar)

Instalación rápida (one-liner basado en confianza)

Características y ventajas de vet

  • Detección de cambios (diff): permite ver qué partes cambiaron frente a un script ejecutado anteriormente
  • Lint automático (integración con shellcheck): diagnostica automáticamente vulnerabilidades, errores tipográficos y código sospechoso en scripts de shell
  • Aprobación explícita de ejecución (Confirm): control directo de la ejecución real con un clic o una confirmación manual
  • Guardado automático de scripts y gestión de historial: permite rastrear de forma segura incluso scripts de instalación usados con frecuencia
  • También garantiza instalaciones y actualizaciones seguras internamente

Conclusión

  • vet es una alternativa segura a curl | bash que necesitan tanto desarrolladores como operadores, y hace posible combinar automatización de instalación y seguridad
  • "¡No lo ejecutes sin más; valídalo con vet antes de ejecutarlo!"

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-07-02
Comentarios de Hacker News
  • En el 90% de los casos, me pregunto cómo se verifica realmente la confiabilidad del software cuando se usa un instalador. En algunos casos el código está firmado, pero muchas veces el código se descarga desde el mismo servidor HTTPS sin validación adicional. Si el código está compilado, también me pregunto si la gente hace diff. Ejecutar instaladores tomados de internet a ciegas no es una buena práctica, y vale la pena mencionar que, si se instala desde la distribución del sistema operativo, normalmente existen mecanismos de verificación mucho mejores. Aun así, estos métodos no ayudan tanto a aumentar la confianza.
    • El objetivo de vet está enfocado en la seguridad del script de instalación en sí, y se centra en evitar que el script sea modificado para saltarse la verificación de checksums o para descargar binarios desde URLs maliciosas. En ese aspecto ofrece una protección fuerte, pero no cubre toda la cadena.
    • Los instaladores normalmente se ejecutan una sola vez, así que me pregunto qué tan útil es mostrar los cambios respecto a ejecuciones anteriores.
    • Solo instalo a través de listas de paquetes mantenidas por la comunidad, confiables y firmadas criptográficamente, usando métodos con un sólido historial de seguridad. Creo que el problema de fondo no es tanto que sea difícil asegurar los scripts de descarga, sino la cultura en ciertas comunidades, como la de macOS, de aceptar este tipo de instalación medio hacky. Hace falta exigir más a las plataformas confiables. No creo que correr un linter sobre un shell script bajado de internet mejore realmente la seguridad.
  • Me pregunto qué pasaría si alguien siguiera insertando pragmas # shellcheck disable= en un script malicioso.
    • Buen punto. Sí, eso podría hacerse. vet no confía solo en ShellCheck; la clave es el diff. Aunque el linter no diga nada, el diff detecta la inserción de código sospechoso como # shellcheck disable=. Ese cambio en sí ya es una señal de alerta.
  • Se siente irónico: 
    # Confiar ciegamente en un script remoto:
curl -sSL https://example.com/install.sh | bash
    y luego ejecutar 
    curl -sL https://getvet.sh | sh
    de esta manera.
    • Creo que pasé por alto esa parte sin leerla. Lo importante de vet es que reconoce esa ironía. Recomienda que el usuario revise directamente el script de instalación de vet. Ese es justamente el objetivo de vet. Se puede ver el código fuente de install.sh directamente.
  • Me parece una solución realmente genial. He pensado en este problema varias veces, y también me lo pregunté con uv y otros casos. Pero en la mayoría de los casos uno termina aceptándolo por compromiso, porque todos confían en los mantenedores del código.
    • Me da curiosidad saber qué opinas sobre uv.
  • Esta discusión me hizo pensar en el siguiente paso para vet: soporte para entornos privados. Está bien verificar scripts públicos, pero también hace falta ejecutar scripts de despliegue desde repos internos de GitHub o servidores internos. Por eso abrí una solicitud de funcionalidad para agregar autenticación a vet. El roadmap incluye soporte para .netrc, la variable de entorno VET_TOKEN y, más adelante, integración con gestores de secretos como HashiCorp Vault. Si les interesa, me gustaría escuchar opiniones en el issue de GitHub. Gracias por el feedback.
  • Me pregunto si en la página o en el readme podrían mostrar cómo funciona en la práctica o incluir un video de demostración. Pregunto si abre en un pager o en un editor, y cómo se muestran las advertencias de shellcheck.
    • Totalmente cierto. El README explica cómo funciona vet, pero no muestra muy bien la experiencia real de uso. Voy a agregar un GIF de demostración en la página. Para responder: por defecto abre el archivo en un pager (less, o un pager con mejor resaltado si bat está instalado), y no en un editor para evitar modificaciones accidentales. Si ShellCheck detecta un problema, lo muestra directamente en la terminal con colores. Después pregunta explícitamente si quieres continuar con la revisión en formato [y/N]. Ejemplo: 
      ==> Running ShellCheck analysis...

In /tmp/tmp.XXXXXX line 7:
echo "Processing file: $filename"
           ^-- SC2086: Double quote to prevent globbing and word splitting.

==> WARNING: ShellCheck found potential issues.
[?] Continue with review despite issues? [y/N]
      Gracias por la buena sugerencia.
  • Es una lástima que no funcione de forma automática como el patrón curl | bash. En Windows hay funciones que escanean automáticamente los archivos cuando el usuario intenta instalarlos.
  • La idea es muy buena. El mayor reto para herramientas de seguridad como esta es la no determinación de los LLM y el riesgo de privacidad de que el código se envíe a APIs de terceros. Esa es precisamente la razón por la que vet depende de ShellCheck. ShellCheck es un linter determinista, basado en reglas y completamente offline. Con la misma entrada siempre da una salida confiable. Para un análisis más inteligente, creo que eventualmente vet necesitará ir en la dirección de una IA rápida y local. Es un buen tema para pensar.
  • Una idea realmente ingeniosa. Como función adicional, también sería interesante pasar el contenido del shell script a un LLM para detectar partes sospechosas desde el punto de vista de seguridad.
  • Hola HN, soy el desarrollador de vet. Siempre me incomodó el patrón curl | bash, y sentía que hacía falta una herramienta que mostrara el diff cuando cambiara el script, corriera shellcheck y pidiera autorización explícita al usuario. Por eso hice vet. La instalación sigue el mismo principio. Les recomiendo de verdad leer el script de instalación. Feedback bienvenido. El repo está en https://github.com/vet-run/vet.
    • Me alegra saber que no soy la única persona que piensa en este problema. Creo que es un punto expuesto a ataques por vulnerabilidades. Me dio risa ver que usaron nvm como ejemplo (en el pasado incluso planteé un problema parecido en nvm). Aun así, el threat model es algo poco claro. Si un atacante capaz de manipular SSL puede servir un script malicioso, entonces probablemente también sea lo bastante sofisticado como para alterar maliciosamente los binarios que descarga el script legítimo. Aunque sea difícil que todo el mundo gestione verificaciones con hashes criptográficos, al final sigue siendo el método más seguro. 1) obtener la entrada remota y compararla con hashes versionados en commits 2) ejecutar en un sandbox sin acceso a internet 3) bloquear la recepción del payload si el hash no está verificado.
    • Pregunto por qué “mostrar el diff cuando el script cambia y correr shellcheck”. Me pregunto si has pensado realmente cuál es el papel de shellcheck y en qué casos creías que el diff iba a funcionar. “Pedir autorización explícita antes de ejecutar” tampoco sirve si el cambio solo modifica la indentación. Un shell script pequeño se puede leer rápido, pero los instaladores grandes suelen tener estilos de código difíciles de seguir por razones legítimas. No entiendo qué filosofía dice seguir vet. De hecho, creo que lo que hace vet se parece bastante al patrón que usan los atacantes para distribuir malware (por ejemplo, si bajas con wget -qO- https://getvet.sh, el servidor está devolviendo text/html). Más bien recomendaría traer directamente install.sh. Como respuesta al pedido de feedback, comparto este tip de bash: 
      check () {
  echo "> $BASH_COMMAND" >&2
  echo -n "Allow? (yes/no) " >&2
  select c in yes no
  do
    if [ "$c" = "yes" ]
    then break
    elif [ "$c" = "no" ]
    then return 1
    fi
  done
}

shopt -s extdebug
trap check DEBUG
      Este método pide autorización cada vez que bash intenta ejecutar algo. Puede ser molesto con scripts largos, así que se podría personalizar con una whitelist de comandos considerados seguros o con una opción de “remember”. En cuanto a sudo, el malware puede primero ejecutar sudo en un comando inocuo para dejar las credenciales cacheadas y luego volver a ejecutar sudo más adelante sin ninguna advertencia. Es más seguro limpiar la caché de sesión con sudo -k antes de ejecutar programas desconocidos.
    • Valoro el intento de identificar un problema y construir una solución, pero shellcheck no fue pensado para análisis de virus o vulnerabilidades, así que no creo que la dirección de vet sea muy válida.
    • La idea en sí es buena. vet puede ser útil cuando el código fuente es visible y el desarrollador puede leerlo directamente. Pero todavía no sé si yo, con mi nivel actual, entro más en el grupo de desarrolladores o en el de la mayoría de usuarios.