Reassess advisories when records change or are withdrawn
Preserve advisory history while revising local triage. Distinguish withdrawal, range correction, replacement records, and a verified deployed fix.
An advisory can change after a team has opened or closed a remediation task. Preserve the earlier evidence before updating the decision. A withdrawn record is a change in the advisory's status; it is not, by itself, evidence that a package was patched or that a deployment changed.
The OSV schema includes modification and withdrawal fields. Use the source's recorded status and explanation. Do not infer withdrawal merely because a feed request failed or an entry was absent from an incomplete response.
Classify the source change
Compare the previous and current records structurally. Identify the fields that affect your local match rather than relying on a summary sentence. Preserve references to both versions where the source permits it.
| Change | Local review question | Possible action |
|---|---|---|
| Affected range narrows | Does our occurrence still match? | Revise applicability with evidence |
| Affected range expands | Did a closed occurrence become relevant? | Reopen the matching release record |
| Record withdrawn | What explanation or replacement exists? | Review disposition, retaining history |
| Alias corrected | Were distinct issues combined? | Repair links without deleting evidence |
| Source unavailable | Is this a retrieval problem? | Keep last known state marked stale |
Assign a person to ambiguous changes. An automated feed update should not silently accept a material risk on behalf of the service owner.
Reconcile existing remediation work
Review deployed fixes, pending upgrades, and temporary mitigations separately. An upgrade may still be worthwhile for other corrections even when one advisory is withdrawn. Conversely, a replacement advisory may require a different version than the original ticket recorded.
Keep the original reason for any emergency action. Do not rewrite the history to imply that the earlier team knew facts published later. Record the new evidence and the revised conclusion with their own timestamps.
Test the update process
Use fixtures representing withdrawal, replacement, range expansion, and transient feed failure. Confirm that a source outage does not mark every dependency unaffected. Check that corrected relationships do not lose package occurrences or previously attached test results.
Notify the responsible owners when a change requires action, rather than sending the entire unchanged feed again. At closure, distinguish a source correction from an implemented fix. The useful artifact is a decision history that explains what was known, which release was assessed, what changed, and why the current disposition differs from the earlier one.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.