The Hallway Track: Enterprise Mac, Open Source, and WWDC26
Kitty Shephard
The conference “hallway track” is where the action is, and this year, we saw one conversation dominate: Homebrew is no longer just a developer problem. Across conferences this spring in the Netherlands, Canada, the UK, and Japan, the same situation kept coming up: Homebrew is installed across full organisations, on machines that IT never provisioned it on and security teams have no visibility into. When a compromised package runs quietly on those machines, the incident is not confined to engineering: it can reach across the company.
That shift is changing who is in the room at these events and what they are asking about. IT administrators and security practitioners are now expected to have answers for open source tooling they were never given responsibility for. This spring's conference circuit was largely about what getting those answers look like in practice. WWDC is on the horizon, and any changes that Apple announces in June will land on top of work currently in-flight.
Admin rights and the Homebrew blast radius
At MacAD.UK, the conversation had moved past whether least privilege was a good idea, and was instead focused on implementation. How do you follow the principles of least privilege without creating a workaround culture? The challenges that came up: handling users with legitimate reasons for elevated access, what a policy exception process looks like at scale, and what audit trail satisfies a security review.
Brandon's talk at MacAD.UK, "The Homebrew organizational blast radius: Managing compliance, security, and trust at scale," framed the problem directly. Homebrew quietly underpins productivity, onboarding, and security tooling in large teams, but unmanaged usage creates hidden risk that doesn't show up until something goes wrong. The session covered how governance and auditability can be added to Homebrew without pulling it out from under the engineering teams that depend on it. The scenario that comes up most often: engineers have worked around MDM controls to get the package access they need, and nobody in IT or security has visibility into what that looks like.
NIS2 is adding formal pressure to this for European teams. The underlying theme is the same across regions: standard accounts as default, with a defensible process for exceptions.
Software origin is a compliance question
At the inaugural FINOS Toronto event, the supply chain risk conversation was more structured. The audience was banks, fintechs, and financial institutions with formal audit obligations. The question of where installed software came from, and what its update history looks like, is no longer theoretical in that environment. "Installed via Homebrew by individual users" does not satisfy audit requirements in regulated environments.
In Billy McGee’s presentations "Brewing in the Dark: Homebrew and Software Supply Chain Security in Financial Services," he looked at the gap between what security frameworks now require and what most organisations can actually demonstrate. Attacks like the Trivy incident have made the provenance question concrete for security teams that previously treated it as a future concern. The compliance teams attending FINOS had largely already identified Homebrew as a gap. The question was what tooling existed to close it without creating friction for engineering teams.
That framing came up at Mac Admins Toronto, JMUG and MacAD.UK as well. The specific form varies by organisation, but the core question is consistent: how do you get visibility and control over Homebrew without breaking the workflows that depend on it.
Governance inside the tools, not alongside them
Across these events, a consistent thread in the audience was the tension between how security teams work and how developers work. Platform SSO, policy enforcement, audit trails: these are the tools security teams reach for. Homebrew, Git, AI agents: these are the tools developers reach for. The gap between those two sets of tools is where unmanaged installs, invisible dependencies, and compliance failures tend to live.
At Mac Admins Europe, David Starr's session addressed this directly. Reflecting on 50 years of Apple and the era the platform is now entering, the framing was pointed: security and developers are not solving different problems. They're solving the same problem with different tools. The argument was that governance needs to live inside the tools developers already use, not in a parallel system that competes for their attention. When those systems are separate, developers route around the governance layer. When governance is built into the tooling, compliance becomes a byproduct of normal work.
This is where the infrastructure-as-code approach to fleet management connects. If device state is defined and version-controlled, unmanaged Homebrew installs represent drift that's visible and addressable rather than invisible and accumulating.
What to watch heading into WWDC
David Starr's point at Mac Admins Europe matters more as WWDC approaches. Apple's announcements in June tend to move the goalposts on the exact questions the community is working through now: how admin rights are enforced at the OS level, what MDM gets visibility into, how Platform SSO behaves across different device and identity states. Every year, those changes either support what admins have built or require them to rebuild it.
The direction is toward tighter OS-level controls, more formal identity requirements, and more scrutiny of what's running on managed devices. That's consistent with where the compliance conversation is heading independently. The admins working through the implementation questions now, on least-privilege, on Homebrew governance, on identity and package management, are doing the work that WWDC announcements will either validate or accelerate.
The spring circuit is done. The rest of the 2026 calendar is ahead. Find out the next event you can find us at here: workbrew.com/events