Vet – un outil pour exécuter plus sûrement des scripts shell distants

 (getvet.sh)
10 points par GN⁺ 2025-07-02 | 1 commentaires | Partager sur WhatsApp
  • vet est un outil CLI qui transforme de manière plus sûre l’exécution de scripts d’installation distants via curl | bash en un processus « téléchargement → vérification → approbation avant exécution »
  • Il fournit des mécanismes de défense par étapes, comme la vérification des modifications du script (diff), un lint basé sur shellcheck (analyse statique) et une approbation manuelle (exécuter après vérification)
  • Avec une seule commande (vet https://example.com/install.sh), il est possible d’inspecter automatiquement avant exécution les risques potentiels, les altérations, les fautes de frappe et les vulnérabilités d’un script distant
  • Pour l’installation, il prend en charge à la fois l’approche « télécharger puis vérifier » et l’approche « curl | sh », et permet aussi de consulter directement le code d’installation de vet lui-même
  • C’est une solution fiable qui permet de prévenir les risques de sécurité dans les environnements de développement et d’exploitation tout en conservant automatisation et simplicité d’usage

Problème : l’exécution inconsidérée de scripts d’installation distants

  • De nombreux projets open source et outils recommandent une installation via des scripts distants comme curl -sSL https://example.com/install.sh | bash
  • Cette méthode comporte des risques de sécurité critiques, comme l’exécution de code malveillant ou l’exécution de fichiers partiels, en cas d’altération du script, de compromission du serveur ou d’erreur réseau

La solution de vet : une exécution interactive sécurisée

  • vet encapsule l’exécution de scripts distants dans un processus de sécurité en 4 étapes
    • 1. Fetch: téléchargement sûr du script distant dans un emplacement temporaire
    • 2. Diff & Review: affichage des changements (diff) par rapport aux exécutions précédentes, avec vérification visuelle directe du code nouveau ou modifié
    • 3. Lint: analyse statique automatique des bugs, vulnérabilités et motifs anormaux avec shellcheck (lorsqu’il est installé)
    • 4. Confirm: demande d’approbation finale à l’utilisateur (yes/no) avant l’exécution réelle
  • Commande unique : 
    vet https://example.com/install.sh

Méthode d’installation

Méthode recommandée et sûre (téléchargement → vérification → exécution)

Installation rapide (one-liner basé sur la confiance)

Caractéristiques et avantages de vet

  • Détection des changements (diff) : permet de voir les parties nouvellement modifiées par rapport aux scripts déjà exécutés
  • Lint automatique (intégration shellcheck) : diagnostic automatique des vulnérabilités, fautes de frappe et code suspect dans les scripts shell
  • Approbation explicite de l’exécution (Confirm) : contrôle direct de l’exécution réelle en un clic ou une saisie
  • Sauvegarde automatique des scripts et gestion de l’historique : permet de suivre en toute sécurité même les scripts d’installation fréquemment utilisés
  • Garantit également des installations et mises à jour sûres en interne

Conclusion

  • vet est une alternative plus sûre à curl | bash, nécessaire aussi bien pour les développeurs que pour les équipes d’exploitation, qui concilie automatisation de l’installation et sécurité
  • « Ne l’exécutez pas directement : vérifiez-le avec vet avant de l’exécuter ! »

À lire aussi

1 commentaires

 
GN⁺ 2025-07-02
Commentaire Hacker News
  • Dans 90 % des cas, on se demande comment la fiabilité d’un logiciel est réellement vérifiée quand on utilise un programme d’installation. Dans certains cas, le code est signé, mais bien souvent il provient du même serveur HTTPS sans vérification supplémentaire. Si le code est compilé, on se demande aussi si quelqu’un fait un diff. Exécuter aveuglément un installeur trouvé sur Internet n’est pas une bonne pratique, et il est rappelé que lorsqu’on installe depuis la distribution du système d’exploitation, il existe des mécanismes de vérification bien meilleurs. Cela dit, ces méthodes n’apportent pas forcément beaucoup plus de confiance
    • L’objectif de vet est centré sur la sécurité du script d’installation lui-même, en particulier pour éviter qu’il soit modifié afin d’ignorer la vérification de checksum ou de télécharger des binaires depuis des URL malveillantes. Il apporte une protection forte sur une partie du problème, mais ne couvre pas toute la chaîne
    • Un installeur ne s’exécute généralement qu’une seule fois, et on peut se demander dans quelle mesure il est utile d’afficher les changements par rapport à l’exécution précédente
    • Installation uniquement via des listes de paquets gérées par la communauté, fiables et signées cryptographiquement, avec un historique de sécurité solide. Le vrai problème n’est pas tant que la sécurité des scripts de téléchargement soit difficile, mais plutôt que certaines communautés, comme celle de macOS, aient accepté culturellement ce genre de méthode d’installation bricolée. Il faudrait des exigences plus fortes envers des plateformes de confiance. Faire passer un shell script récupéré sur Internet dans un linter ne me semble pas renforcer la sécurité
  • On se demande ce qui se passerait si quelqu’un continuait à insérer des pragmas # shellcheck disable= dans un script malveillant
    • Bonne remarque. C’est possible. vet ne repose pas uniquement sur ShellCheck, le diff est l’élément central. Même si le linter reste silencieux, le diff détectera l’insertion de code suspect comme # shellcheck disable=. Ce changement en lui-même est un signal d’alerte
  • Il y a une certaine ironie : 
    # Situation où l’on fait aveuglément confiance à un script distant :
curl -sSL https://example.com/install.sh | bash
    puis ensuite 
    curl -sL https://getvet.sh | sh
    pour l’exécuter
    • J’avais sans doute survolé ce passage. Le point essentiel de vet est précisément qu’il reconnaît cette ironie. Il encourage l’utilisateur à inspecter lui-même le script d’installation de vet. C’est justement son objectif. On peut consulter directement la source de install.sh
  • Je trouve que c’est une solution vraiment chouette. Je me pose souvent ce genre de questions, et je me les suis aussi posées pour uv, entre autres. Mais dans la plupart des cas, on fait un compromis parce que tout le monde fait confiance au gestionnaire de code
    • Je serais curieux de savoir ce que vous pensez de uv
  • Cette discussion fait réfléchir au prochain cap pour vet : la prise en charge des environnements privés. Vérifier des scripts publics, c’est utile, mais on a aussi besoin d’exécuter des scripts de déploiement depuis des dépôts GitHub internes ou des serveurs internes. Une demande de fonctionnalité a été ouverte pour ajouter l’authentification à vet. La feuille de route inclut la prise en charge de .netrc, une variable d’environnement VET_TOKEN, et plus tard l’intégration avec des gestionnaires de secrets comme HashiCorp Vault. Si cela vous intéresse, j’aimerais recueillir des avis sur la GitHub issue. Merci pour les retours
  • On se demande s’il serait possible de montrer sur la page ou dans le readme à quoi cela ressemble en fonctionnement, ou de proposer une vidéo de démonstration. Est-ce que cela s’ouvre dans un pager ou un éditeur, et comment les avertissements shellcheck sont-ils affichés ?
    • C’est juste. Le README explique le fonctionnement de vet, mais il ne montre pas très bien l’expérience réelle d’utilisation. Je vais ajouter un GIF de démonstration sur la page. Pour répondre à la question, le fichier s’ouvre par défaut dans un pager (less, ou un pager avec une mise en évidence plus agréable si bat est installé), et pas dans un éditeur afin d’éviter toute modification accidentelle. Si ShellCheck détecte un problème, il l’affiche immédiatement dans le terminal avec des couleurs. Ensuite, il demande explicitement s’il faut poursuivre la revue au format [y/N]. Exemple : 
      ==> 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]
      Merci pour l’excellente suggestion
  • C’est dommage que cela ne fonctionne pas automatiquement comme le modèle curl | bash. Sous Windows, quand un utilisateur essaie d’installer quelque chose, le système analyse automatiquement le fichier
  • L’idée est excellente. Le plus grand défi pour ce type d’outil de sécurité, c’est le caractère non déterministe des LLM et le risque de confidentialité lié à l’envoi du code vers une API tierce. C’est précisément pourquoi vet s’appuie sur ShellCheck. ShellCheck est un linter déterministe, fondé sur des règles, qui fonctionne entièrement hors ligne. À entrée identique, il fournit toujours une sortie fiable et identique. Pour une analyse plus intelligente, on peut imaginer qu’un jour vet s’oriente vers une IA rapide et locale. C’est une piste intéressante
  • Idée vraiment brillante. Comme fonctionnalité supplémentaire, il serait aussi intéressant d’envoyer le contenu du shell script à un LLM pour repérer les éléments suspects sur le plan de la sécurité
  • Salut HN, je suis le développeur de vet. Le modèle curl | bash m’a toujours mis mal à l’aise, et j’ai ressenti le besoin d’un outil capable d’afficher un diff quand le script change, d’exécuter shellcheck et de demander l’autorisation explicite de l’utilisateur. C’est pour cela que j’ai créé vet. L’installation suit le même principe. Je recommande vivement de lire le script d’installation. Tous les retours sont les bienvenus. Le dépôt est ici : https://github.com/vet-run/vet
    • Je suis content de voir que je ne suis pas le seul à réfléchir à ce problème. Cela me semble être un point d’exposition aux attaques sur les vulnérabilités. J’ai trouvé amusant que vous preniez nvm comme exemple (j’avais déjà signalé un problème similaire sur nvm par le passé). En revanche, le threat model reste un peu flou. Si un attaquant capable d’altérer SSL peut fournir un script malveillant, il est probablement assez avancé pour modifier aussi les binaires téléchargés par le vrai script. Même s’il est difficile pour tout le monde de gérer des vérifications à l’aide de hachages cryptographiques, cela reste au final la méthode la plus sûre. 1) récupérer l’entrée distante et la comparer à un hash versionné 2) exécuter dans un sandbox sans accès à Internet 3) bloquer la réception de la charge utile si le hash n’est pas vérifié
    • Je me demande pourquoi il faut « afficher un diff quand le script change et exécuter shellcheck ». Vous êtes-vous demandé à quoi sert vraiment shellcheck, et dans quel cas le diff est censé être utile ? « Demander une autorisation explicite avant exécution » ne sert à rien non plus si les changements se limitent à l’indentation. Un petit shell script peut se lire rapidement, mais les gros installeurs adoptent souvent, pour de très bonnes raisons, des styles de code difficiles à lire. Je ne vois pas bien quelle philosophie vet revendique. À vrai dire, la manière dont vet procède ressemble beaucoup aux schémas utilisés par des attaquants pour diffuser des malwares (par exemple, si on télécharge avec wget -qO- https://getvet.sh, le serveur renvoie en fait du text/html). Je recommanderais plutôt de récupérer directement install.sh. Puisque vous demandez des retours, voici une astuce bash dans l’esprit de « essayez plutôt comme ça » : 
      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
      Cette méthode demande une autorisation chaque fois que bash s’apprête à exécuter quelque chose. Pour les scripts longs, cela peut être fastidieux, donc on peut la personnaliser avec une liste blanche de commandes jugées sûres ou une option « remember ». Concernant sudo, un malware peut utiliser une commande apparemment anodine pour lancer d’abord sudo, mettre les identifiants en cache, puis réutiliser plus tard une commande sudo sans aucun avertissement. Il est plus sûr d’effacer le cache de session avec sudo -k avant d’exécuter un programme inconnu
    • J’apprécie la tentative d’identifier le problème et de construire une solution, mais ShellCheck n’a pas vocation à détecter virus et vulnérabilités, donc je doute fortement que l’orientation de vet soit réellement pertinente
    • L’idée en elle-même est bonne. vet sera utile aux développeurs quand le code source est bien visible et qu’ils peuvent le lire eux-mêmes. Personnellement, je ne sais pas encore si, à mon niveau actuel, je fais partie de cette minorité d’utilisateurs ou de la majorité des utilisateurs ordinaires qui ne peuvent pas vraiment en tirer parti pour l’instant