If an advisory lists the wrong affected versions, suppress your finding for now, then report the error to the database that holds the record. Gather proof of the real introduced and fixed versions, submit a correction through that database's process, and track it so your suppression can be removed.
Why the range can be wrong
Advisory records are written by people, often quickly. Typical errors include a missing fixed version, a range that starts too early, a range that covers a different major line, or a package name that matches the wrong ecosystem. The OSV schema defines ranges by introduced and fixed events and notes that SEMVER ranges should not overlap, which gives reviewers something concrete to check against.
A wrong range turns into false positives in every tool that reads the record.
Step by step
- Confirm the error. Read the advisory and the project's own release notes or fix commit. Find the first vulnerable and first fixed versions. Test if you can.
- Capture the proof. Link the commit that introduced the flaw, the commit that fixed it, and the release tags that contain each.
- Find where the record lives. Look at the ID prefix and the references on the advisory. Aliases listed in the record point to the same issue in other databases, so you may need to correct more than one.
- Use that database's correction path. Many accept a pull request or an issue against the advisory file, or a web form. Read the contribution notes first.
- Write a short, factual report. State the advisory ID, what is wrong, the correct range, and the evidence. Do not argue about severity in the same report.
- Record a tracking link in your suppression entry.
| What to include | Why |
|---|---|
| Advisory ID and aliases | So maintainers find all copies |
| Wrong range and correct range | The exact change requested |
| Fix commit and tags | The proof |
| Your contact | In case they have questions |
Keep your suppression honest
Until the record changes, your scanner will keep alerting. Suppress the finding narrowly: this advisory, this package, these versions, with the correction link and an end date of 30 to 60 days. When the database updates, delete the entry.
What about the tool maker
If the database is correct and the tool misreads it, report it to the tool maker instead. See reporting a scanner false positive. To decide which side is wrong, check the raw record first.
Be a good citizen
Corrections help everyone who scans that package. They also protect you: a fixed record means no future auditor asks why a suppression exists.
What good looks like
A good correction report is three sentences and two links. It names the advisory, says which end of the range is wrong, and points to the commit and tag that prove it. Maintainers can act on that in minutes. A long essay about why the database is bad rarely gets acted on at all.
Quick check
Who owns an advisory record?
It depends on the database. Many have named maintainers and a public process for changes. Check the record's references.
Should I wait for the correction before suppressing?
No. Suppress narrowly with an end date, then remove the entry once the record is fixed.
Sources
Last reviewed: 19 October 2026.
