"They're taking my brew away": A practical guide to managing Homebrew
Kitty Shephard
Homebrew used to be an engineering team problem. It isn't anymore. AI-assisted development has turned marketing analysts, ops teams, and product managers into people who install packages. Most of them have no idea what Homebrew actually is, or that it's now sitting on their machine. The attack surface that used to stop at your engineering floor now runs through the whole organisation, and open source supply chain attacks are accelerating.
This is a practical guide for the IT admin who has to do something about it without breaking everything in the process.
TL;DR: Start with visibility, not policy. Meet developers in the tool they already love. Workbrew's free plan gets you full fleet visibility in minutes. No developer disruption, no policy decisions required upfront. Start for free.
Start with visibility, not policy
The instinct when faced with a policy problem is to write the policy first. That's the wrong order here.
Before restricting anything, understanding what's actually installed across the fleet changes the conversation significantly. It gives IT concrete data rather than hypothetical exposure to bring to security. It surfaces the actual scope of the problem, which is frequently larger than expected and makes the case for action more clearly than any threat report. And it lets you open the conversation with everyone else, including engineers, as "we're adding visibility without disruption" rather than "we're introducing restrictions." Most people don't have strong feelings about being visible. They do have strong feelings about being blocked.
Workbrew's free plan is a useful starting point here. It gives IT fleet-wide visibility into what's installed across every machine. No policy decisions required, no impact to developers so you can understand the actual scope before deciding what to do about it.
How to unite the teams
Developers make the most noise when something changes in their workflow, and they're usually right to. Homebrew is where a significant portion of their daily work happens: installing dependencies, managing versions, keeping local environments running. Any change that introduces friction there gets felt immediately and loudly.
The framing that works is meeting them in the tool they already use. Imagine your developers being able to self-serve package requests directly through brew. No ticket, no waiting, no workaround, with IT having visibility into what gets installed and the ability to set guardrails where they actually matter. That's a different conversation than "we're managing your package manager." It's closer to "your workflow gets better and we get the oversight we need."
"Our engineers need immediate access to the latest tools, but we couldn't afford chaos with unchecked installs. Workbrew provided the perfect solution, blending the flexibility our team loves from Homebrew with essential oversight."
Frode Lundgren, CTO, Vespa.ai
Security gets the audit trail they need to answer compliance questions and respond to incidents. Leadership gets a credible answer for the auditor. Developers get to stay in the tool they love, with fewer restrictions than before because IT can now demonstrate the fleet is under control rather than asking security to take their word for it.
Being an empowered connector
When the security team asks what's running on developer machines and you can pull up a full report rather than shrug, the dynamic of that conversation changes completely. You're no longer in the dark or scrambling for data. It becomes a fluid, of the moment update which unites teams to act appropriately.
Getting fleet visibility before being asked for it puts you in a position to bring the answer rather than react to the problem. You can walk into the security conversation with data, the developer conversation with reassurance, and the leadership conversation with evidence. The IT team stops being the people who slow things down and becomes the team that connects everyone's needs without making anyone change the way they work.
Tooling that meets everyone where they are
Most existing approaches to this problem break down because they were designed for a narrower one. Approval queues and blocked installs work poorly enough with engineering teams who understand the trade-offs. Applied to a broader population of people who just want their pipeline to run, they generate confusion rather than compliance.
Workbrew is built around a different premise. Developers keep using brew exactly as they always have — same command, same output, same Brewfiles. Non-engineers who don’t know they installed Homebrew for a specific tool don't notice anything different but are kept safe. Fleet visibility and policy enforcement happen beneath the workflow, which means IT gets what it needs without becoming the team that broke everyone's machine.
When a CVE drops, affected machines across the whole fleet are identifiable immediately. When an auditor asks what's running on developer machines, there's a real answer. When security asks for a report, it exists.
The IT teams that get ahead of this are the ones who can walk into any room and say with confidence: we know what's running, we know where, and we didn't have to break anything to find out.
Workbrew's free plan gets you fleet visibility from day one. No developer disruption, no policy decisions required upfront.