Homebrew 6.0.0公開｜サードパーティtap信頼確認でセキュリティ強化、Linuxユーザーの対応

リナックスマスター.JPの宮崎智広です。
いつもありがとうございます。

「LinuxサーバーにHomebrew（Linuxbrew）を入れているが、6.0でいきなりインストールが止まった」
「サードパーティのtapを使ったスクリプトやCIが、ある日突然エラーで落ちるようになった」

2026年6月11日、Homebrewのメジャーアップデート「Homebrew 6.0.0」が公開されました。今回の目玉はtap trust（タップ信頼確認）というセキュリティ機構です。これは「公式以外のtapは、明示的に信頼するまでコードを実行しない」という、これまでのHomebrewの前提を大きく変える破壊的変更です。

私自身、20年以上Linuxサーバーを現場で触ってきましたが、パッケージマネージャの「信頼モデル」がここまで明確に変わるのは珍しいことです。macOSの話題として語られがちなHomebrewですが、LinuxでもLinuxbrewとして広く使われており、CIやデプロイ自動化に組み込んでいる現場ほど今回の変更の影響を受けます。

この記事では、Homebrew 6.0.0の変更点を一次情報で確認したうえで、LinuxでHomebrewを使う人が「何を確認し、どう対応すべきか」を、現役のLinuxサーバー管理者向けに実務手順として整理します。

Homebrew 6.0.0公開の事実を一次情報で確認する

まず、噂や又聞きではなく公式の一次情報で事実を押さえます。

Homebrew公式ブログ（brew.sh）のリリースノートによると、Homebrew 6.0.0は2026年6月11日に公開されました。5.1.0以降の主要な変更として、公式は次の点を挙げています。

・tap trust（タップ信頼確認）という新しいセキュリティ機構
・より高速・小型になった新しい内部JSON API（デフォルト化）
・Linuxでのサンドボックス（Bubblewrap）対応
・ユーザーアンケートを反映したデフォルト設定の改善
・brew bundleの多数の改善
・macOS 27（Golden Gate）への初期対応

このうち、運用への影響がもっとも大きいのがtap trustです。これは「サードパーティのtap（およびtap名で修飾されたformula・cask）は、そのコードが評価・実行される前に、ユーザーが明示的に信頼しなければならない」という仕組みです。公式tapと組み込みコマンドはデフォルトで信頼されているため、普段のbrew install wgetのような基本操作には影響しません。影響を受けるのは、第三者が公開したtapを使っているケースです。

バージョン・公開日はいずれもHomebrew公式リリースノート（brew.sh/2026/06/11/homebrew-6.0.0/）および公式ドキュメント（docs.brew.sh/Tap-Trust）で確認した一次情報です。

tap trustとは何か。なぜセキュリティ強化になるのか

「tapを信頼する」と言われても、Homebrewのtapの実体を知らないとピンと来ないかもしれません。ここがtap trust理解の核心です。

Homebrewのtapは、検証済みのメタデータを配信する「パッケージレジストリ」ではありません。実体は、Rubyファイルが入った単なるGitリポジトリです。そして、tap内のformula・cask・外部コマンドは、Homebrewがそれを読み込んだ時点で呼び出したユーザーのフル権限で実行されます。

ここに大きなリスクがあります。悪意のあるtap、あるいは乗っ取られた（侵害された）tapをbrew tapで追加してしまうと、formulaを評価しただけで任意のRubyコードがユーザー権限で動いてしまうのです。サーバー管理者なら、これが何を意味するかすぐ分かるはずです。実質的に、信頼できない第三者のシェルスクリプトを、確認なしに自分の権限で実行しているのと変わりません。

tap trustは、この構造的なリスクを下げるための仕組みです。公式以外のtapは「明示的に信頼する」という一手間を踏まない限り、コードを読み込みも実行もしません。これにより、間違ったtap名のタイプミスや、知らないうちに侵害されたtapから、いきなりコードが走る事故を防ぎます。

