A suppressed finding comes back under a new ID when your suppression is keyed to one identifier and the scanner now reports the same vulnerability under another, such as a CVE ID versus a vendor advisory ID. Key suppressions to the full alias set, or to a stable pair of package and advisory, and recheck after scanner upgrades.
One vulnerability, several names
The same flaw can have a CVE ID, an ecosystem advisory ID and a vendor bulletin. The OSV schema handles this with an aliases field, which it describes as a list of IDs of the same vulnerability in other databases. It also says aliases should be considered symmetric and transitive: if A is an alias of B, B is an alias of A.
A related field covers closely related vulnerabilities. Related is symmetric but not transitive, so a related ID is not the same flaw. Do not suppress by related IDs unless you review each.
How the finding resurfaces
- You suppress the advisory ID the scanner used last quarter.
- The scanner updates and prefers a different database as its primary source.
- The finding now carries the new ID. Your rule does not match it.
- The same issue appears as a new, unsuppressed finding, often failing a gate.
It feels like a bug. It is a keying problem.
Make suppressions survive
| Approach | How it works | Trade off |
|---|---|---|
| Store all known aliases in the record | Match on any of them | Needs the list kept current |
| Key to package, version and one canonical ID, with aliases as notes | Humans can follow, tools can map | Depends on the tool resolving aliases |
| Re-resolve aliases at scan time | Tool does the work | Not every tool supports it |
If your tool matches only exact IDs, write the aliases into the suppression entry when you create it and add a reminder to recheck after major scanner upgrades.
A recovery routine when it happens
- Open the resurfaced finding and read the aliases on the record.
- Find your old suppression and confirm it covers one of them.
- Update the entry with every alias, keeping the original reason, evidence and end date. Do not extend the date as a side effect.
- Note the change in the history.
- Check for other suppressions affected by the same data change.
Do not treat the return as a new decision
The reviewer should compare the new finding to the old record. If the package, version and evidence are the same, this is a bookkeeping fix. If anything changed, review it fresh.
Related data hygiene
Withdrawn entries are a cousin of this issue. The OSV schema describes a withdrawn timestamp, and if it is missing the entry has not been withdrawn. When a record is withdrawn in favor of another, make sure you suppress or close the right one. Our post on withdrawn advisories covers the cleanup.
Quick check
Are related IDs the same as aliases?
No. Aliases name the same vulnerability. Related IDs are close but not identical, and the relation is not transitive.
Should the end date reset when I fix the alias list?
No. Keep the original date. Changing identifiers does not change the risk decision.
Sources
Last reviewed: 19 October 2026.
