Skip to content

Compliance · UK

Cyber Essentials Plus with Homebrew on Developer Macs

UK central government, its agencies and the NHS require Cyber Essentials or Cyber Essentials Plus from suppliers bidding for higher-risk contracts. Many FCA-regulated firms use it as their security baseline, and investors and public funders ask for it in due diligence.

Developer Macs are in scope like any other end user device, and Homebrew is the part of them your MDM doesn’t manage. EnterpriseBrew handles the Homebrew side and gives you evidence to show the assessor.

What the assessor checks on a sampled Mac

Cyber Essentials Plus checks the same five controls as Cyber Essentials, then tests them on a sample of your devices. Three of those tests land on a developer Mac:

  1. 1

    Check patching. An authenticated vulnerability scan of each sampled Mac. It fails on any vulnerability the vendor calls critical or high risk, that scores 7 or more on CVSS v3, or whose fix comes with no severity at all, once that fix has been available for more than 14 days.

  2. 2

    Check malware protection. Anti-malware is running and stops the test files the assessor sends by email and downloads in the browser. On a Mac that uses certificate-based application allow-listing instead, unsigned code must not run.

  3. 3

    Check account separation. The developer, signed in with their everyday account, tries to run an administrative process. The Mac passes only if it asks them for other credentials.

The other two, an external scan of your internet-facing addresses and MFA on cloud services, don’t involve Homebrew.

Security update management

Software on in-scope devices must be licensed and supported, and updates that fix critical or high-risk vulnerabilities installed within 14 days of release.

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. Out of the box, your MDM patches macOS and the apps it deployed. It doesn’t see the tools under the Homebrew prefix, and doesn’t know which apps in /Applications came from brew.

  • ✓A live inventory of every Homebrew package and version on every Mac, reported at login and every 15 minutes.
  • ✓A fleet-wide vulnerability scan every six hours. Command-line tools are checked against OSV.dev and the CISA Known Exploited Vulnerabilities catalog, apps against the NVD.
  • ✓An alert by email or webhook for every finding that is known-exploited or clears your CVSS threshold. A threshold of 7 matches the scheme’s CVSS line, and apps can have a threshold of their own.
  • ✓Optional automatic remediation: when a finding is raised, an upgrade to Homebrew’s current version is queued on every affected Mac that a pin doesn’t hold.
  • ✓Auto update for command-line tools: on the device groups you choose, at most one brew upgrade a day, and only when something is out of date.
  • ✓For command-line tools, an install gate refuses known-exploited versions before they land, and anything above your threshold if you choose. If the check can’t finish in time, you decide whether the install is blocked or goes ahead. Apps are checked by the scan, not at install.

User access control

Accounts used for everyday work have no administrative privileges. Admin accounts are only for admin tasks.

Homebrew’s installer needs administrator rights to create its prefix, and after that brew works only for the user who owns the prefix. That’s why so many developer Macs stay admin “for Homebrew”, and why the account separation test is where they fail.

  • ✓Managed brew hands the Homebrew prefix to a local, unprivileged service account. IT sets it up once, as root, with the installer package (push it with your MDM).
  • ✓Developers install command-line tools and most apps from standard accounts, without sudo or an admin password. Every install still goes through your policy.
  • ✓On a standard account, a developer doesn’t own the prefix and can’t install into it without going through EnterpriseBrew.
  • ✓Apps with a .pkg installer need administrator rights, so a standard account can’t install them on its own. They still need an administrator, which is what the test expects.

Malware protection

Every device runs anti-malware software or certificate-based application allow-listing.

That isn’t Homebrew’s job, and EnterpriseBrew doesn’t replace either. What Homebrew adds is another way for code to arrive: any package in its main repositories, and any third-party tap a developer adds. EnterpriseBrew’s rules apply to what goes through it. With managed brew, that’s everything installed into the Homebrew prefix.

  • ✓Allow and block rules for each package, scoped to the whole fleet, a device group or one person. You can also switch to an allowlist, where only what you approved installs.
  • ✓Third-party taps are refused unless you’ve allowed them.
  • ✓Known-exploited versions of command-line tools are refused at install.

Secure configuration

Unnecessary software is removed or disabled.

A developer Mac collects packages: a database for one project, a tool tried once, dependencies of things removed long ago. If nobody knows what’s on it, nobody can say what’s unnecessary.

  • ✓The same inventory, per package: which Macs have it, at which version. Each Mac’s page shows where every package on it came from.
  • ✓Remote brew uninstall on one Mac, a device group or every Mac that has the package.
  • ✓The developer store marks packages Homebrew has deprecated, and doesn’t offer the ones it has disabled.
  • ✓Package sets that install the tools each team is meant to have, so “necessary” has a written definition.

Firewalls

The fifth control has nothing to do with Homebrew. Turn on the macOS firewall with a configuration profile from your MDM.

What you can hand the assessor

  • ✓Every install, upgrade and removal made through EnterpriseBrew: who ran it, on which Mac, which version, and what the policy and vulnerability checks decided. A package that appears without going through EnterpriseBrew is flagged at the Mac’s next sync.
  • ✓A software bill of materials for the fleet, in SPDX or CycloneDX.
  • ✓PDF reports, on demand or emailed on a schedule.
  • ✓A log of every rule change: who changed what, and when.
  • ✓Installs, fleet commands, package requests and admin actions can be streamed to your SIEM.

Vulnerability checks use the best available data: OSV.dev and the CISA KEV catalog for command-line tools, the NVD for apps. A tool whose source repository can’t be identified, or an app with no confident product match, is reported as not scanned. It is never reported as clean.

EnterpriseBrew isn’t a certification body and doesn’t certify anyone. It gives you controls and evidence for the Homebrew part of your scope. Requirements are from the NCSC’s Cyber Essentials scheme (Requirements for IT Infrastructure v3.3, April 2026).