GitHub makes withdrawn Dependabot alerts distinguishable from missing ones

GitHub's [October 13 update](https://github.blog/changelog/2026‑10‑13‑improved‑detection‑for‑withdrawn‑dependabot‑alerts/) changes how integrations learn that an alert's underlying advisory or vulnerability is no longer valid. The `dependabot_alert` webhook now emits a `withdrawn` action before the alert is removed, and REST requests for that alert return `410 Gone` instead of `404 Not Found`. The distinction closes an audit gap. A 404 could previously mean that the alert never existed, the caller used the wrong repository or number, access was missing, or the alert had been withdrawn. A 410 explicitly says the resource existed and is no longer available because GitHub withdrew it. Treat withdrawal as a terminal lifecycle event, not a successful remediation. It changes the validity of the finding; it does not show that a vulnerable dependency was upgraded or that a pull request fixed the code.

GitHub says the withdrawal payload includes identifiers captured before removal: the alert number, GHSA and CVE IDs, package, and manifest path. Existing subscribers to `dependabot_alert` events receive the new action automatically. The current [webhook reference](https://docs.github.com/webhooks/webhook‑events‑and‑payloads#dependabot_alert) remains the schema source for delivery handling. Persist the action, delivery ID, repository, alert number, advisory identifiers and received time before updating a local record. Keep the raw payload or a verified hash under the same retention policy used for other security events. That makes the state change explainable after the corresponding alert can no longer be fetched. Consumers that use an exhaustive action switch need an explicit `withdrawn` branch. A default branch that drops unknown actions can silently lose the only durable withdrawal signal.

GitHub's [Dependabot alerts REST reference](https://docs.github.com/rest/dependabot/alerts) covers get and update operations for alert records. With this release, a withdrawn alert produces 410 for those requests. That status should terminate ordinary retries and lead to a withdrawal reconciliation path. Do not convert every 404 into 410 in a compatibility layer. A 404 still carries useful meaning for an alert that never existed or cannot be seen by the caller. Record status code, repository, alert number and authentication scope so operations teams can tell an expected terminal response from a permissions or routing defect. For clients that support GitHub Enterprise Server, gate the behavior by deployment version. GitHub says the changes are live for all repositories on GitHub.com and will be included in GitHub Enterprise Server 3.24.

A security dashboard that maps removed alerts into resolved findings will overstate remediation. Use at least four states: open, dismissed, fixed and withdrawn. The withdrawal state should exclude the alert from current exposure counts while preserving it in the historical audit trail. Recalculate only metrics whose definitions actually include invalidated advisories. A remediation‑rate denominator may need a dated rule for withdrawals; an operational queue may simply remove them. Document the choice so a sudden count decrease is not reported as developer performance. If downstream tickets or SIEM cases were created from the alert, close or annotate them with the advisory identifiers and GitHub delivery evidence. Avoid deleting the local history just because GitHub removed the source alert.

Add the new action to a fixture, replay it through the webhook consumer and confirm that duplicate deliveries do not create duplicate transitions. Then test a synthetic 410 response in the REST client and verify that it stops retries without masking unrelated 404 or authorization errors. Monitor unknown‑action counts and 410 rates during rollout. A spike can be legitimate after advisory withdrawals, but it can also reveal a parser version mismatch. Keep the alert number and advisory IDs searchable even after the current‑alert table removes the row. GitHub's change is small at the protocol edge but important for evidence quality: invalidated findings can now leave an explicit trace. Follow [GitHub's OpenTools organization page](https://opentools.ai/organizations/github) for related platform changes. *Figure: The new Dependabot withdrawal path from webhook evidence to REST terminal status. Sources: [GitHub's announcement](https://github.blog/changelog/2026‑10‑13‑improved‑detection‑for‑withdrawn‑dependabot‑alerts/), the [webhook reference](https://docs.github.com/webhooks/webhook‑events‑and‑payloads#dependabot_alert) and the [REST reference](https://docs.github.com/rest/dependabot/alerts). Figure by OpenTools Team; no third‑party expressive material used.*