Security Alerts Getting Withdrawn Without Trace – Feature Request / Bug Report #151862
Replies: 1 comment
-
I'm not a GitHub employee—just a community member who's seen this issue come up repeatedly. Unfortunately, once a security alert (whether from Dependabot, code scanning, or a security advisory) is withdrawn, it completely disappears from the UI and API without leaving a historical record or triggering a webhook event. This behavior clearly hampers traceability, external synchronization, and compliance tracking. Many in the community have voiced similar concerns, suggesting that withdrawn alerts should instead be marked as closed with a visible reason. Additionally, having a security_advisory webhook event fire for these state changes would help external systems stay in sync. Until GitHub provides an official fix, some have resorted to workarounds like polling the alerts API to capture state changes before the alert vanishes. Hopefully, GitHub will address this on their roadmap soon, as the loss of historical data significantly impacts security workflows. Let's continue sharing any interim solutions or updates as they come along. |
Beta Was this translation helpful? Give feedback.
-
Select Topic Area
Question
Body
We have observed a critical issue where security alerts (e.g., Dependabot, code scanning, or security advisories) are getting withdrawn without any trace in GitHub. This creates challenges in tracking security vulnerabilities and disrupts ongoing investigations into alerts.
### Issue Details:
When a security alert is withdrawn, it should ideally remain in a closed state with a reason.
However, in the current behaviour, alerts completely disappear once withdrawn, leaving no log or history in the GitHub UI or API responses.
Additionally, the security_advisory webhook (which should notify external systems about alert state changes) does not trigger when an alert is withdrawn.
### Impact:
Loss of traceability: Security teams working on fixes lose visibility of withdrawn alerts.
Sync issues: External dashboards relying on GitHub APIs become out of sync due to missing webhook events.
Audit and Compliance concerns: No historical record exists for withdrawn alerts, making it difficult for organizations to track past vulnerabilities and resolutions.
### Expected Behavior:
Withdrawn alerts should remain in a closed state with a reason displayed in the UI.
GitHub should trigger a security_advisory webhook event whenever an alert is withdrawn, so external systems can capture this event properly.
### Steps to Reproduce:
Trigger a security alert (e.g., via Dependabot, GitHub Code Scanning, or Security Advisories).
Observe the alert under the Security tab in the repository.
Wait for the alert to be withdrawn (either automatically or manually).
Notice that:
The alert disappears entirely instead of being closed with a reason.
No webhook event is triggered for this state change.
Request:
🔹 Bug Fix: Ensure that withdrawn alerts persist in a closed state with a withdrawal reason in the UI.
🔹 Feature Request: Trigger a security_advisory webhook event for withdrawn alerts in each of the repo, so external tracking tools can stay in sync.
This issue significantly affects security workflows, making GitHub's security tracking unreliable for organizations that depend on continuous monitoring.
Would love to hear from the GitHub team and the community on potential workarounds or whether this is on the roadmap! 🚀
Beta Was this translation helpful? Give feedback.
All reactions