severity_from_cvss counts high-impact metrics and checks AV/PR/UI rather than computing the CVSS base score:
if impact_high >= 2 && network_attack && no_privs
"critical"
elsif impact_high >= 1 && network_attack
"high"
elsif impact_high >= 1 || (network_attack && no_privs && no_interaction)
"medium"
else
"low"
end
lib/brew/vulns/vulnerability.rb:111-132
This will disagree with the official 0.0–10.0 → severity banding for some vectors. For example CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H scores 8.8 (HIGH) under the spec but this code returns medium because AV isn't N. With --severity high that vuln is filtered out.
Local privilege escalation bugs are the obvious class that gets undercounted here.
Options: pull in a CVSS gem that computes the real score, or fall back to database_specific.severity before trying to parse the vector since GHSA usually provides a pre-computed label.
severity_from_cvsscounts high-impact metrics and checks AV/PR/UI rather than computing the CVSS base score:lib/brew/vulns/vulnerability.rb:111-132
This will disagree with the official 0.0–10.0 → severity banding for some vectors. For example
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Hscores 8.8 (HIGH) under the spec but this code returnsmediumbecauseAVisn'tN. With--severity highthat vuln is filtered out.Local privilege escalation bugs are the obvious class that gets undercounted here.
Options: pull in a CVSS gem that computes the real score, or fall back to
database_specific.severitybefore trying to parse the vector since GHSA usually provides a pre-computed label.