公式ドキュメントによると、未信頼のtapはtap trust要求時にはロードされません（フルネームのformula・cask識別子で明示的にインストールする場合を除く）。「黙って読み込んで実行する」から「明示的に許可したものだけ実行する」への転換であり、セキュリティの考え方として正しい方向です。Linux側ではこれに加えて、build・test・postinstallの各フェーズがBubblewrapによるサンドボックス内で実行されるようになりました。macOSが長年持っていた分離が、ようやくLinuxにも入ったかたちです。

LinuxでのHomebrew（Linuxbrew）の位置づけ

ここで、LinuxでHomebrewを使う意味を改めて整理しておきます。今回の変更が「自分に関係あるか」を判断する前提になるからです。

HomebrewはもともとmacOS向けに生まれましたが、現在はLinuxでも公式にサポートされており、かつては「Linuxbrew」と呼ばれていました。Linuxサーバーでの典型的な使いどころは次のようなものです。

・新しめのCLIツールを、ディストリのリポジトリより新しいバージョンで入れたいとき（古いLTSのaptパッケージが古すぎる場合など）
・root権限なしで、ユーザーのホーム配下にツールを入れたいとき（共用サーバーや権限が限られた環境）
・macOSの開発環境とLinuxサーバーでツールチェーンを揃えたいとき

便利な反面、Linux管理者の視点では注意点もあります。Homebrewはディストリの公式パッケージ管理（apt・dnf）とは別系統です。セキュリティ更新の流れもディストリのものとは独立しているため、「aptで管理しているつもりが、brewで入れたツールだけ古いまま残る」といった死角が生まれやすい。今回のtap trustは、この「別系統で動く第三者コード」のリスクに正面から手を入れた変更だと捉えると分かりやすいです。

Homebrewそのものの基礎や、Linuxでのパッケージ管理の考え方をきちんと押さえておきたい方には、手元に1冊リファレンスを置いておくと、こうした変更が起きたときの理解が早くなります。

Homebrew 6.0.0でやるべき更新・対応手順

では、LinuxでHomebrewを使っている人が具体的に何をすべきかを順に整理します。

1. 現在のバージョンを確認する

まず自分の環境がどのバージョンかを確認します。

$ brew --version
Homebrew 6.0.0

6.0.0以降になっていれば、tap trustの対象です。まだ古いバージョンなら、更新のタイミングで挙動が変わる点を意識しておきます。

2. 使っているサードパーティtapを棚卸しする

自分がどのtapを追加しているかを確認します。

$ brew tap
homebrew/cask
your-org/internal
some-author/tools

ここでhomebrew/で始まる公式tap以外（上の例ではyour-org/internalやsome-author/tools）が、tap trustで明示的な信頼が必要になる対象です。このリストを見て「自分が意図して追加したtapか」を一つずつ確認すること自体が、よいセキュリティ点検になります。身に覚えのないtapがあれば、信頼する前にリポジトリの中身を確認しましょう。

3. 信頼するtapを明示的に登録する

中身を確認し、信頼すると判断したtapは、明示的に信頼を登録します。公式ドキュメントのコマンド構文は次のとおりです。

# tap全体を信頼する
$ brew trust user/repo

# formula単体だけを信頼する
$ brew trust --formula user/repo/formula

# cask単体だけを信頼する
$ brew trust --cask user/repo/cask

# 信頼済みの一覧を確認する
$ brew trust

最小権限の考え方からすると、tap全体を丸ごと信頼するより、実際に使うformulaやcaskだけを--formula／--caskで個別に信頼するほうが安全です。信頼を取り消したいときはbrew untrust user/repoを使います。

4. フルネーム指定でインストールする方法

あらかじめtapを信頼登録しなくても、フルネーム（user/repo/formula）で指定してインストールすると、その対象だけが自動的に信頼されます。

$ brew install user/repo/formula

単発で1つだけ入れたい場合は、この方法が手軽です。一方、短い名前（brew install formula）で入れたい場合は、先にbrew tapとbrew trustで信頼を済ませておく必要があります。

CI・自動化環境での破壊的変更と対処

