How vulnerability patching works

A Vulnerability Patching policy tells Workbrew to upgrade vulnerable packages on your Devices without waiting for anyone to act. It gives you two things a plain upgrade schedule doesn't. It covers casks as well as formulae, and it takes a severity threshold, so you decide which vulnerabilities are worth patching without review. This page explains when patching happens and what makes a package eligible.

When patching happens#

Every time the Workbrew Agent checks in, the Workbrew Console compares the packages installed on the Device against known advisories. Patching is tied to check-in rather than to a schedule, which keeps the window where a Device sits vulnerable as short as Workbrew can make it. When a Vulnerability Patching policy covers the Device, the Console issues upgrade commands to the Agent for the affected packages.

What qualifies a package#

Workbrew upgrades a package only when the upgrade fixes the vulnerability. If Homebrew has not shipped a fixed version yet, the package is left alone until one exists. Packages installed from third-party Taps are also left alone, because Workbrew has no official Homebrew version to move them to.

Both of these are reporting rules before they are patching rules. A package that fails either one never reaches the Vulnerabilities page in the first place, so its absence from the list is not a sign that Workbrew missed it. Package vulnerabilities lists the full set of conditions.

Choosing a threshold#

You set a minimum severity for each package type. An organization might patch Medium and above for formulae, where an upgrade rarely disrupts anyone, while holding casks at Critical because upgrading a desktop app interrupts whoever is using it. Some advisories carry no usable CVSS score, and those are patched only when a package type is set to All. Package vulnerabilities maps each threshold to its CVSS cutoff.

How it relates to Automatic Upgrades and Uninstalls#

An Automatic Upgrades and Uninstalls policy carries its own "automatically upgrade vulnerable formulae" option, which upgrades every vulnerable formula on a schedule with no severity filter. Vulnerability Patching replaces that option rather than running beside it. Once Vulnerability Patching is available in your Workspace, Workbrew stops enforcing the older option and creates an equivalent Vulnerability Patching policy for each Device Group that had it enabled, so nothing stops being patched during the switch. That policy arrives with formulae set to All and casks Off, which is exactly what the older option did. Narrow it whenever you are ready, and turn casks on when you want them covered.

The rest of an Automatic Upgrades and Uninstalls policy is untouched. Scheduled upgrades of outdated-but-not-vulnerable packages, and uninstalls of forbidden ones, keep running alongside Vulnerability Patching.

Related docs#

• Automatically patch vulnerable packages - set up a Vulnerability Patching policy
• Package vulnerabilities - severity levels, CVSS cutoffs, and every Vulnerability Patching option
• How policies apply to devices in multiple groups - policy precedence when a Device is in several groups
• Why Workbrew needs Full Disk Access to update apps in place - what in-place cask upgrades require on macOS
• How the Workbrew Agent uses elevated privileges - what runs as root and why