9 min read - Withdrawn Dependabot Alerts: Keep the Security Decision Trace

GitHub changed the lifecycle of Dependabot alerts on 13 October 2026. When the advisory behind an alert is no longer valid, GitHub withdraws the alert and removes it. Security automation can now receive a withdrawn webhook action before that record disappears, and the REST API returns 410 Gone for the former alert instead of treating it like an ID that never existed.

The change looks small. It fixes a hard audit problem: a queue item can vanish after someone has opened a ticket, upgraded a dependency, accepted downtime or explained a risk to a customer. If the integration stores only the current Dependabot list, it loses the reason for that work and may report a misleading fall in vulnerability count.

The right response is to keep a tombstone, check why the source changed and review the original decision. Withdrawal is not a command to revert a patch.

What GitHub changed

GitHub's 13 October changelog defines two machine-readable signals:

• the dependabot_alert webhook has a withdrawn action whose payload retains the alert number, GHSA and CVE identifiers, package and manifest path captured before removal;
• requests to get or update the withdrawn alert return 410 Gone, while 404 Not Found remains a different result.

Existing webhook subscribers receive the new action automatically. GitHub says the behaviour is available for all repositories on github.com and will ship with GitHub Enterprise Server 3.24.

Those details separate four states that should stay separate in a security record:

A withdrawal therefore belongs in the event history. It should not overwrite the earlier state as though the alert had never existed.

A source correction is not a remediation result

Vulnerability records change for several reasons. The CVE Program's operational rules allow a published CVE record to be rejected when research finds no vulnerability, when an incorrect identifier was used, or when records become duplicate or are merged. The rules require the assigning authority to provide an explanation.

That distinction affects the local response. Suppose an alert led a team to upgrade a library from version A to version B. A later withdrawal may mean the issue did not exist, but it may instead mean another identifier now represents the same flaw. The upgrade may also contain ordinary bug fixes or compatibility changes that have nothing to do with the withdrawn advisory.

An automated rollback cannot tell those cases apart from the withdrawal event alone. It can reopen the decision for review, attach the upstream explanation when one is available and show the code or configuration changed in response. A human owner can then decide whether any further work is justified.

This is the same evidence discipline described in our guide on turning vulnerability findings into verified patches: the finding, change, test and acceptance record answer different questions.

Keep a useful tombstone

The webhook carries enough identity to avoid an anonymous deletion. Store it in an append-only event record before synchronising dashboards or tickets.

Do not copy the full advisory into every system without a retention purpose. The identifiers, affected path and decision links are usually enough to reconstruct the case while keeping one controlled evidence record.

The payload is a tombstone, not necessarily a complete explanation. If the event contains a CVE ID, inspect the current CVE record and cited vendor advisory. If it has only a GHSA ID, inspect that advisory and its references. Record “reason not available” rather than inventing one.

Change the integration before the dashboard

A webhook consumer should verify GitHub's signature, accept the new action and process redeliveries without creating duplicate tickets. GitHub's webhook documentation documents the unique X-GitHub-Delivery identifier and recommends validating X-Hub-Signature-256. Use the delivery ID for ingestion idempotency, while the repository and alert number identify the security object.

Process the event in this order:

1. Validate the delivery signature and store the raw event under the applicable retention policy.
2. Append a withdrawn transition to the alert history; do not delete the row.
3. Link any existing ticket, pull request, dependency update and acceptance evidence.
4. Look up the current GHSA, CVE and vendor sources, then assign an owner if the reason or replacement is unclear.
5. Recalculate operational views from event state, keeping source corrections apart from fixes and risk acceptances.
6. Close the review only after the owner records the effect on the prior decision.

Polling integrations need a separate branch for 410. GitHub's Dependabot REST reference lists both 404 and 410 for the get endpoint. Treating both as “delete local row” throws away the distinction the new API was designed to supply. A 404 can also follow a wrong repository, alert number or access context, so it should enter an investigation path rather than masquerade as a withdrawal.

Review the patch without second-guessing history

The owner should review what the team did, using the evidence available when the decision was made. Avoid judging the earlier response solely with information that arrived later.

“Usually keep” is deliberately not an automatic rule. A dependency upgrade can alter behaviour, licensing or support even when it passes tests. The product owner still owns that choice. Conversely, reverting a tested patch merely because one identifier was withdrawn can reintroduce unrelated defects or place the application back on an unsupported version.

Keep the metrics honest

A withdrawn alert should reduce the current count of source-backed alerts. It should not count as a patch delivered, a risk accepted or engineering work avoided. Teams that collapse every disappearance into “resolved” reward their process for an upstream data correction.

Use separate measures for current exposure and workflow quality. Current exposure can show open alerts by severity and reachable dependency path. Workflow reporting can show time to ingest a withdrawal, tombstones awaiting explanation, replacement IDs not yet linked and tickets whose prior decision has not been reviewed.

Keep historical effort visible too. If a team spent two days testing an upgrade that remained useful, the withdrawal does not turn those two days into zero. It changes the attribution: the work is no longer evidence of closing that alert, but it may still be valid maintenance.

A one-sprint rollout

Start by finding every consumer of Dependabot state: webhook handlers, scheduled API jobs, security data stores, issue automation, dashboards and compliance exports. A single unmodified consumer can recreate the deletion later.

Add recorded fixtures for withdrawn, 410 and 404. Test duplicate delivery, out-of-order events, a ticket that is already closed and an alert with no CVE ID. Then run the change against a non-production repository and verify that the active queue, history and metrics disagree in the intended way: the alert leaves the current queue while its decision trace remains searchable.

For GitHub Enterprise Server, plan the handler before upgrading to 3.24 so the new event does not arrive as an unknown action. On github.com, check ingestion now because existing subscribers receive it without a new subscription step.

Exceev's custom engineering and consulting services can help a team map the event flow, test the integration and design the decision record. The customer remains responsible for its vulnerability decisions, evidence retention and change approvals.

Sources and limitations

We opened and reviewed every source below on 14 October 2026.

• GitHub's 13 October changelog is the primary source for the new withdrawn action, retained identifiers, 410 response, github.com availability and planned GitHub Enterprise Server 3.24 support.
• GitHub's webhook event reference documents the event subscription context, delivery identifier and payload-signature headers used in the integration design.
• GitHub's Dependabot REST reference lists distinct 404 and 410 responses for a single-alert request. It does not state the business workflow a customer should apply.
• The CVE Program's CNA Operational Rules 4.0 provides independent primary evidence for rejection reasons and the requirement to explain a rejected published CVE record.

We did not inspect GitHub's internal advisory pipeline, a reader's webhook deliveries or a real withdrawn alert payload. GitHub's changelog does not promise that every withdrawal includes a replacement ID or complete explanation. The tombstone schema, review flow and metrics are Exceev's analysis, not GitHub or CVE Program requirements. This article does not provide a security, legal or compliance guarantee.