A useful vulnerability finding contains the affected component and version, the advisory identifier, where it was found, severity with its source, exploit signals, a fix version, and an owner. Without those fields a developer has to research before acting, which is where findings stall.
The field list
| Field | Why it matters | Example of the problem when missing |
|---|---|---|
| Component name and exact version | Says what to change | Developer cannot find the package |
| Ecosystem or package type | Avoids name clashes across registries | Same name, different package |
| Advisory ID and aliases | Lets people look up details and deduplicate | One issue appears twice under two IDs |
| Location and dependency path | Shows which project and how it was pulled in | Nobody knows which parent to upgrade |
| Severity, with scoring version and source | Sets expectations | A score with no source cannot be compared |
| Exploit signals | Separates urgent from theoretical | Everything looks equally urgent |
| Fix version, or none available | Defines the action | Ticket says "update" without a target |
| Scan time and data version | Shows how fresh the result is | Cannot tell if a fix is already known |
| Owner or team | Gets it to a person | Finding sits in a shared queue |
| State | Open, fixed, accepted, suppressed | Same item reopened by mistake |
Notes on the trickier fields
Aliases. One vulnerability can have several identifiers across databases. The OSV schema includes an aliases field for exactly this, so a record can state that its entry describes the same issue as entries elsewhere. A finding that carries aliases can be merged with its twins.
Severity. CVSS guidance recommends labelling scores by the metrics used: CVSS-B for Base only, CVSS-BT for Base plus Threat, and so on. The guide also notes that public databases typically provide only Base scores. If your finding shows a bare number, you cannot tell whether it reflects exploit activity or your environment.
Exploit signals. Two public signals are common. EPSS estimates the probability of exploitation in the next 30 days, as a score from 0 to 1 updated daily. The CISA Known Exploited Vulnerabilities catalog lists issues with evidence of active exploitation, with a date added and a due date for federal agencies. Neither knows your context.
Location. For transitive dependencies, a path such as app to parent to child is more useful than the child alone, because the fix may be upgrading the parent.
A quick test
Hand a finding to someone who has never seen the project. Can they, without asking anyone, say what to change, to which version, in which repository? If not, a field is missing.
What to leave out
Long advisory prose copied into every ticket adds length but not action. Link to the advisory and keep the finding short.
Where Safeguard fits
Safeguard attaches reachability analysis and exploit context to findings and can open a fix pull request, with autonomous remediation off by default and every category on Manual. To see findings with these fields on your own project, run the free scan.
Quick check
Why include the advisory aliases?
Different databases give the same vulnerability different IDs. Aliases let a tool merge duplicates so one issue is not fixed or counted twice.
Is a fix version always available?
No. Some findings have no fixed release yet. The finding should say so plainly, so the owner can choose a mitigation or a replacement instead.
Sources
- OSV schema specification
- FIRST CVSS v4.0 user guide
- FIRST EPSS FAQ
- CISA Known Exploited Vulnerabilities catalog
Last reviewed: 19 October 2026.
