Trust the source closest to the code for versions and fixes, which is usually the maintainer or vendor advisory, then check it against the package level database. For severity, compare vectors and add your own context. Whatever you pick, write down which source you used and why.
A decision order
| Question | Prefer | Why |
|---|---|---|
| Which versions are affected? | Maintainer or vendor advisory, then a reviewed package database | They know what shipped |
| What is the fixed version? | Release notes and the commit | Records can lag the release |
| How severe is it? | The vector strings, read against your use | Scores from different sources can differ |
| Is it exploited? | A known exploited catalog | Observation beats prediction |
| Is it still valid? | Check withdrawn or rejected status | Retired records linger |
Why records differ
Databases are made differently. The GitHub Advisory Database separates reviewed advisories, which GitHub checks for validity, from unreviewed ones published automatically from the NVD feed. The Go database labels reports REVIEWED or UNREVIEWED, and warns that automatic mapping can fail and list all versions. The PyPA database matches CVEs to packages by heuristic and adds a small amount of human triage. Each is a different level of care.
A record with automated mapping and a record with human review will disagree sometimes, and the human reviewed one is usually, but not always, tighter.
The checklist
- Write down both claims side by side: affected range, fixed version, severity.
- Open the maintainer advisory or release notes. Does it state versions?
- Check the
modifiedtime on each record. The later one may have corrected the earlier one. - Test it. Install the claimed fixed version and the version just before it in a scratch project and rerun your scan.
- If a record is wrong, suggest a correction. See how to suggest a correction to a GitHub advisory.
- Record the decision in your tracker.
What not to do
Do not average the scores. Do not pick the lower number because it makes the report cleaner. Do not close the item without a note. An accepted risk needs an owner and a review date. For handling unresolved items, follow how to ignore a dependency advisory without hiding real risk.
Write the decision down
A one line entry is enough: the CVE ID, the sources compared, the version range you accepted, the date and your name. Six months from now, an auditor or a new teammate will ask why.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how the evidence you collect changes the decision.
Safeguard reachability analysis and policies help you record why a finding is acted on or deferred. A free scan gives you a starting list.
Quick check
Is the highest score the safest one to follow?
It is the most cautious number, but it may be wrong for your use. Read the vector and the description first.
What if the maintainer and the database disagree on versions?
Test both versions in a scratch project, then suggest a correction to the database with links as evidence.
Sources
- About the GitHub Advisory Database
- Go vulnerability database documentation
- PyPA advisory database README
Last reviewed: 19 October 2026.
