Preparing Developer Macs for Cyber Essentials Plus: The Homebrew Problem

Cyber Essentials is the UK government-backed baseline for cyber security, and more and more buyers ask for it. Since February 2025, UK central government departments, their agencies and the NHS have to require Cyber Essentials, Cyber Essentials Plus or equivalent controls from suppliers bidding for higher-risk contracts (Procurement Policy Note 014). The FCA doesn't mandate the scheme, but many regulated firms use it as their security baseline. Investors and public funders increasingly ask for it in due diligence.

Plain Cyber Essentials is a self-assessment. Cyber Essentials Plus adds an assessor, who tests your controls on a sample of real devices. For many companies, that's where the developer Macs become a surprise. The Windows laptops were ready months ago, and so is macOS itself. But the developers' toolchains came through Homebrew, and Homebrew is the part of the Mac the MDM doesn't manage.

This article walks through the tests that land on a developer Mac, where Homebrew tends to fail them, and what to fix before the assessor arrives.

What Cyber Essentials Plus actually tests

The NCSC's test specification has five test cases. The first is an external vulnerability scan of your internet-facing addresses. The other four run on sampled devices and accounts:

Check patching. An authenticated vulnerability scan of each sampled device.
Check malware protection. Test files sent by email and downloaded in the browser must be blocked, or unsigned code must not run where application allow-listing is used.
Check MFA on cloud services.
Check account separation. A user signed in with their everyday account tries to run an administrative process.

MFA on cloud services has nothing to do with Homebrew. The other three all involve it.

The sampling is worth understanding. The specification asks the assessor for a representative sample, and says the number of devices tested depends on how much variation your provisioning leaves between them. Standard laptops built from one image can be covered by a handful of samples. Developer Macs are the most varied devices most companies own. Every developer has installed their own tools, so expect developer Macs in the sample.

A single failed sub-test fails the assessment. The specification allows a narrow exception for marginal deviations, at the scheme's discretion. Don't plan around it.

The 14-day rule meets `brew upgrade`

The patching test fails a device if it finds a vulnerability that:

the vendor describes as critical or high risk,
has a CVSS v3 base score of 7 or above, or
comes with a fix whose severity the vendor doesn't give at all,

and the fix has been available for more than 14 days. The requirement behind it, in the scheme's Requirements for IT Infrastructure, applies to all software on in-scope devices, however it got there.

Homebrew doesn't upgrade packages in the background. A command-line tool stays at the version it was installed at until someone runs brew upgrade on that Mac. A developer Mac collects dozens, often hundreds, of Homebrew packages, and many of them get regular security releases: openssl@3, curl, git, language runtimes like python and node, and the libraries under them. Apps installed as casks sit in /Applications like any other app, where an authenticated scan looks for them.

The MDM doesn't close this gap. Out of the box, it patches macOS and the apps it deployed. It doesn't see the tools under the Homebrew prefix, and it doesn't know which apps brew installed.

Done by hand, the fix looks like this, on every Mac:

brew update
brew outdated
brew upgrade

That works for five Macs, but not for two hundred, and it misses what the rule actually measures. brew outdated tells you a package is behind. It doesn't tell you whether the version installed has a high-severity vulnerability, or how long the fix has been out. The 14-day rule is about severity and time, and you need to know both, for every Mac. Pinned packages need a decision too. brew pin holds a package at its current version, usually for good reasons, but the scheme doesn't care why a vulnerable version is still there. If you pin, you need to know when a pinned version picks up a high-severity finding.

"We need admin rights for Homebrew"

This is the most common reason developer Macs fail the account separation test.

Homebrew's installer needs administrator rights to create its prefix (/opt/homebrew on Apple Silicon), and after that the prefix belongs to the user who installed it. The easy path is to make every developer an administrator, and many companies did exactly that. It fails the test. The account separation test passes only if the Mac asks the user for other credentials when they try to run an administrative process. An everyday account with admin rights fails on every sampled Mac.

