Vet – ein Tool zum sichereren Ausführen entfernter Shell-Skripte

 (getvet.sh)
10 Punkte von GN⁺ 2025-07-02 | 1 Kommentare | Auf WhatsApp teilen
  • vet ist ein CLI-Tool, das die Ausführung entfernter Installationsskripte nach dem Muster curl | bash sicher in einen **„Herunterladen → Prüfen → Ausführung freigeben“*-Prozess umwandelt
  • Es bietet mehrstufige Schutzfunktionen wie das Prüfen von Skriptänderungen (diff), auf shellcheck basierende Lint-Prüfung (statische Analyse) und explizite Freigabe durch den Nutzer (nach Prüfung ausführen)
  • Mit einem einzigen Befehl (vet https://example.com/install.sh) lassen sich vor der Ausführung entfernter Skripte potenzielle Risiken, Manipulationen, Tippfehler und Schwachstellen automatisch prüfen
  • Auch die Installation selbst unterstützt sowohl den Modus „nach dem Herunterladen prüfen“ als auch curl | sh, und sogar der Installationscode von vet kann direkt eingesehen werden
  • Es ist eine verlässliche Lösung, die Sicherheitsrisiken in Entwicklungs- und Betriebsumgebungen verhindert und gleichzeitig Automatisierung sowie Komfort bietet

Problem: Unbedachtes Ausführen entfernter Installationsskripte

  • Viele Open-Source-Projekte und Tools empfehlen die Installation per entferntem Skript wie curl -sSL https://example.com/install.sh | bash
  • Dieser Ansatz birgt kritische Sicherheitsrisiken wie die Ausführung von Schadcode oder unvollständigen Dateien durch Skriptmanipulation, Server-Hacks oder Netzwerkfehler

Die Lösung von vet: sichere interaktive Ausführung

  • vet kapselt die Ausführung entfernter Skripte in den folgenden vierstufigen Sicherheitsprozess
    • 1. Fetch: Das entfernte Skript wird sicher an einen temporären Ort heruntergeladen
    • 2. Diff & Review: Änderungen (diff) werden im Vergleich zu früheren Ausführungen angezeigt, neuer oder geänderter Code kann visuell direkt geprüft werden
    • 3. Lint: shellcheck (bei Installation) führt automatisch eine statische Analyse auf Bugs, Schwachstellen und ungewöhnliche Muster durch
    • 4. Confirm: Vor der tatsächlichen Ausführung wird der Nutzer zur finalen Freigabe per yes/no aufgefordert
  • Einzelbefehl: 
    vet https://example.com/install.sh

Installation

Empfohlene sichere Methode (Herunterladen → prüfen → ausführen)

Schnelle Installation (vertrauensbasierter One-Liner)

Merkmale und Vorteile von vet

  • Änderungserkennung (diff): Unterschiede zum zuvor ausgeführten Skript lassen sich erkennen
  • Automatisches Linting (shellcheck-Integration): Schwachstellen, Tippfehler und verdächtiger Code in Shell-Skripten werden automatisch erkannt
  • Explizite Ausführungsfreigabe (Confirm): Die tatsächliche Ausführung lässt sich mit einem Klick/einer Eingabe direkt steuern
  • Automatisches Speichern und Verlaufspflege von Skripten: Auch häufig genutzte Installationsskripte lassen sich sicher nachverfolgen
  • Gewährleistet auch intern eine sichere Installation und Aktualisierung

Fazit

  • vet ist für Entwickler und Administratoren gleichermaßen eine sichere Alternative zu „curl | bash“, die sowohl Installationsautomatisierung als auch Sicherheit ermöglicht
  • „Nicht einfach ausführen – erst mit vet prüfen und dann starten!“

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-07-02
Hacker-News-Kommentare
  • In 90 % der Fälle frage ich mich, wie man die Vertrauenswürdigkeit von Software bei der Nutzung eines Installers tatsächlich verifiziert. In manchen Fällen ist der Code signiert, aber oft kommt derselbe Code ohne zusätzliche Prüfung vom gleichen HTTPS-Server. Falls der Code kompiliert ist, frage ich mich auch, ob dann ein Diff gemacht wird. Einfach blind Installer aus dem Internet auszuführen, ist keine gute Praxis, und wenn man stattdessen aus der Distribution des Betriebssystems installiert, gibt es in der Regel deutlich bessere Verifizierungsmechanismen. Allerdings helfen auch diese Methoden nicht besonders viel dabei, Vertrauen aufzubauen.
    • Der Zweck von vet ist auf die Sicherheit des Installationsskripts selbst fokussiert und insbesondere darauf, zu verhindern, dass das Skript so verändert wird, dass Checksum-Prüfungen übersprungen oder Binärdateien von bösartigen URLs heruntergeladen werden. In diesem Teil der Kette bietet es starken Schutz, aber es deckt nicht die gesamte Kette ab.
    • Installer werden im Allgemeinen nur einmal ausgeführt, daher frage ich mich, wie nützlich es wirklich ist, Änderungen gegenüber einer früheren Ausführung anzuzeigen.
    • Ich installiere nur über vertrauenswürdige, kryptografisch signierte und von der Community gepflegte Paketlisten und nutze Verfahren mit guter Sicherheitsgeschichte. Das Grundproblem ist meiner Meinung nach nicht so sehr, dass Download-Skripte schwer abzusichern sind, sondern dass bestimmte Communities, etwa rund um macOS, diese hackige Art der Installation kulturell akzeptiert haben. Von vertrauenswürdigen Plattformen sollte man mehr verlangen. Ich glaube nicht, dass die Sicherheit dadurch steigt, dass man ein aus dem Internet geladenes Shell-Skript einmal durch einen Linter jagt.
  • Ich frage mich, was passiert, wenn jemand in ein bösartiges Skript einfach immer wieder # shellcheck disable=-Pragmas einfügt.
    • Guter Punkt. Das ist möglich. vet verlässt sich nicht nur auf ShellCheck, der Diff ist entscheidend. Selbst wenn der Linter still bleibt, erkennt der Diff das Einfügen bedenklichen # shellcheck disable=-Codes. Diese Änderung selbst ist bereits ein Warnsignal.
  • Ich spüre eine gewisse Ironie: 
    # Situation, in der einem Remote-Skript blind vertraut wird:
curl -sSL https://example.com/install.sh | bash
    und dann als Nächstes 
    curl -sL https://getvet.sh | sh
    so auszuführen.
    • Den Teil habe ich wohl überlesen. Der Kern von vet ist, dass es sich genau dieser Ironie bewusst ist. Nutzer werden ausdrücklich ermutigt, das Installationsskript von vet selbst zu prüfen. Genau das ist das Ziel von vet. Man kann sich den Quelltext von install.sh direkt ansehen.
  • Ich halte das für eine wirklich coole Lösung. Ich habe darüber schon öfter nachgedacht und mich das auch bei uv und Ähnlichem gefragt. In den meisten Fällen nutzt man es aber pragmatisch, weil alle dem jeweiligen Code-Manager vertrauen.
    • Mich würde interessieren, was du zu uv denkst.
  • Diese Diskussion bringt mich dazu, als nächsten Schritt für vet Unterstützung für private Umgebungen zu erwägen. Öffentliche Skripte zu verifizieren ist gut, aber man muss auch Deployment-Skripte aus internen GitHub-Repos oder von internen Servern ausführen können. Deshalb habe ich ein Feature-Request für Authentifizierung in vet eröffnet. Unterstützung für .netrc, die Umgebungsvariable VET_TOKEN und später sogar die Anbindung an Secret-Manager wie HashiCorp Vault stehen auf der Roadmap. Wenn Interesse besteht, würde ich gern im GitHub-Issue Meinungen dazu hören. Danke für das Feedback.
  • Könnt ihr auf der Seite oder im README zeigen, wie das in der Praxis aussieht, etwa mit einer Demo oder einem Video? Öffnet es einen Pager oder einen Editor, und wie werden ShellCheck-Warnungen angezeigt?
    • Stimmt. Im README steht derzeit nur, wie vet funktioniert, aber die tatsächliche Nutzungserfahrung wird nicht gut vermittelt. Ich plane, auf der Seite ein Demo-GIF hinzuzufügen. Zur Beantwortung der Frage: Standardmäßig wird die Datei in einem Pager geöffnet (less oder, falls installiert, in einem optisch schöner hervorgehobenen Pager mit bat), nicht in einem Editor, um versehentliche Änderungen zu verhindern. Wenn ShellCheck Probleme erkennt, werden sie direkt farbig im Terminal ausgegeben. Danach wird man explizit gefragt, ob man die Prüfung trotz der Probleme fortsetzen will, im Format [y/N]. Beispiel: 
      ==> 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]
      Danke für den guten Vorschlag.
  • Schade ist, dass es nicht automatisch funktioniert wie das curl | bash-Muster. Unter Windows gibt es Funktionen, die Dateien beim Installieren automatisch scannen.
  • Die Idee ist hervorragend. Die größte Herausforderung bei Sicherheitswerkzeugen dieser Art sind die Nichtdeterminismus-Probleme von LLMs und das Datenschutzrisiko, wenn Code an APIs von Drittanbietern geschickt wird. Genau deshalb stützt sich vet auf ShellCheck. ShellCheck ist ein deterministischer, regelbasierter Linter, der vollständig offline arbeitet. Bei gleicher Eingabe liefert er immer dieselbe verlässliche Ausgabe. Für intelligentere Analysen bräuchte vet langfristig wohl eher schnelle, lokal laufende AI. Ein spannender Gedanke.
  • Wirklich geniale Idee. Als Zusatzfunktion wäre es auch interessant, den Inhalt des Shell-Skripts an ein LLM zu schicken, um sicherheitsverdächtige Stellen zu identifizieren.
  • Hi HN, ich bin der Entwickler von vet. Ich hatte mich beim curl | bash-Muster immer unwohl gefühlt und wollte ein Tool, das bei Änderungen im Skript einen Diff zeigt, ShellCheck ausführt und vor der Ausführung eine ausdrückliche Zustimmung des Nutzers einholt. Deshalb habe ich vet gebaut. Für die Installation gilt dasselbe Prinzip. Ich empfehle ausdrücklich, das Installationsskript zu lesen. Feedback ist willkommen. Das Repo ist https://github.com/vet-run/vet
    • Es freut mich, dass ich nicht der Einzige bin, der über dieses Problem nachdenkt. Ich halte das für einen Punkt, an dem man Angriffsflächen ausgesetzt ist. Ich fand es interessant, dass du nvm als Beispiel genannt hast (ich habe in der Vergangenheit schon einmal ein ähnliches Problem bei nvm angesprochen). Allerdings ist das Threat Model etwas unklar. Wenn ein SSL-Manipulationsangreifer in der Lage ist, ein bösartiges Skript auszuliefern, dann ist er wahrscheinlich auch weit genug, um die Binärdatei, die das echte Skript herunterlädt, bösartig zu ersetzen. Auch wenn es schwierig ist, dass alle die Verifikation über kryptografische Hashes pflegen, ist das letztlich die sicherste Methode. 1) Remote-Eingaben holen und mit einem committed Hash vergleichen 2) in einer Sandbox ohne Internet ausführen 3) den Empfang von Payloads mit nicht verifizierten Hashes blockieren.
    • Ich frage mich, warum du „einen Diff anzeigst und ShellCheck ausführst, wenn sich das Skript geändert hat“. Hast du dir überlegt, welche Rolle ShellCheck dabei überhaupt spielt und wann genau der Diff deiner Meinung nach wirksam wird? Auch „vor der Ausführung eine ausdrückliche Zustimmung einholen“ hilft nicht, wenn es am Ende nur um geänderte Einrückung geht. Kleine Shell-Skripte kann man schnell lesen, aber größere Installer verwenden aus legitimen Gründen oft schwer lesbare Codestile. Ich weiß nicht, auf welche Philosophie du dich bei vet berufst. Das Vorgehen von vet erinnert mich ehrlich gesagt an Muster, die auch Angreifer zum Verteilen von Malware nutzen (zum Beispiel liefert der Server bei wget -qO- https://getvet.sh text/html zurück). Ich würde eher empfehlen, install.sh direkt zu holen. Und als Feedback im Sinne von „probier es doch so“ hier ein Bash-Tipp: 
      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
      Diese Methode fragt jedes Mal nach Erlaubnis, wenn Bash etwas ausführen will. Bei langen Skripten kann das mühsam werden, daher könnte man das mit einer Whitelist für als sicher betrachtete Befehle oder einer „remember“-Option anpassen. In Bezug auf sudo gilt: Malware kann zunächst bei einem harmlos wirkenden Befehl sudo ausführen, die Zugangsdaten im Cache halten und später ohne weitere Warnung erneut sudo verwenden. Es ist sicherer, vor dem Ausführen unbekannter Programme mit sudo -k den Session-Cache zu leeren.
    • Ich würdige den Versuch, ein Problem zu erkennen und eine Lösung zu bauen, aber ShellCheck ist seinem eigentlichen Zweck nach kein Viren- oder Schwachstellen-Scanner, daher glaube ich nicht, dass die Ausrichtung von vet besonders tragfähig ist.
    • Die Idee an sich ist gut. vet dürfte für Entwickler nützlich sein, wenn der Quellcode gut sichtbar und direkt lesbar ist. Ich bin dafür selbst noch nicht versiert genug und weiß nicht, ob ich eher zur Mehrheit der Nutzer oder zu einer kleinen Minderheit gehöre.