How Workbrew detects vulnerabilities

Workbrew draws vulnerability data from two public databases, OSV and NVD, and matches it against the software inventory it collects from your fleet. This page explains where that data comes from, how often it refreshes, what Workbrew does before it flags a package, and how quickly a new CVE reaches the Workbrew Console.

Where the data comes from#

OSV (Open Source Vulnerabilities) is an open vulnerability database covering open source software. Workbrew pulls the advisory corpus from the OSV distribution point rather than querying it per package, across the ecosystems that map onto Homebrew formulae. Each advisory ties a CVE to the versions it affects, using semver ranges together with exact version lists.

NVD (National Vulnerability Database) is NIST's CVE feed, which Workbrew reads through the NVD API. This is the source for casks, which are macOS apps and other compiled software that OSV does not cover. Matching there goes through CPE (Common Platform Enumeration), where each cask is mapped to a vendor and product pair and the advisory carries version bounds rather than semver ranges.

How often the data refreshes#

OSV syncs every six hours. Most ecosystems download the full dataset on each run. The two largest fetch only what changed since the last run and get a full re-sync once a week as a backstop, so any drift in the change cursor is reconciled.

NVD syncs once a day. The NVD API is rate limited, which is what sets the cadence. Each daily run asks for records modified in a window that overlaps the previous run, and writes are idempotent, so a failed run is covered by the next one instead of leaving a gap. A full pull of the CVE corpus runs weekly as a backstop, and the cask CPE mappings refresh daily just before it.

What Workbrew checks before flagging a package#

Flagging every Device running a named package would be noise. Workbrew confirms that the specific installed version falls in the vulnerable range, and that there is somewhere to move it to.

A formula is flagged when it came from homebrew/core, the installed version matches an OSV advisory, and the version Homebrew ships now does not. A formula that Homebrew has disabled is flagged even when it is not outdated. A cask is flagged when it came from homebrew/cask, it is outdated, the installed version matches an NVD advisory, and the version Homebrew ships now does not.

The shared rule in both is that a fix has to exist. A CVE with no patched release stays hidden until Homebrew ships one. Package vulnerabilities lists the full set of reporting conditions.

How quickly a CVE reaches the Console#

Advisory data lands within six hours of OSV publishing it, and within roughly a day of NVD publishing it. Each sync then re-matches the new advisories against packages already installed across every Workspace, so a Device does not need to check in for an existing install to be flagged. Check-ins still matter for newly installed software, because that is when a Device submits fresh inventory and Workbrew re-runs the match for it.

Those windows describe how fast Workbrew ingests advisory data, not how fast a package appears on the Vulnerabilities page. Because a package is only reported once Homebrew ships a fixed version, the wait is often set by Homebrew rather than by either sync. That part sits upstream of Workbrew.

What happens after a package is flagged#

Workbrew records the vulnerability against the Device, the package, the installed version, the CVE, and its CVSS severity, then does three things with it.

Workspaces that have configured notifications receive a batched digest by email, Slack, or webhook. It is batched rather than sent per detection, because a single sync can flag many packages at once, and a Workspace should get one summary instead of a burst. Workbrew tracks when each Workspace last received a digest, so the next one covers only what has been detected since.

The Vulnerabilities page lists every affected package across the fleet. You can search it and filter by severity and package type, and each CVE links to its record on cve.org. Where your plan includes Brew Commands, an Upgrade button opens a Brew Command prefilled to upgrade the package on the affected Devices.

A Vulnerability Patching policy removes the manual step. It upgrades vulnerable packages on check-in above a severity threshold you set separately for formulae and casks, scoped to the whole Workspace or to a Device Group. See How vulnerability patching works for when it runs, and Automatically patch vulnerable packages for how to set one up.

Related docs#

• Package vulnerabilities - severity levels, CVSS cutoffs, and the Vulnerabilities page
• How vulnerability patching works - when patching runs and what qualifies a package for it
• Automatically patch vulnerable packages - set up a Vulnerability Patching policy
• How policies apply to devices in multiple groups - policy precedence when a Device is in several groups
• Declare policies to block software packages - block forbidden formulae, casks, and licenses instead of patching them