When an advisory is withdrawn, its database no longer considers the entry valid, so the finding should be closed once you confirm why. In the OSV format, a withdrawn timestamp marks this, and the reason belongs in the summary text. Read the reason first, then close the finding and keep a note.
What withdrawn means in OSV
The OSV schema has an optional withdrawn field. It gives the time the entry should be considered to have been withdrawn, as a UTC timestamp. If the field is missing, the entry has not been withdrawn. The schema says any rationale for why the vulnerability was withdrawn should go into the summary text.
So there are two parts to check: whether the field is set, and what the summary says.
Why advisories get withdrawn
The schema does not list reasons, so avoid guessing. In practice, the reason is stated in the summary. Common situations to look for in that text include a duplicate of another record, an entry that was filed against the wrong package, or a claim that turned out not to be a vulnerability. Treat these as examples to look for, not as a complete list.
The reason changes what you do next.
| Reason in the summary | What to do |
|---|---|
| Duplicate of another record | Keep the finding, but under the surviving ID |
| Wrong package or ecosystem | Check whether your component was ever affected, close if not |
| Not a vulnerability | Close the finding |
| No reason given | Ask the database owner, and keep the finding open until answered |
The duplicate trap
If the record was withdrawn as a duplicate, the underlying flaw is probably still real. Closing the finding would be a mistake. Look for the other record, often named in the summary, and make sure your scanner reports it. Check the aliases field on the surviving entry, so you track one problem under one row. See listing the same vulnerability twice.
A short procedure
- Open the record and check the withdrawn timestamp.
- Read the summary for the reason.
- If it is a duplicate, find the surviving record and confirm your tool reports it.
- If the flaw is not real or never applied to your package, close the finding and note the source, reason and date.
- Check that your scanner has refreshed its data. A tool with old data can keep reporting a withdrawn entry.
- If tickets were opened in other systems, update them so no one patches for a non-issue.
Keep the paper trail
Closing a finding because of a withdrawal is a decision. Record the advisory ID, the withdrawal date, the reason, and who closed it. If a customer or auditor asks later why a finding disappeared, you can show the record rather than rely on memory.
For a related look at data freshness, see how fresh is a vendor's vulnerability data.
Quick check
Does withdrawn always mean I am safe?
No. A duplicate withdrawal means the flaw is tracked elsewhere. Read the summary to see which case you have.
Why does my tool still show a withdrawn advisory?
Its data may not have refreshed yet. Check when it last synced, and rescan after it has.
Safeguard offers dependency scanning with SBOM output and reachability analysis, and the free scan lets you try it on your own project.
Sources
Last reviewed: 19 October 2026.
