Dependabot Returns 410 Gone: Was the Vulnerability Fixed?
Yesterday's Dependabot alert now returns 410 Gone, and there is no dependency-update PR to link. Do you close the ticket as fixed?
- A 410 Gone response to a single-alert read or update identifies a withdrawn Dependabot alert.
- An alert is withdrawn when its basis is no longer valid; this does not mean a dependency was patched.
- The withdrawn webhook provides identifiers that integrations can match to an existing ticket.
410 does not confirm a successful patch
If fetching a saved Dependabot alert number returns 410 Gone, do not record a fix. GitHub’s October 13 update identifies alerts removed because the advisory or vulnerability behind them is no longer valid.
Reads and updates for those alerts previously returned 404. The new response distinguishes a withdrawn alert from one that never existed. Both single-alert operations in the REST reference now list 410.
The relevant request targets an individual alert at /repos/OWNER/REPO/dependabot/alerts/ALERT_NUMBER. Treating every unsuccessful fetch as the same missing-record case discards the distinction the new response provides.
Keep the reason for closure
GitHub’s alert guide separates updating a vulnerable dependency from dismissing an assessed alert. An unfixed dismissed alert can be reopened. Neither dismissal nor withdrawal should be counted as a patch.
| Observed result | Interpretation | External record |
|---|---|---|
fixed | The alert is fixed. | Keep the fix record. |
dismissed | The alert was dismissed. | Keep its reason and explanation. |
Single-alert 410 Gone | The alert was withdrawn. | Record withdrawal separately. |
403 or 404 | This request did not retrieve the alert. | Check permissions and request details. |
This is a suggested classification for an integration, not a request to PATCH an alert with state=withdrawn. An alert disappearing from a list is insufficient evidence to increase a remediation count.
The event carries identifiers captured before removal
The new withdrawn action on dependabot_alert includes the alert number, GHSA and CVE identifiers, package and manifest path. An integration can use those details to match a ticket without depending solely on another fetch of the removed alert.
Existing subscribers receive the new action automatically. If a receiver filters by known action names, check whether it handles this one. GitHub Apps need at least read permission for Dependabot alerts to subscribe.
The change is available across repositories on github.com. GitHub says Enterprise Server will include it in version 3.24, so an on-premises integration needs to account for its installed version.
Close the ticket for the right reason
A practical integration can match the repository and alert number to an existing ticket, retain the advisory identifiers and dependency location, and record withdrawal as the closure reason. That leaves an explanation when there is no patch pull request to link.
Apply the same distinction when polling returns 410. For 403 or 404, investigate the fetch before marking the security work complete. Store retrieval status separately from remediation status.
When a dependency does need a fix, the work still involves changing it and verifying deployment. Dependabot’s repository alerts are not a deployment receipt. The new signal helps preserve why an alert ended.