Resolve malware vulnerabilities when the advisory is withdrawn
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Summary
Resolve vulnerabilities created from a malware advisory when that advisory is later withdrawn upstream.
Problem
pm_malware_advisories.withdrawn_date records that an advisory was retracted. Excluding withdrawn advisories from new matching is handled separately. This issue covers vulnerabilities that were already created before the withdrawal. Once the underlying claim is retracted those vulnerabilities have no valid basis, and leaving them open means users act on a false malware report.
Proposal
When an advisory's withdrawn_date is set, resolve the vulnerabilities that trace back to it instead of leaving them open. This needs two things:
- A way to find vulnerabilities linked to a withdrawn malware advisory. Malware findings are identified by their GLAM identifier, which is the most likely join path.
- A resolution path that reuses the existing vulnerability resolution mechanism rather than adding a parallel one.
Relationship to add-on expiry resolution
#594793 (closed) covers skipping the MarkAsResolved service for GLAM vulnerabilities for up to 30 days after add-on expiry.
Note that the SBOM and CVS integration for malicious advisories is a general Ultimate feature and is no longer tied to an add-on, so it is not clear that add-on expiry is still a trigger for this data. Confirm whether that issue is still in scope before designing around it.
If both paths do end up existing, they resolve GLAM vulnerabilities on different triggers, so the interaction needs defining: a withdrawal should still resolve regardless of entitlement state, the two paths must not both act on the same vulnerability, and the audit trail should distinguish the reasons.
Acceptance criteria
- Vulnerabilities linked to a withdrawn malware advisory are resolved.
- Resolution reuses the existing service rather than duplicating logic.
- The resolution reason distinguishes advisory withdrawal from other causes.
- Confirmed whether #594793 (closed) is still in scope now that the feature is not add-on gated; if it is, the interaction between the two paths is defined and specced.
Technical notes
Depends on withdrawal being observable at ingestion. Confirm that a withdrawn advisory is delivered as an update to the existing row rather than being omitted from the feed, since the resolution has no trigger otherwise.
Parent epic: &21156