✨ Improvements to Dependabot alerts ✨

[erinhav]

Today, we’re shipping improvements to Dependabot alerts that make them easier to understand and remediate. 🚀

Improving the developer experience for Dependabot alerts

Since we launched Dependabot alerts nearly four years ago, we’ve alerted users on over 425 million potential vulnerabilities in their open source dependencies. However, we haven't invested nearly enough in Dependabot alerts. Driven by your feedback, these changes are the first step towards improving Dependabot alerts.

Latest changes include:

• Ungrouped Dependabot alerts: Dependabot alerts are now displayed individually by advisory and dependency manifest, rather than being grouped by package. Alerts will include more descriptive alert titles, new detailed breakdowns on alert severity scoring, and better linked pull request dialogues in the alerts UI.
• Improved searching and tracking: Each alert will have a unique numeric identifier, which will soon be available via the GraphQL API. The alert index page has also been redesigned so it is easier to search with new filtering options, including a new search filter field with full-text searching of advisories.
• Improvements to the alert lifecycle: Dependabot alerts will now persist and continue to appear under the “Closed” tab in the UI, and later this month, be available via the GraphQL API. As a follow-up to this release, we’ll also be shipping the ability to reopen dismissed alerts.
• Custom roles for GitHub Enterprise Cloud users: Two new permissions to view and dismiss Dependabot alerts can be configured when managing custom repository roles for GitHub Enterprise Cloud users
• Organization-wide reporting: GitHub Advanced Security customers can now view all their Dependabot alerts at the organization-level, in the organization security tab.

We’re continuing to work on addressing your top concerns and feedback for Dependabot, including better APIs, noise filtering, actionability, and configurability of alerts, and more. Please let us know what you think, and continue to share feedback!

Learn more

• Check out our blog post to learn more about our recent ship!

[chrismo]

Is the dismissal reason available anywhere in the UI? It's nice having access to closed items in the Closed tab, but ... it'd be nice to have the reason listed for dismissed items.

[zackfern]

You can see the dismissal reason by hovering over the word "dismissed" on an individual alert page:

[chrismo]

That's subtle, but at least it's there. I suppose with the forthcoming API we'll be able to get better reporting on that in the future?

[erinhav]

We just released some changes today (access state, fixed alerts, and numeric identified via GraphQL API). You can also view dismissReason, dismissedAt, and dismisser for each Dependabot alert via the GraphQL API.

Does that do what you want? We're spec'ing out some improvements to the APIs now, so appreciate your feedback!

[adriandersen]

Did this update break the Vulnerability Alert webhook? Resolving vulnerability alers no longer emits a webhook. @erinhav

[erinhav]

Sorry about that -- a fix just went out, so you can see resolve events again!

[Lawvia]

Hi,
thank you for the great work and continuous improvement for the dependabot. We've been using this feature to tackle the possibility of security breach.

I just want to ask one thing, is there a plan or development on dependabot API so we can list and get the alert list ? I knew its possible to get a list of it from graphQl, but there is no filter method we can implement on it. (ex. getting only critical and open status alert)

thank you

[NikoRaisanen]

Hello, thanks for all the awesome work with Dependabot!

I found the recent change to include “fixed” as a state for dependabot alerts has been super helpful.

I noticed that we have some dependabot alerts in the open status, even though the alert says “No security update is needed as X is no longer vulnerable” (see screenshot). Would it be possible to automatically transition these types of alerts where the package is no longer vulnerable to the fixed or closed status?

To my understanding, dependabot alerts are automatically moved from "open" to "fixed" when the underlying vulnerability is remediated. I think this same workflow would be helpful for cases where the package is no longer vulnerable

Thanks for the amazing contributions to dependabot 🔥

[bradymholt]

It would be helpful to be able to snooze an alert for a period of time.

[AnthonyHerman]

Any plans to implement dismissing at the org level? Our org has started to review some of the noisier ones for our environment and the ability to dismiss those we accept risk on org wide (without iterating through all repos) would be nice.

[GumpSun]

👏👏👏