GitHub now surfaces the removal of a Dependabot alert in two concrete ways: the dependabot_alert webhook includes a new withdrawn action, and the REST endpoints for alerts return HTTP 410 Gone when the alert has been withdrawn. This lets automation and monitoring distinguish a deliberately withdrawn alert from a missing or never‑created one.
Webhook Withdrawal Action
When an alert is withdrawn, the webhook payload carries the withdrawn action and retains the identifiers that existed at the time of removal, such as the alert number, GHSA ID, CVE ID, affected package, and manifest path. Existing subscriptions to dependabot_alert events receive these deliveries automatically, so no additional registration is required.
API 410 Gone for Withdrawn Alerts
Calls to retrieve or update an alert that has been withdrawn now respond with HTTP 410 Gone instead of the previous 404 Not Found. The 410 status signals that the resource existed but is no longer valid, allowing client code to separate a withdrawn alert from a request for a non‑existent alert.
Operational Considerations
- Update webhook consumers to check for the
withdrawnaction and handle the payload accordingly. - Modify alert aggregation pipelines to treat a 410 response as a state transition rather than an error.
- Adjust security dashboards or compliance reports to display a withdrawn status instead of discarding the record.
- Verify that CI/CD gating logic that blocks merges on open alerts does not mistakenly block on withdrawn alerts.
- Test the new behavior on GitHub Enterprise Server 3.24, as the change is included there as well.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Review any tooling that consumes Dependabot alerts and add explicit handling for the withdrawn action and the 410 status. Ensure that alert lifecycle state machines record the withdrawal event rather than treating it as a missing alert. By doing so, you maintain accurate security posture data and avoid unnecessary remediation cycles.
