Who rated this finding: NVD, the CNA, or the advisory author?

A severity score always comes from someone. In the OSV format a severity entry can name its source as NVD, CNA or SELF, and the same advisory can carry more than one. When two scores disagree, check who assigned each before you decide which to trust.

What the schema records

In OSV, the severity array holds objects with a type, a score and an optional source. The types are CVSS_V3, for a vector in versions from 3.0 up to but not including 4.0, and CVSS_V4, for 4.0 and above. If the source is omitted, the rating is attributed to the record's home database. The defined sources are NVD, CNA and SELF.

The schema adds a structural rule: package-level severity goes in the affected entry, and if any package-level severity is set, the top-level severity must not be set. So a record can rate the flaw generally or rate it per package, but not both.

Why different sources disagree

Each rater sees the flaw from a different position.

1. Timing. One source may rate at publication, another later with more information.
2. Perspective. A project scoring its own flaw describes its own deployment assumptions. A third party scoring a library scores the general case.
3. Version. One may use CVSS 3.1 and another 4.0, so metrics and numbers differ.
4. Scope of rating. A package-level rating may reflect how a specific package uses the flaw.

None of these is wrong by default. They answer slightly different questions.

Choosing a source for your gate

1. Decide whether you want the general rating or the package-specific one. For dependency scanning, package-level data is often closer to what you run, if the record provides it.
2. Prefer one stable source for gating, and write it down in policy. For example: use the CNA rating, fall back to NVD, otherwise treat as unrated.
3. Log the others as context. If a second source rates the flaw higher, add a note to the ticket.
4. Define what happens when there is no rating. The severity field is optional, so some records have none.
5. Revisit the choice when your tooling or sources change.

Do not take the highest score on every finding or the lowest. Taking the highest creates noise. Taking the lowest hides risk. A consistent choice with documented exceptions beats both.

Checking the vector, not just the number

If two sources give vectors, compare them metric by metric. If the difference is a single metric, such as Attack Complexity or Scope, read the advisory text to see which is closer to the truth for your use. For the meaning of each metric, see the CVSS 3.1 specification. A one-metric disagreement is often a judgement call about how the flaw is typically used.

Distribution ratings

Operating system vendors may rate with their own scales. Debian's FAQ says it does not use external CVSS scores when triaging issues. If a finding comes from a distribution package, read the distribution's own record, because its priority may not line up with the CVSS label shown by a general database.

What to record

For each important finding, keep: the score you used, its source and its version. If a reviewer later asks why a 7.5 was treated as medium, the answer is in the ticket.

Safeguard's policies, gates and guardrails let you set the severity basis used to block a change and apply it consistently across repositories. A free scan is at gold.safeguard.sh/scan.

Try it yourself

Click through it at your own pace, or open it full screen. Look at where a finding's severity is shown and what sits beside it.

Quick check

Sources

• OpenSSF, OSV schema
• FIRST, CVSS v3.1 Specification Document
• Debian, Security FAQ

Last reviewed: 19 October 2026.