Dependabot helps developers identify vulnerable dependencies before they become a bigger problem. However, a security alert does not always remain valid. Sometimes, the advisory behind an alert is withdrawn because the reported vulnerability is incorrect, the affected package was misidentified, or the underlying security information is no longer considered valid.
Previously, when GitHub withdrew a Dependabot alert, integrations could have difficulty distinguishing that event from an alert that had never existed. This created challenges for teams that synchronize security findings with ticketing systems, dashboards, and internal vulnerability management tools.
GitHub has addressed this issue by adding a withdrawn action to the dependabot_alert webhook event and changing the REST API response for withdrawn alerts from 404 Not Found to 410 Gone.
These changes give developers and security teams a clearer way to identify withdrawn alerts, preserve historical records, and keep their security reporting accurate.
What Are Withdrawn Dependabot Alerts?
Dependabot alerts notify developers when dependencies used in a repository are affected by known security vulnerabilities or other supported security advisories.
For example, a .NET application might use a NuGet package with a version affected by a published vulnerability. Dependabot can create an alert identifying the package, affected version range, and available remediation information.
However, security advisories can change as researchers investigate reported problems. If an advisory is withdrawn because the underlying information is no longer valid, GitHub can withdraw and remove the corresponding Dependabot alert.
A withdrawn alert is different from an alert that has been fixed.
- Fixed: The vulnerability has been addressed, typically through a dependency update or another remediation.
- Dismissed: A user has dismissed the alert based on the available information and their assessment.
- Withdrawn: GitHub removes the alert because the underlying advisory or vulnerability is no longer considered valid.
- Open: The alert remains active and requires investigation or remediation.
This distinction matters because a withdrawn alert should not be counted as a successfully patched vulnerability. It represents a change in the validity of the finding, not proof that a developer corrected vulnerable code.
What's New in GitHub Dependabot?
GitHub has introduced two changes that make withdrawn alerts easier to detect.
1. A New Webhook Action
The dependabot_alert webhook event now includes a withdrawn action.
When an alert is withdrawn, the webhook payload includes identifiers captured before the alert is removed. These include:
- Dependabot alert number.
- GitHub Security Advisory identifier (GHSA).
- Common Vulnerabilities and Exposures identifier (CVE), when available.
- Package information.
- Manifest file path.
Existing integrations that already subscribe to dependabot_alert events receive the new deliveries automatically. They do not need to subscribe to the event again.
This is particularly useful for systems that maintain their own copies of GitHub security alerts. The webhook provides the information needed to identify the affected record even after the original alert is no longer available through the API.
2. REST API Returns HTTP 410 Gone
The second change concerns API requests for withdrawn alerts.
HTTP status | Meaning | Recommended handling |
|---|
200 OK
| The request succeeded | Process the returned resource |
404 Not Found
| The requested resource was not found | Investigate the identifier, repository, and access context |
410 Gone
| The alert existed but has been withdrawn and is no longer available | Record the withdrawal and reconcile local state |
403 Forbidden
| Access is not permitted | Check authentication and permissions |
429 Too Many Requests
| The API rate limit has been reached | Apply appropriate rate-limit handling |
Previously, requests to retrieve or update withdrawn alerts returned 404 Not Found. The new 410 Gone response makes the withdrawal status distinguishable from an ordinary missing-resource response.
The change is available for repositories on GitHub.com and is scheduled for inclusion in GitHub Enterprise Server 3.24.
How to Handle Withdrawn Alerts in a Webhook Integration
If your application receives Dependabot webhook events, update its handler to recognize the new action.
Consider a security dashboard that stores alerts in a database. When GitHub sends an alert event, the application records its current state and displays it to the security team.
The following C# example demonstrates how to inspect the action in a webhook payload.
using System.Text.Json;
public static class DependabotWebhookHandler
{
public static string GetAlertAction(string payload)
{
using JsonDocument document =
JsonDocument.Parse(payload);
JsonElement root = document.RootElement;
if (!root.TryGetProperty(
"action",
out JsonElement actionElement))
{
throw new InvalidOperationException(
"The webhook action is missing.");
}
return actionElement.GetString()
?? throw new InvalidOperationException(
"The webhook action is invalid.");
}
}
The method parses the JSON payload and extracts the action. It rejects malformed or incomplete input instead of silently treating it as a valid event.
You can then route the action to the appropriate business logic.
string action = DependabotWebhookHandler
.GetAlertAction(payload);
switch (action)
{
case "created":
// Register a new alert.
break;
case "fixed":
// Record that the alert was fixed.
break;
case "dismissed":
// Record the dismissal.
break;
case "reopened":
// Return the alert to active review.
break;
case "withdrawn":
// Preserve the withdrawal history.
// Stop treating the alert as active.
break;
default:
// Log the action and handle it safely.
break;
}
This example illustrates action routing rather than a complete webhook receiver. A production integration must also verify the webhook signature, validate the repository and payload, handle retries, and update its database transactionally.
The critical addition is the withdrawn branch. Without it, an integration that only recognizes previously supported actions may ignore the event or process it incorrectly.
Handling HTTP 410 in a REST API Client
Applications that periodically retrieve Dependabot alerts should also update their HTTP response handling.
For example, a C# service can distinguish a withdrawn alert from a resource that cannot be found.
using System.Net;
public static async Task<string> GetAlertStatusAsync(
HttpClient client,
string requestUri,
CancellationToken cancellationToken = default)
{
using HttpResponseMessage response =
await client.GetAsync(
requestUri,
cancellationToken);
if (response.StatusCode == HttpStatusCode.Gone)
{
return "Withdrawn";
}
if (response.StatusCode == HttpStatusCode.NotFound)
{
return "NotFound";
}
response.EnsureSuccessStatusCode();
return "Available";
}
The example returns a status based on the HTTP response. In a production application, these results should normally be represented by a structured type rather than strings.
For instance, the caller could use an enumeration with values such as Available, Withdrawn, and NotFound.
The EnsureSuccessStatusCode call ensures that other unsuccessful responses are not silently treated as successful requests. A complete client should also handle authorization failures, rate limits, network errors, and transient server errors.
Most importantly, do not retry a 410 Gone response indefinitely. It indicates that the requested alert is no longer available because it was withdrawn. Record the state transition and stop ordinary retrieval retries.
Best Practices for Managing Withdrawn Alerts
1. Preserve Historical Security Records
Do not delete a local security record simply because GitHub has withdrawn the corresponding alert.
Instead, mark it as withdrawn and preserve the relevant identifiers, timestamps, and investigation history. This allows security teams to explain why an alert disappeared from their active dashboard.
The retention period should follow the organization's security and compliance requirements.
2. Keep Withdrawal Separate From Remediation
Do not combine withdrawn and fixed alerts into a single resolved category without preserving the distinction.
For example, a vulnerability remediation report should not count a withdrawn advisory as a successful dependency upgrade. Track the two outcomes separately so that security metrics remain meaningful.
3. Make Webhook Processing Idempotent
Webhook deliveries may be retried. Your integration should be able to process the same withdrawal event more than once without creating duplicate records or repeatedly triggering downstream actions.
Use stable identifiers and delivery information where available. Apply database updates in a way that safely handles repeated events.
4. Validate Incoming Webhooks
Verify GitHub's webhook signature before processing the payload. Also validate required fields and restrict updates to the appropriate repository and alert records.
Never trust an incoming JSON payload merely because it contains a familiar action name.
5. Reconcile Existing Records
A system may already contain stale alerts that were withdrawn before the new event became available to its integration.
Review existing records and compare them with the current state available from GitHub. Where the original alert can no longer be retrieved, investigate the record rather than automatically assuming that the vulnerability was fixed.
Advantages and Disadvantages
Advantages
Clearer alert lifecycle: Integrations can distinguish withdrawn alerts from ordinary missing resources.
Better historical tracking: Webhook identifiers make it easier to preserve records after an alert is removed.
More accurate security reports: Teams can separate invalidated findings from successfully remediated vulnerabilities.
Simpler API error handling: The 410 Gone response provides a specific signal for withdrawal-related requests.
Disadvantages
Integration updates are required: Existing webhook handlers and API clients may need changes to recognize the new behavior.
Historical gaps remain: Systems that did not previously receive withdrawal events may need to reconcile older records.
Additional state management: Security dashboards must preserve the difference between fixed, dismissed, withdrawn, and active alerts.
Deployment differences: Organizations running GitHub Enterprise Server need to account for the version in which the changes become available.
Common Mistakes and Troubleshooting
Withdrawn Alerts Are Still Showing as Open
Check whether your integration processes the new withdrawn action. If it does not, the local database may continue displaying an alert that GitHub has removed.
Update the event handler and reconcile existing records.
The API Returns 410 Gone
Treat this as a withdrawal signal rather than a transient failure. Update the local alert state and retain the historical information needed for investigations.
Do not repeatedly retry the same request.
The API Returns 404 Not Found
Do not automatically interpret every 404 as a withdrawal. Check the alert number, repository, request path, and access context.
The new status distinction exists precisely to avoid treating these outcomes as equivalent.
Security Metrics Suddenly Change
Review how the reporting system categorizes withdrawn alerts. If it counts withdrawals as successful fixes or removes historical records entirely, remediation and trend reports may become misleading.
Update the reporting logic to distinguish invalidated advisories from vulnerabilities that have actually been addressed.
Summary
GitHub has made withdrawn Dependabot alerts easier to identify by adding the withdrawn action to the dependabot_alert webhook event and returning 410 Gone for REST API requests involving withdrawn alerts.
These changes help developers maintain accurate security dashboards, preserve audit history, and distinguish invalidated findings from vulnerabilities that have been fixed. They are especially useful for organizations that synchronize Dependabot alerts with ticketing systems, compliance tools, or internal security platforms.
To benefit from the update, review your webhook handlers, update API error handling, and preserve withdrawn alerts as a distinct state. Combined with signature verification, idempotent processing, and reliable historical records, these changes make dependency security integrations easier to maintain and more accurate.
Join the conversation! Your thoughts help the community grow.