Vet – リモートシェルスクリプトをより安全に実行するツール

 (getvet.sh)
10 ポイント 投稿者 GN⁺ 2025-07-02 | 1件のコメント | WhatsAppで共有
  • vetは curl | bash 方式のリモートインストールスクリプト実行を 「ダウンロード→レビュー→実行承認」プロセスへ安全に変換するCLIツール
  • スクリプト変更履歴のdiff確認、shellcheckベースのlint（静的解析）、手動承認（確認後に実行）など、段階的な防御機能を提供
  • 単一コマンド（vet https://example.com/install.sh）で、リモートスクリプト実行前に 潜在的なリスク・改ざん・タイプミス・脆弱性を自動点検可能
  • インストール自体も「ダウンロード後にレビュー」方式と「curl | sh」方式の両方に対応しており、vet自体のインストールコードも直接確認可能
  • 開発/運用環境におけるセキュリティリスクの予防と自動化/利便性を同時に確保できる信頼性の高いソリューション

問題点: 無分別なリモートインストールスクリプト実行

  • 多くのオープンソースやツールが、curl -sSL https://example.com/install.sh | bash のようなリモートスクリプトによるインストール方法を案内している
  • この方式には、スクリプト改ざん、サーバーハッキング、ネットワーク障害などによって 悪意あるコードの実行や不完全なファイル実行などの致命的なセキュリティリスクが存在する

vetのソリューション: 安全な対話型実行

  • vetはリモートスクリプト実行を、以下の 4段階セキュリティプロセス でラップする
    • 1. Fetch: リモートスクリプトを一時的な場所へ安全にダウンロード
    • 2. Diff & Review: 過去の実行履歴と比較して変更点（diff）を表示し、新規/変更コードを目視で直接レビュー
    • 3. Lint: shellcheck（インストール時）でバグ/脆弱性/異常パターンを自動静的解析
    • 4. Confirm: 実際の実行前にユーザーへ最終承認（yes/no）の入力を要求
  • 単一コマンド: 
    vet https://example.com/install.sh

インストール方法

安全な推奨方式（ダウンロード → レビュー → 実行）

クイックインストール（信頼ベースのワンライナー）

vetの特徴と利点

  • 変更検知（diff）: 以前に実行したスクリプトと比較して、新しく変わった部分を確認できる
  • 自動lint（shellcheck連携）: シェルスクリプトの脆弱性・タイプミス・疑わしいコードを自動診断
  • 明示的な実行承認（Confirm）: 1回のクリック/入力で実際の実行を直接コントロール
  • スクリプト自動保存・履歴管理: よく使うインストールスクリプトも安全に追跡可能
  • 内部的に安全なインストール/アップデートも保証

結論

  • vetは 開発者・運用担当者の双方に必要な「curl | bash」の安全な代替手段であり、インストール自動化とセキュリティの両立を実現する
  • 「そのまま実行せず、vetで検証してから実行しましょう！」

関連記事

1件のコメント

 
GN⁺ 2025-07-02
Hacker Newsのコメント
  • 90%のケースで、インストーラを使う際にソフトウェアの信頼性を実際にどう検証しているのか気になる。コードに署名されている場合もあるが、多くの場合は追加の検証なしに同じHTTPSサーバーからコードが降ってくるだけ。コードがコンパイル済みなら diff を取るのかも気になる。インターネット上のインストーラを無条件に実行するのはよいやり方ではなく、OSディストリビューション経由でインストールするなら、はるかにましな検証の仕組みが用意されている。こうした方法も、信頼を大きく高める助けにはあまりならない
    • vet の目的はインストールスクリプト自体の安全性に焦点を当てることで、インストールスクリプトがチェックサム検証を飛ばしたり、悪意あるURLからバイナリをダウンロードするよう改変されたりするのを防ぐことに重点を置いている。ある一部分では強い防御になるが、チェーン全体を担うものではない
    • インストーラはたいてい一度しか実行されないので、前回実行時からの変更点を見せることがどれほど有用なのか疑問
    • 信頼できる暗号学的署名付きのコミュニティ管理パッケージリスト経由でのみインストールし、実績のある方式を使う。根本的な問題はダウンロードスクリプトの安全確保が難しいことというより、macOS など一部コミュニティでこうしたハッキーなインストール方法を受け入れる文化だと思う。信頼できるプラットフォームにもっと強い要求が必要。インターネットから拾ったシェルスクリプトに Lint をかけても、セキュリティが強化されるとは思わない
  • 誰かが悪意あるスクリプトに # shellcheck disable= プラグマを延々と差し込んだらどうなるのか気になる
    • いい指摘。実際そうできる。vet は ShellCheck だけに頼っておらず、核心は diff にある。linter が黙っていても、diff によって問題のある # shellcheck disable= コードの挿入を検出できる。その変更自体が警告サインになる
  • アイロニーを感じる: 
    # リモートスクリプトを盲信する状況:
