Sharing a pre-install CVE gate for brew install / upgrade — feedback welcome

[sharkyger]

Hi all — I've been working on homebrew-safe-upgrade, a small set of wrappers (brew safe-install, brew safe-upgrade) that check incoming and transitive packages against OSV.dev, GitHub Advisory, and NVD before the install/upgrade runs. If a known CVE is found, the run is held and you decide whether to proceed.

It's deliberately a different scope from brew-vulns, which audits what's already installed. The two are complementary: brew-vulns tells you what's vulnerable on your system today; safe-upgrade tries to stop a known-vulnerable version from landing in the first place.

A few things I'd genuinely like input on from people closer to Homebrew than I am:

• Does a pre-install gate feel like something that belongs upstream (e.g. in brew-vulns itself), or is it better as an external tap?
• The transitive-dep check uses NVD's anonymous endpoint (5 req / 30s). For large brew upgrade batches this is the practical bottleneck. Are there patterns the Homebrew side already uses I should look at?
• Anything about the UX (flag names, default-on vs. opt-in, output format) that would make this feel less foreign next to brew itself?

Not trying to promote — just want to know if I'm solving a problem the community actually has, and whether I should be opening a PR somewhere instead of running it as a separate tap.

Happy to take "this overlaps too much with X, close it" as an answer.

[SMillerDev]

Seems like something that would be better served as an audit. That way it would stop updates with a CVE from getting merged.

Interesting idea though, I've shared it with other maintainers who might be interested in it.

[sharkyger]

Thanks for circulating it. The PR-time audit angle catches CVEs known before a formula bump, but anything disclosed after a version is merged still ships to users until the next bump — so I'd see that as complementary to a runtime gate, not a substitute.

The bigger goal on my side is making brew install / brew upgrade safer for everybody, especially casual users who won't enable a flag or run a separate audit command. The engine living in brew-vulns is fine; the value shows up only when the check is wired into the install path itself.

If you have a sense of where that conversation should happen — RFC on Homebrew/brew, an issue on brew-vulns, here — happy to take it there.

[stefanb]

How would this (either as a before-merge or before-install audit) handle cases of multiple vulnerabilities of different severities, where some are fixed and some not yet?

[sharkyger]

@stefanb Good question. Two parts to the answer.

For CVEs that are already fixed in the target version, version-aware filtering drops them before they reach the report. OSV is queried with native version filtering, GitHub Advisory is matched against patch-version metadata, and NVD is filtered via CPE version ranges / exact matches. So a CVE whose fixed-in version is ≤ the target version doesn't appear as noise.

For CVEs that still affect the target version, every remaining one is listed individually with its CVSS severity and source. If a target ships with, say, one CRITICAL and one LOW unfixed, both show up. For the primary package the gate then blocks and asks whether to proceed (default no); for transitive deps it warns with the same default-no prompt rather than hard-blocking, since you may have a reason to accept the dep regardless.

There's no severity threshold by design — the tool surfaces the full picture and leaves the call to the user, rather than silently auto-allowing LOW/MEDIUM. If a --min-severity opt-in for CI/batch use would be helpful, happy to track that as a separate issue.

[andrew]

@sharkyger would you be interested in contributing that kind of functionality into brew-vulns itself as ruby code instead of shell?

[sharkyger]

Yes, willing to. The goal shapes the implementation though, so let me be explicit:

The mission is making brew install / brew upgrade safer for everybody — including the casual user who won't enable a flag or run a separate audit command. That argues for default-on with an opt-out (HOMEBREW_VULN_CHECK=0 or --no-vuln-check), not opt-in. Per-command flags don't reach the people who need the protection most.

If default-on is too big a step today, the step-down I'd accept:

1. One-time opt-in via brew config, persisted — not per-invocation flags
2. Engine inside brew-vulns as Ruby (NVD + GHSA drivers alongside OSV + a brew vulns check <formula> subcommand for pre-install use), with homebrew-safe-upgrade staying as a tap wrapper for users who want gating today

npm runs npm audit automatically post-install. pip and cargo have first-party-ish audit tooling. There's room to do the same here.

Which step on that ladder is realistic? Happy to open an RFC issue on Homebrew/homebrew-brew-vulns once we know.

[andrew]

Yes that sounds good, an RFC would be great.

I believe OSV aggregates data from NVD and GHSA already?