[Feature Request] Custom Severity Overrides and SLA Management for GitHub Advanced Security

[TheAxZim]

Select Topic Area

Product Feedback

Body

Overview of request

Currently, GitHub alerts (dependabot, code scanning) rely on static severity ratings (Critical, High, Medium, Low). We're requesting the ability for organizations or enterprises to:

1. Manually adjust alert severity based on internal business context.
2. Define and track Service Level Agreements (SLAs) at the Organization or Enterprise level to automate prioritization and escalation.

1. Custom Severity Overrides

CVE's are not the best determination of criticality for certain types of issues. On triage for example, we've found Dependabot alerts that are listed as critical but the entrypoint for the vulnerability is unreachable OR 5 layers deep inside of a transitive dependancy. The only tool for security teams right now is to dismiss these alerts (basically just ignore the problem) but some of us would prefer to lower the criticality of the alert.

Main pain points:

• Alert Fatigue: Teams are forced to treat all "Criticals" with the same urgency, leading to burnout and missed deadlines for truly dangerous vulnerabilities.
• Binary Triage: Currently, the only options are "Open" or "Dismissed." There is no middle ground to say, "This is important, but not a P0."

2. Service Level Agreements (SLAs)

Security teams in Enterprises and Organizations must use external spreadsheets or third-party tools like JIRA to track if developers are meeting remediation timelines (SLAs), as GitHub lacks native "Time-to-Remediate" countdowns or escalations.

Developers have no timeline or push to drive them to fix issues.

Proposal

1. Severity Adjustment (Triage)

• Allow authorized users to change the severity level of an alert.
  • Example: Downgrade a "Critical" Dependabot alert to "Medium" if the vulnerable function is not reachable.
  • • Audit Trail: Any change should require a reason and be logged in the alert history (similar to current dismissal comments).
  • "Authorized users" should be configurable at the organization/enterprise level where settings can adjust whether repo owners / security teams or organization owners have the permission to adjust the severity of alerts. Alternatively, this could also be similar to Secret Scanning bypass requests where currently people can choose to bypass alerts, or security teams in Github can set up delegated bypass approvals.

2. SLA Management Framework

• Introduce a settings pane at the Organization/Enterprise level to define remediation windows E.g:

  • Critical: 7 days
  • High: 30 days
  • Medium: 90 days
  • Low: 180 days

  Potentially, this could be configurable based on the type of alert i.e. secret scanning / dependabot / code scanning.

3. Automated Warnings & Escalations

• Visual Indicators: Add "Days remaining until SLA breach" badges on the alert dashboard.
• Notifications: Example: Send automated pings to repository owners when an alert is within 48 hours of an SLA breach.

Escalation: Ability for security team to retrieve SLA breached alerts and escalate them (perhaps by taking over major parts of the main repo page or just fetching them via an API and escalating on a 3rd party tool like JIRA/Slack/Teams etc)

---

For business value, I think this will give teams a lot more control and the following benefits:

• Improved Security Posture: Teams focus on the risks that actually matter to the organization.

• Compliance: Makes it easier to prove to auditors that the organization is adhering to its own internal security policies.

• Operational Efficiency: Reduces the noise for developers, leading to higher adoption of GitHub Advanced Security tools.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[orosander]

For reference there is this request with a response from a GH representative.

https://github.com/orgs/community/discussions/43777