curl -sSL https://example.com/install.sh | bash
    次に 
    curl -sL https://getvet.sh | sh
    と実行する
    • そこを読み飛ばしていたようだ。vet の核心は、そのアイロニー自体を認識している点にある。ユーザーには vet のインストールスクリプトを自分で確認するよう勧めている。まさにそれが vet の目標。install.sh のソースは直接見られる
  • 本当にすばらしい解決策だと思う。こういうことはよく気になっていたし、uv でも同じ点が気になっていた。ただ大半の場合、コード管理者をみんな信頼しているので、妥協して使っている
    • uv についてどう考えているのか気になる
  • この議論を見て、vet の次のステップとしてプライベート環境のサポートを考えるようになった。公開スクリプトの検証もよいが、社内 GitHub repo や内部サーバーから配布スクリプトを実行する需要もある。そこで vet に認証機能を追加する機能要望をオープンした。.netrc サポート、VET_TOKEN 環境変数、将来的には HashiCorp Vault のようなシークレットマネージャとの連携までロードマップに入れている。興味があれば GitHub issue で意見を聞かせてほしい。フィードバックありがとう
  • ページや readme に、実際に動いている様子やデモ動画を載せられないか気になる。pager や editor で開くのか、shellcheck の警告はどんなふうに見えるのか知りたい
    • その通り。README には vet の仕組みは書いてあるが、実際の使用感はうまく伝えられていない。ページにデモ GIF を追加する予定。質問に答えると、デフォルトでは pager（less、または bat が入っていればより見やすいハイライト付き pager）でファイルを開き、誤って編集しないよう editor では開かない。ShellCheck が問題を検出すると、端末にカラーでその場で表示する。そしてレビューを続けるかどうかを [y/N] 形式で直接たずねる。例: 
      ==> 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]
      いい提案をありがとう
  • curl | bash パターンのように自動では動かない点が惜しい。Windows には、ユーザーがインストールしようとすると自動でファイルをスキャンしてくれる機能がある
  • アイデアはとてもよい。この種のセキュリティツールで最大の課題は、LLM の非決定性と、コードがサードパーティ API に送られることによるプライバシーリスクだ。vet が ShellCheck に依存しているのはそのため。ShellCheck は決定論的で、ルールベースで、完全にオフラインで動く linter。同じ入力には常に同じ信頼できる出力を返す。より賢い分析のためには、将来的に vet には高速でローカル実行できる AI が必要になる方向だと思う。よい論点だ
  • 本当に気の利いたアイデアだ。追加機能として、シェルスクリプトの内容を LLM に渡してセキュリティ上疑わしい部分を見つけるのも面白い方法だと思う
  • Hi HN, vet の開発者です。ずっと curl | bash パターンに不安を感じていて、スクリプトが変更されたときに diff を見せ、shellcheck を走らせ、ユーザーの明示的な許可を求めるツールが必要だと感じた。そこで vet を作った。インストールも同じ原則を適用している。インストールスクリプトはぜひ読んでほしい。フィードバック歓迎。repo は https://github.com/vet-run/vet
    • こういう問題を気にしているのが自分だけではなくてうれしい。脆弱性攻撃にさらされるポイントだと思う。nvm を例に出していたのも面白かった（以前に nvm でも似た問題 を提起したことがある）。ただ、threat model がやや不明確。SSL 改ざん攻撃者が悪意あるスクリプトを配るほどの能力を持つなら、本物のスクリプトがダウンロードするバイナリも悪意あるものに差し替えられる程度には高度だと思う。暗号学的ハッシュによる検証をみんなで管理するのは難しいとしても、最終的にはそれが最も確実な方法。1) リモート入力を取得してコミット済みハッシュと比較 2) インターネット遮断済みサンドボックスで実行 3) 未検証ハッシュでのペイロード受信を遮断
    • 「スクリプトが変わったときに diff を見せて shellcheck を走らせる」理由は何なのか知りたい。shellcheck の役割をどう考えているのか、いつ diff が機能すると想定していたのかも気になる。「実行前に明示的な許可を求める」も、単なるインデント変更にすぎなければ意味がない。短いシェルスクリプトならすぐ読めるが、大きなインストーラは正当な理由で難解なコードスタイルを使っていることも多い。vet がどんな哲学を語っているのかよくわからない。vet のやり方は、実際には攻撃者がマルウェアを配るときのパターンにかなり似ていると思う（例: wget -qO- https://getvet.sh で落とすと、サーバーは text/html を返している）。むしろ install.sh を直接取ることを勧めたい。フィードバックへの返答としては、「こういうふうにやってみては」という 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
      この方式では、bash が何かを実行しようとするたびに許可を求める。長いスクリプトでは煩雑になりうるので、安全だと思うコマンドをホワイトリスト化したり、"remember" オプションでカスタムしたりできる。sudo に関しては、マルウェアは無害そうなコマンドで先に sudo を実行して認証情報をキャッシュさせ、後から何の警告もなく再び sudo コマンドを実行する手口を使える。sudo -k でセッションキャッシュを消してから、未知のプログラムを実行するのが安全
    • 問題を見つけて解決策を作ろうとする試みは評価するが、ShellCheck 本来の役割はウイルスや脆弱性の検査ではないので、vet の方向性はあまり有効ではない気がする
    • アイデア自体はよい。vet は、開発者にとってソースコードが見やすく、直接読めるときに有用に機能するだろう。まだ自分の実力では難しく、多数派のユーザー側なのか少数派のユーザー側なのか自分でもわからないという意見だ