An internal tap is worth it when several people install your tools and you want one reviewed install path with versions you control. It also becomes a high trust repository, because Homebrew documents that code in a tap can run with your user's privileges. Run it with protected branches, review and item level trust.
Definition
A Homebrew tap is a repository of formulae, casks and external commands. Homebrew's documentation states plainly that code in a tap can run with your user's privileges, and that formulae, casks and external commands are executable package definitions, not plain metadata. Loading them can run Ruby code from the tap.
What the trust model says
Since Homebrew 6.0.0, according to the documentation, non-official taps require explicit trust by default. The details matter for how you roll out an internal tap:
| Behavior | What it means for you |
|---|---|
| Tapping does not grant whole-tap trust | Adding the tap alone does not let Homebrew load everything in it |
| Installing a fully qualified name trusts only that item | Instruct people to install with the full tap and formula name |
| Whole-tap trust covers current and future items | Appropriate for a tap you administer, risky for outside ones |
| Aliases and renames do not carry trust | A changed target needs fresh trust |
| brew doctor warns about untrusted non-official taps | A useful signal to watch in fleet checks |
The reasons Homebrew gives for tap trust line up with your own threats: compromised tap repositories, unexpected repository ownership changes, package name collisions and commands loaded merely because their tap is present.
Decide: internal tap or something else
- How many tools and how many users? One tool and three users can live on a download page. Six tools and sixty users deserve a tap.
- Who reviews changes? A tap needs the same discipline as a deployment repository, because a merged formula change runs on every machine that installs or updates it.
- Do you need versions pinned per team? Formulae let you control which version is current.
- Do you have another path, such as managed device software? If device management already ships your tools, the tap may add a second channel to defend.
How to run it safely
- Put the tap in an organization repository with branch protection, required reviews and code owners limited to tool maintainers.
- Build the binaries in CI and have formulae reference release artifacts by URL and checksum. The formula should fail if the checksum changes.
- Never have formulae download and run scripts from branches. Reference tagged releases only.
- Document the install line using the fully qualified name, so people trust only the item they intend to.
- Decide whether to trust the whole tap. For a tap you administer and use daily, it can be reasonable. Write down why.
- Monitor changes. A notification on every merge to the tap repository is cheap and valuable.
- Offer a removal path: how to untap and untrust if a tool is retired or compromised.
Common mistakes
Letting many people push directly to the default branch. Pointing formulae at a moving download. Naming a tool the same as a public formula, which sets up the collisions Homebrew warns about. Forgetting that updating the tap updates what everyone runs.
Where Safeguard fits
Safeguard's SBOM and dependency scanning and CLI can check the tools you package before a release, and policies and gates can hold a release back. Try the free scan at gold.safeguard.sh/scan.
Quick check
Does running brew tap trust everything in the tap?
No. According to the Homebrew docs, tapping does not grant whole-tap trust. Installing a fully qualified item trusts only that item.
Why use the full name in install instructions?
It limits trust to the one formula or cask you intend to install, instead of every current and future item in the tap.
Sources
Last reviewed: 19 October 2026.