There are two ways out:

Install Homebrew with an admin account, then give the prefix to the developer's standard account. It works on a one-person Mac. Apps that install into /Applications will need an administrator, and the patching problem above stays exactly where it was.
Give the prefix to a dedicated service account, and let developers install through a controlled path that doesn't need admin rights. That takes more setup, but it's the one that scales past a few Macs and, on a standard account, leaves the developer unable to get around the process.

Either way, apps whose installer needs administrator rights still need an administrator: a standard account can't install them on its own. That's fine, because it's what the test expects.

Supported and necessary software

Two more requirements catch developer Macs out. Software must be supported, and removed from in-scope devices once it isn't. And unnecessary software must be removed or disabled.

Homebrew has its own signal for the first one. When a package stops being maintained upstream or no longer builds, Homebrew marks it deprecated, and later disables it. A disabled formula can no longer be installed, but it stays on every Mac that already has it. brew info <name> shows whether a package is deprecated and why. Homebrew's deprecation isn't the same thing as the scheme's "unsupported", but it's the closest signal Homebrew gives you, and a deprecated package is worth a decision.

For unnecessary software, start with what nobody asked for:

brew leaves --installed-on-request   # what the developer installed on purpose
brew autoremove                      # dependencies nothing needs any more

The rest is judgement. A database installed for one project two years ago is unnecessary. So is a tool someone tried once. You can only make that call if you know what's on the Mac.

Malware protection is not Homebrew's job

The malware protection control asks for anti-malware software or certificate-based application allow-listing on every device. Homebrew doesn't change which one you use.

Most Mac fleets meet it with anti-malware. If yours uses certificate-based allow-listing, test Homebrew's command-line tools against it early: they aren't signed with a developer certificate the way distributed apps are.

What Homebrew does add is another way for code to arrive on the Mac: any package in its main repositories, and any third-party tap a developer adds. Deciding which packages and taps are allowed isn't the malware control itself, but it narrows what that control has to deal with.

A checklist before the assessor arrives

Know what's on every developer Mac. Keep a per-Mac list of Homebrew packages and versions, not just the apps in /Applications.
Know which versions have high or critical findings, and since when. A CVSS threshold of 7 matches the scheme. Findings without a score count too, so review them.
Upgrade within 14 days. The assessor's scan looks at what is on the Mac on the day, so what counts is that nothing on it is past the deadline.
Take developers off admin accounts without taking away their ability to install tools.
Remove what nobody needs: orphaned dependencies, deprecated packages, one-off experiments.
Decide who can add third-party taps.
Do a dry run. Pick three developer Macs, the older and messier the better, and scan them the way the assessor will.

Where EnterpriseBrew fits

EnterpriseBrew manages the Homebrew side of this. Each Mac reports its packages and versions at login and every 15 minutes. A fleet-wide scan every six hours checks command-line tools against OSV.dev and the CISA Known Exploited Vulnerabilities catalog, and apps against the NVD. You get an alert for every finding that is known-exploited or clears your threshold, and you can have an upgrade to Homebrew's current version queued on the affected Macs automatically. Managed brew hands the Homebrew prefix to an unprivileged service account, so developers install command-line tools and most apps from standard accounts. Apps with a .pkg installer still need an administrator. And every install, upgrade and removal made through EnterpriseBrew is on record for the assessor. The Cyber Essentials Plus page maps each control to what it does.

A caveat, true of any scanner: vulnerability checks are only as good as the data behind them. EnterpriseBrew checks against the best available data. A tool whose source repository can't be identified, or an app without a confident product match, is reported as not scanned, never as clean. EnterpriseBrew doesn't certify anyone either. It gives you the controls and the evidence for one part of the scope.

The rest stays where it is: firewalls, MFA on cloud services, anti-malware and macOS updates belong to your MDM and your identity provider. What usually fails the assessment is the part nobody was looking at, and on developer Macs that's Homebrew.