Vet – uma ferramenta para executar scripts de shell remotos com mais segurança

 (getvet.sh)
10 pontos por GN⁺ 2025-07-02 | 1 comentários | Compartilhar no WhatsApp
  • O vet é uma ferramenta de CLI que transforma a execução de scripts remotos de instalação no estilo curl | bash em um processo mais seguro de "baixar → revisar → aprovar a execução"
  • Oferece camadas de defesa por etapa, como verificação de mudanças no script (diff), lint com base em shellcheck (análise estática) e aprovação manual (executar após confirmação)
  • Com um único comando (vet https://example.com/install.sh), é possível fazer verificações automáticas de riscos potenciais, adulteração, erros de digitação e vulnerabilidades antes de executar scripts remotos
  • A própria instalação também oferece suporte tanto ao método de "baixar e revisar" quanto ao método curl | sh, e o código de instalação do próprio vet também pode ser verificado diretamente
  • É uma solução confiável que permite obter ao mesmo tempo prevenção de riscos de segurança em ambientes de desenvolvimento/operação e automação/conveniência

Problema: execução indiscriminada de scripts remotos de instalação

  • Muitos projetos open source e ferramentas orientam a instalação por meio de scripts remotos como curl -sSL https://example.com/install.sh | bash
  • Esse método envolve riscos críticos de segurança, como execução de código malicioso e execução de arquivos parciais, devido a adulteração do script, invasão do servidor, erro de rede etc.

A solução do vet: execução interativa segura

  • O vet encapsula a execução de scripts remotos no seguinte processo de segurança em 4 etapas
    • 1. Fetch: baixa com segurança o script remoto para um local temporário
    • 2. Diff & Review: compara com o histórico de execuções anteriores, mostra as mudanças (diff) e permite revisar visualmente o código novo/modificado
    • 3. Lint: faz análise estática automática com shellcheck (na instalação) para detectar bugs, vulnerabilidades e padrões anormais
    • 4. Confirm: antes da execução real, solicita ao usuário a aprovação final (yes/no)
  • Comando único: 
    vet https://example.com/install.sh

Como instalar

Método recomendado e seguro (baixar → revisar → executar)

Instalação rápida (one-liner baseado em confiança)

Recursos e vantagens do vet

  • Detecção de mudanças (diff): permite conferir o que mudou em relação a scripts executados anteriormente
  • Lint automático (integração com shellcheck): diagnostica automaticamente vulnerabilidades, erros de digitação e código suspeito em scripts shell
  • Aprovação explícita da execução (Confirm): controle direto da execução real com um clique/entrada
  • Armazenamento automático de scripts e gerenciamento de histórico: permite rastrear com segurança até scripts de instalação usados com frequência
  • Também garante instalação/atualização segura internamente

Conclusão

  • O vet é uma alternativa segura ao curl | bash necessária tanto para desenvolvedores quanto para operadores, tornando possível unir automação de instalação e segurança
  • "Não execute simplesmente: valide com o vet antes de executar!"

Leituras relacionadas

1 comentários

 
GN⁺ 2025-07-02
Comentários do Hacker News

  • Em 90% dos casos, fico me perguntando como as pessoas realmente verificam a confiabilidade do software ao usar instaladores. Em alguns casos, o código é assinado, mas em muitos outros ele vem do mesmo servidor HTTPS sem verificação adicional. Se o código vier compilado, também vale perguntar se alguém faz diff. Executar instaladores aleatórios da internet não é uma boa prática, e vale lembrar que, ao instalar pela distribuição do sistema operacional, geralmente existem mecanismos de verificação muito melhores. Ainda assim, esses métodos não ajudam tanto assim a aumentar a confiança

    • O objetivo do vet é focar na segurança do próprio script de instalação, com ênfase em impedir que o script seja alterado para pular a verificação de checksum ou baixar binários de URLs maliciosas. Ele oferece uma proteção forte em uma parte do problema, mas não cobre toda a cadeia
    • Instaladores normalmente são executados só uma vez, então fico em dúvida sobre o quanto é útil mostrar as mudanças em relação à execução anterior
    • Eu só instalo por listas de pacotes mantidas pela comunidade, assinadas criptograficamente e com bom histórico de segurança. Acho que o problema fundamental não é tanto que proteger scripts de download seja difícil, mas sim a cultura de algumas comunidades, como a do macOS, de aceitar esse tipo de instalação meio hacky. Precisamos exigir mais de plataformas confiáveis. Não acho que rodar lint em um shell script baixado da internet realmente melhore a segurança

  • Fico pensando no que acontece se alguém ficar inserindo pragmas # shellcheck disable= em um script malicioso

    • Boa observação. Isso pode acontecer. O vet não confia só no ShellCheck; o diff é a peça central. Mesmo que o linter fique em silêncio, o diff detecta a inserção de código preocupante como # shellcheck disable=. Essa mudança em si já é um sinal de alerta

  • Há uma certa ironia aqui:

    # confiando cegamente em um script remoto:
curl -sSL https://example.com/install.sh | bash

    e depois

    curl -sL https://getvet.sh | sh
    • Acho que passei por essa parte sem ler. O ponto central do vet é justamente reconhecer essa ironia. Ele recomenda que o usuário verifique diretamente o script de instalação do vet. Esse é exatamente o objetivo. Dá para ver o código-fonte do install.sh por conta própria

  • Acho uma solução muito legal. Já pensei nisso várias vezes, inclusive com o uv. Mas, na maioria dos casos, acaba sendo um compromisso prático porque todo mundo confia nos mantenedores do código

    • Fiquei curioso sobre o que você pensa do uv

  • Ao ver essa discussão, comecei a pensar em suporte a ambientes privados como próximo passo do vet. Verificar scripts públicos é ótimo, mas também surge a necessidade de executar scripts de deploy de um repositório interno no GitHub ou de um servidor interno. Por isso abri uma solicitação de recurso para adicionar autenticação ao vet. O roadmap inclui suporte a .netrc, variável de ambiente VET_TOKEN e, no futuro, integração com gerenciadores de segredos como o HashiCorp Vault. Se tiver interesse, adoraria ouvir opiniões na issue do GitHub. Obrigado pelo feedback

  • Será que daria para mostrar na página ou no readme como ele funciona na prática, ou um vídeo de demonstração? Fiquei curioso para saber se abre em pager ou editor, e como os avisos do ShellCheck são exibidos

    • Faz sentido. O README explica como o vet funciona, mas não mostra tão bem a experiência real de uso. Vou adicionar um GIF de demonstração à página. Para responder à pergunta: por padrão, ele abre o arquivo em um pager (less ou, se o bat estiver instalado, um pager com highlight mais agradável), e não em um editor, para evitar alterações acidentais. Se o ShellCheck detectar problemas, eles são mostrados imediatamente no terminal com cores. Depois ele pergunta explicitamente se você quer continuar a revisão, no formato [y/N]. Exemplo: 
      ==> 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]
      Obrigado pela boa sugestão

  • É uma pena que isso não funcione automaticamente como o padrão curl | bash. No Windows, há recursos que escaneiam arquivos automaticamente quando o usuário tenta instalá-los

  • A ideia é muito boa. Um dos maiores desafios nesse tipo de ferramenta de segurança é a não determinismo dos LLMs e o risco de privacidade de enviar código para APIs de terceiros. É exatamente por isso que o vet depende do ShellCheck. O ShellCheck é um linter determinístico, baseado em regras e que funciona totalmente offline. Para a mesma entrada, ele sempre fornece a mesma saída confiável. Para uma análise mais inteligente, acho que no futuro o caminho seria um AI rápida, rodando localmente dentro do vet. É uma boa questão para se pensar

  • Ideia realmente brilhante. Como recurso extra, também seria interessante enviar o conteúdo do shell script para um LLM para detectar partes suspeitas do ponto de vista de segurança

  • Oi HN, sou o desenvolvedor do vet. Sempre me senti desconfortável com o padrão curl | bash, e achei que precisava de uma ferramenta que mostrasse o diff quando o script muda, rodasse o shellcheck e pedisse autorização explícita do usuário. Foi por isso que criei o vet. A instalação segue o mesmo princípio. Recomendo fortemente ler o script de instalação. Feedback é bem-vindo. O repositório é https://github.com/vet-run/vet

    • Fico feliz em ver que não sou o único pensando nesse tipo de problema. Considero isso um ponto de exposição a ataques de vulnerabilidade. Achei divertido ver o nvm usado como exemplo (no passado, eu mesmo já levantei um problema parecido no nvm). Dito isso, o threat model ainda me parece um pouco pouco claro. Se um atacante capaz de adulterar SSL consegue entregar um script malicioso, então ele provavelmente também é sofisticado o bastante para adulterar os binários baixados pelo script legítimo. Embora seja difícil para todos gerenciar verificação com hashes criptográficos, no fim das contas esse continua sendo o método mais confiável. 1) buscar a entrada remota e comparar com hashes versionados no repositório 2) executar em um sandbox sem acesso à internet 3) bloquear o recebimento de payloads com hashes não verificados
    • Pergunta sobre o motivo de “mostrar o diff quando o script muda e rodar shellcheck”. Diz que não sabe qual é o papel do shellcheck aí, e pergunta se você já refletiu sobre isso e em que situação o diff de fato entraria em ação. “Pedir autorização explícita antes de executar” também não adianta se a mudança for só de indentação. Shell scripts pequenos até dá para ler rápido, mas instaladores grandes muitas vezes usam estilos de código difíceis por razões legítimas. Não sabe qual filosofia o vet está propondo. Na prática, acha que o modo como o vet opera se parece bastante com os padrões que atacantes usam para distribuir malware (por exemplo, ao baixar com wget -qO- https://getvet.sh, o servidor está retornando text/html). Em vez disso, prefere recomendar baixar diretamente o install.sh. Como resposta ao pedido de feedback, compartilha esta dica de bash de “faça assim”: 
      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
      Esse método pede autorização sempre que o bash vai executar alguma coisa. Em scripts longos isso pode ser incômodo, então dá para personalizar com uma whitelist de comandos considerados seguros ou com uma opção de “remember”. Em relação ao sudo, um malware pode primeiro executar sudo em um comando inocente para deixar as credenciais em cache e, depois, executar outro comando com sudo sem qualquer aviso. É mais seguro limpar o cache da sessão com sudo -k antes de rodar programas desconhecidos
    • Valorizo a tentativa de identificar o problema e criar uma solução, mas o ShellCheck não foi feito para detectar vírus ou vulnerabilidades, então não me parece que a direção do vet vá ser muito eficaz
    • A ideia em si é boa. O vet deve funcionar bem para desenvolvedores quando o código-fonte está visível e fácil de ler diretamente. No meu nível atual, porém, ainda não sei se isso me coloca mais no grupo da maioria dos usuários ou no de uma minoria