Security Vulnerabilities
Open Dependabot alerts across your repos, with an admin-configurable remediation SLA.
Security Vulnerabilities, in the main sidebar, lists every currently open Dependabot alert across your connected GitHub repos — package, severity, ecosystem, and how many days it's been open. It's its own root nav item, not part of the Reports section, since it's a live risk list rather than a comparative/ranked panel.
Filtering
Filter the list by repo, by team (via each repo's team assignment — an alert counts toward a team if the alert's repo is assigned to that team, not by any notion of "owner"), and by severity (Critical, High, Medium, Low). Unlike most reports, there's no date-range filter — this is always a snapshot of what's open right now, the same way the "oldest work in progress" panel on other pages works.
Remediation SLA
Each severity has a configurable number of days before an open alert counts as breached. Defaults are Critical: 1 day, High: 7 days, Medium: 30 days, Low: 90 days — a starting policy, not a fixed standard. The summary tiles at the top of the page show the total open count, how many are currently breached, and a per-severity count; each row also gets an On track / Breached badge, and the table is sorted breached-first.
The SLA days themselves are configured from Settings → Security, not on this page — admins with access see a "Manage SLA" link in the top-right.
Pagination
Results are paginated (25 per page) rather than all loaded at once, sorted breached-first, then by severity, then by days open. Use the Previous/Next links at the bottom of the table; your repo/team/severity selections carry over across pages.
Access
Two separate permissions control this feature:
- View Security Vulnerabilities — required to see the page and its data.
- Manage Security Vulnerabilities SLA — required to access Settings → Security and change the SLA days. This requires the view permission as well, so a role can't be given SLA policy control for a page it can't otherwise see.
See Granular Permissions for how these two fit into the permission model, and Default Role Templates for which built-in templates grant which by default.