← tips

Tip #1 — Use Homebrew as much as possible

·
  • homebrew
  • mac
  • devops
  • supply-chain

The rule

When you install something on a Mac, default to Homebrew. It installs .dmgs, .pkgs, and CLIs alike, and it gives you something you don't get when you double-click installers from random websites: a single catalog you can list, audit, and upgrade in one command.

brew list                  # everything you have
brew outdated              # what's behind
brew upgrade               # bring it all forward

That catalog is the killer feature. A year from now you'll know exactly what you installed and why — instead of digging through /Applications wondering where that one binary came from.

When brew is not the right answer

There are real exceptions. The one that bites people most often:

  • Apps that ship daily and the brew cask lags. Claude, some editors, fast-moving betas. If the upstream cuts a release a day and the cask updates once a week, you're choosing between "stale" and "auditable". For these, take the native installer/auto-updater so you don't fall behind on fixes.

The rule of thumb: native install only when update freshness materially matters and the cask is demonstrably behind. Otherwise, brew it.

On a company computer? Document, don't skip

If the machine is locked down and you can't install brew, that's fine — but don't lose the catalog. The whole point is reproducibility. Drop the brew install command into a chat with yourself (or a private note) every time you would have run it:

# 2026-05-26 — wanted on the work mac
brew install --cask rectangle
brew install jq
brew install --cask ghostty

When you move to a personal machine — or when IT loosens the policy — you have an actual install script instead of a fuzzy memory.

Always check the formula before brew install

This is the part most people skip and it's the most important from a supply-chain perspective. Before you run brew install <pkg> for something you've never installed before, open the formula and verify the download URL points to the official vendor:

brew info <formula>          # shows homepage + URL
brew edit --print-path <formula>   # path to the .rb file
brew cat <formula>           # dump the Ruby formula to stdout

What you're looking for in the .rb file:

  • url — does this resolve to a domain you'd actually trust if you saw it in a browser? releases.foo.com from the real vendor, not foo-releases.someone.workers.dev.
  • sha256 — pinned, not blank. Brew won't install a cask without it, but eyeball it anyway.
  • homepage — sanity check the project itself exists.

Cask formulas live under homebrew/homebrew-cask, regular formulas under homebrew/homebrew-core. If brew info shows a tap you've never heard of (brew tap-info someuser/random), that's a signal — third-party taps don't get the same review as the core repos.

A trojanized brew formula is rare. A trojanized installer downloaded from a Google ad result is not. Brew tilts the odds heavily in your favor — but only if you spot-check the URL once before you let it run.

TL;DR

  1. Default to brew install / brew install --cask.
  2. Skip brew only when update freshness genuinely matters and the cask is stale (e.g. Claude).
  3. On a locked-down machine, log the brew install commands somewhere you own — future you needs the catalog.
  4. Before installing anything new, brew info + brew cat and eyeball the url and sha256. Thirty seconds, big payoff.
Community-driven supply-chain breach intel.A project from Aztecknology.