Give unscored vulnerabilities their own visible bucket, set a documented fallback rule, and track how long items stay unscored. Silently dropping them from severity charts, or treating them as low, both understate risk. The count of unscored items is itself a data quality metric.
Why scores go missing
Not every advisory arrives with a score. New records may be waiting for analysis. Some ecosystem advisories carry no numeric rating at all. The OSV schema makes the severity field a list that can hold zero or more entries, each with a type and optional source, so an empty list is perfectly valid data. A dashboard that expects exactly one number per finding will break or hide such rows.
Three bad defaults
- Drop the row. The chart total no longer matches the list, and the missing items are exactly the ones nobody has assessed.
- Treat as low. A convenient assumption that hides potentially serious issues.
- Treat as critical. Safe in one sense, but it floods the top bucket and teaches readers to ignore it.
A better design
- Add an explicit category named Unrated, shown on every severity chart with the same prominence as the others.
- Define a fallback order. For example: primary source score, then a secondary source score, then your own triage rating, then Unrated. Whatever order you pick, write it down.
- Record which tier supplied the value, so a reviewer can see if the number came from the advisory or from your team.
- Give Unrated items a short review deadline. They should be moved to a real category after someone has looked.
Measure the bucket
Track two numbers over time: how many items are Unrated today, and how long they have been in that state. If the bucket grows, an upstream source has slowed or your intake has changed. If items sit there for months, your review step is not happening.
| Metric | What it tells you |
|---|---|
| Unrated count | Size of the blind spot |
| Median days unrated | Whether triage keeps up |
| Share supplied by internal triage | How much you depend on your own judgement |
When your own rating is the right one
Internal triage can legitimately set severity, particularly when the exploit conditions in your environment differ from the generic description. Label these as internal, keep the reasoning in the record, and allow it to be overridden if the source later publishes a score.
Communicating it
When you present numbers, include the Unrated count in the same sentence as the totals, for example "twelve critical, forty high, nine unrated". Readers learn to ask about the nine, which is the aim.
Safeguard does this kind of counting in one place: SBOM and dependency scanning, asset discovery and reachability analysis feed the same inventory, so each number can be traced back to its source. Policies can route unrated items to a review state instead of letting them disappear. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is an empty severity field a bug?
Not necessarily. Records can legitimately carry no score. Your pipeline should expect that case.
Should unrated items block a build?
Decide by policy. Many teams warn on them and set a review deadline instead of blocking.
Sources
Last reviewed: 19 October 2026.
