In the OSV dumps for seven ecosystems, 1,515 of 44,476 advisory records (3.4%) are marked withdrawn. The share ranges from 1.6% for Maven to 5.9% for RubyGems. Malware records are withdrawn far less often, 356 of 239,513 (0.15%). A scanner that ignores the withdrawn field will keep reporting flaws that the database says are not real.
Method
We downloaded the per-ecosystem OSV dumps on 19 October 2026 and counted records that carry a withdrawn timestamp. We split them into advisory records and malware records (IDs starting MAL). We did not read the withdrawal reasons, so we cannot tell how many were duplicates, mistaken reports or other causes.
The shares
| Ecosystem | Advisory records | Withdrawn | Share |
|---|---|---|---|
| RubyGems | 1,160 | 69 | 5.9% |
| npm | 7,846 | 399 | 5.1% |
| crates.io | 2,923 | 124 | 4.2% |
| PyPI | 14,533 | 592 | 4.1% |
| NuGet | 1,183 | 41 | 3.5% |
| Go | 9,641 | 177 | 1.8% |
| Maven | 7,190 | 113 | 1.6% |
All seven together: 1,515 of 44,476, or 3.4%. Including malware records, 1,871 of the 283,989 records we read are withdrawn.
Malware records withdraw rarely
For malicious package records, npm has 331 withdrawn out of 222,536 and PyPI 25 out of 11,848. RubyGems and NuGet have none. A malware report is usually a plain observation, and fewer need to be taken back.
Why advisories get withdrawn
The OSV schema defines a withdrawn timestamp: the time the entry should be considered withdrawn, and if the field is missing the entry has not been withdrawn. It says any rationale for the withdrawal belongs in the summary text. We did not read those summaries, so we do not know the split between duplicates, mistaken reports and other causes. A withdrawn record stays in the dump, which lets consumers remove it from their results.
What it means for scanners and reports
- A scanner must read the withdrawn field. If it does not, a withdrawn advisory can show as an open finding.
- A finding that disappears after a database update is not necessarily fixed code. It may be a withdrawn record.
- In an audit trail, keep the advisory ID and the date you saw it. If the record is later withdrawn, you can show why the finding closed.
- When you count findings over time, expect a small drop each month from withdrawals alone.
For a team, a short check keeps this tidy. After each database refresh, compare closed findings against withdrawn IDs, and label those closures as "advisory withdrawn" so they are not counted as fixes.
Safeguard's SBOM and dependency scanning lists the components you run, and reachability analysis helps separate vulnerable code your application calls from code it does not. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a monitor reacts when data it depends on changes, and note what a withdrawn record would do to its list.
Quick check
Is a withdrawn advisory the same as a fixed flaw?
No. Withdrawn means the database retracted the record. The code was not changed.
Should I delete findings tied to withdrawn records?
Close them with the reason, and keep the record so the history is clear.
Sources
- OSV schema, definition of the withdrawn and aliases fields.
- OSV data sources and dumps, per-ecosystem OSV dumps downloaded on 19 October 2026.
Last reviewed: 19 October 2026.
