When a scan is wrong because the advisory itself lists the wrong packages or versions, suppressing it locally only fixes your copy. Propose a correction to the advisory so every tool and team benefits. For GitHub's database, anyone can suggest an improvement through a pull request that follows the OSV schema.
Three places an error can live
Before you report anything, work out which party owns the mistake. A false positive has at least three possible sources.
| Source | Typical sign | Who fixes it |
|---|---|---|
| Advisory data | Several tools make the same wrong call | The advisory database |
| Scanner logic | Only one tool reports it | The tool maker |
| Your own project | The component really is present | You |
Test with a second tool or database. If two independent sources agree the version is affected, check your own tree again before blaming the data. If only one source says so, the problem is probably in that source.
For the scanner case, see reporting a scanner false positive.
What GitHub's contribution guide says
The GitHub advisory-database repository describes itself as the public repository for GitHub Advisory Database records, and says contributions help improve the quality, clarity and completeness of advisory data. Its examples of helpful contributions include correcting affected package or ecosystem information, fixing version ranges, adding or improving references, and correcting CWEs or CVSS data.
The guide lists some conditions before you submit:
- The advisory you are updating already exists in the repository, or the vulnerability is appropriate for a public advisory record.
- Your information is based on public, referenceable sources.
- Your change follows the OSV schema.
- Your pull request updates only one advisory.
It also says that if your contribution includes sensitive or not yet public details, you should not open a public pull request or issue there.
A step by step correction
- Collect evidence: the fix commit, the release that contains it, and the first release that has the flaw. Public links only.
- Compare with the record. Check the introduced and fixed events in the affected ranges, and the package name and ecosystem.
- Fork the repository and make a branch. The guide suggests naming it after yourself and the GHSA ID.
- Edit the advisory file. Change only what the evidence supports, and keep the schema valid.
- Open one pull request for that one advisory, with a short description and your links.
- While you wait, record a time limited local exception so your pipeline is not blocked, and link it to your pull request.
Write the request so a reviewer can say yes
State what is wrong, state what it should be, and link the proof. "Fixed version is listed as 2.4.1 but the fix commit first appears in 2.4.0" is checkable. "This looks wrong" is not.
Quick check
Should I wait for the correction before shipping?
No. Use a dated local exception with your evidence, and remove it when the record is corrected.
Can I report a vulnerability I just found this way?
No. The guide says not-yet-public details must not go into a public pull request. Use private reporting instead.
What if the record is a CVE rather than a GHSA?
CVE records are maintained through the CVE program, so check that process for how corrections are requested. The steps above apply to the GitHub database only.
Safeguard offers dependency scanning with SBOM output and reachability analysis, and the free scan lets you try it on your own project.
Sources
- GitHub advisory-database contributing guide
- Editing security advisories in the GitHub Advisory Database
Last reviewed: 19 October 2026.
