Vulnerability severity levels, low to critical

Labels and scores

Advisories rate danger in two ways. Many carry a qualitative label such as high or moderate. Others carry a CVSS score from 0 to 10, computed from a vector that describes how the flaw is reached and what it affects.

The five buckets

DevFlow uses one scale for every ecosystem: critical, high, moderate, low and unknown. A numeric score is bucketed with the standard CVSS v3 ranges:

• 9.0 to 10: critical;
• 7.0 to 8.9: high;
• 4.0 to 6.9: moderate;
• 0.1 to 3.9: low;
• 0, or no score: unknown.

Labels map by name, with medium treated as moderate, and any label DevFlow does not recognise becomes unknown. A computed score of exactly 0 is treated like a missing score, since such a vector rates no impact at all.

How each scanner gets there

• govulncheck, the .NET scanner and pnpm audit use the label of the advisory, and the info level of pnpm becomes low.
• osv-scanner uses the label when there is one and otherwise the highest numeric score of the advisory group.
• cargo-audit gives only a CVSS vector, so DevFlow computes the base score itself; a CVSS v4 vector stays unscored.
• RustSec warnings carry no score: unsound crates count as moderate, unmaintained and yanked crates as low.
• pip-audit reports no severity at all, so every pip-audit finding lands in the unknown bucket.

Where the buckets show up

The scan summary of a task reads like "3 vulnerabilities: 1 critical, 2 high", listing buckets from critical down. The merge evidence section of the pull request counts findings per bucket for each repository.

Every recurring scan also stores its critical and high counts with the scan history. The planned public security pages will report both per ecosystem as well.

Reading severity with care

A severity describes the flaw, not your exposure to it. A critical issue in a function your code never calls can matter less than a moderate one on your request path, so check whether your code uses the affected function before you decide how urgent an upgrade is.

A severity also says nothing about the fix. Check the fixed version that comes with each finding: an upgrade inside the same major release is usually cheap, while a fix that needs a new major release deserves its own planned task.

A worked example

Suppose one scan returns a high finding from osv-scanner, a moderate one from cargo-audit and two unknown ones from pip-audit. The task summary then lists one high, one moderate and two unknown, and the two findings in the unknown bucket still need a look. The evidence line for that repository shows a total of 4 next to the same three counts.