今回のtap trustでもっとも実害が出やすいのが、CIパイプラインやデプロイ自動化でサードパーティtapを使っているケースです。実際、6.0.0公開後、世界中のtapメンテナのCIが「明示的な信頼が必要になった」ことで一斉に落ちる事態が起きています。

対処の方向性は2つあります。

方法A：CIスクリプトに明示的な信頼を追加する（推奨）

CIの中で、使っているtapやformulaをbrew trustで明示的に信頼してからbrew installするように直します。あるいはBrewfileを使っているなら、信頼するtapにtrusted: trueを付けます。

# Brewfileでtapを信頼する書き方
tap "user/repo", trusted: true

これが本筋の対応です。「何を信頼しているか」がコードに明示され、レビュー可能になるため、セキュリティ的にも望ましい形になります。

方法B：環境変数で一時的に旧来の挙動に戻す（暫定）

すぐにCIを直す時間が取れない場合の緊急避難として、環境変数で挙動を変える方法があります。

# 非公式tapをデフォルトで許可する（一時的な互換用）
$ export HOMEBREW_NO_REQUIRE_TAP_TRUST=1

# 逆に、tap trustを即座に強制したいとき
$ export HOMEBREW_REQUIRE_TAP_TRUST=1

ただしHOMEBREW_NO_REQUIRE_TAP_TRUST=1は、あくまで移行のための一時的な互換措置です。これを恒久的に設定してしまうと、せっかくのtap trustによる保護を自分で無効化することになります。「動かすために一旦戻す」ではなく、「方法Aへ直すまでの数日だけ」の使い方にとどめるべきです。私自身、現場では「とりあえず無効化」が一番危険な習慣だと感じています。無効化した瞬間に、それが恒久設定として残り続けるからです。

Amazon Linuxやその他のサーバー環境で、こうしたツールチェーンの破壊的変更に強くなるには、Linuxの基本コマンドと環境変数の扱いを日頃から身につけておくことが結局いちばんの近道です。

Linux管理者が今回の変更から学ぶべき教訓

Homebrew 6.0.0のtap trustは、単なる1ツールの仕様変更にとどまらない、サーバー運用全般に通じる教訓を含んでいます。

第一に、「便利だから入れた第三者のコード」は、必ず棚卸しの対象にすべきだということ。tapに限らず、curlで落としてくるインストールスクリプト、野良のapt/yumリポジトリ、pipやnpmの依存パッケージ——いずれも「実行＝相手を信頼する」行為です。Homebrewが信頼モデルを明示化したのは、裏を返せば「これまで多くの人が無意識に第三者コードを信頼していた」という事実の表れでもあります。

第二に、「とりあえず無効化」の誘惑に負けないこと。HOMEBREW_NO_REQUIRE_TAP_TRUST=1のような互換用スイッチは、エラーをすぐ消せる魔法に見えます。しかし、セキュリティ機構を無効化して問題を「先送り」しただけの状態は、いずれ自分に返ってきます。エラーが出たときこそ、なぜその機構が入ったのかを理解し、正しい形で対応する。これが20年以上現場を見てきて、最も差がつくポイントだと感じます。

第三に、別系統のパッケージ管理は「死角」を作ると自覚すること。Linuxサーバーでapt/dnfと並行してHomebrewを使うなら、「brewで入れたものは別管理で、別系統で更新される」ことを忘れないでください。脆弱性対応やバージョン管理の対象から漏れやすいのは、いつもこうした「正規ルート外」のツールです。

Homebrew 6.0.0は、こうした「信頼と検証」の問題を、ツールの側からはっきり可視化してくれました。面倒に感じる変更ほど、運用を見直すよい機会です。お使いの環境にサードパーティtapがあるなら、これを機にぜひ一度棚卸しをしてみてください。

---

• 次のページへ：389 Directory ServerとOpenLDAPの違い｜アーキテクチャから移行判断まで
• 前のページへ：AWS CLI v1が2026年7月にメンテナンスモード入り｜v1残存確認とv2移行手順
• この記事の属するカテゴリ：Linux情報・技術・セキュリティへ戻る