Grant access to security alerts via the API

Do I understand correctly that granting access to security alerts to teams on a repository level (i.e. that you can configure from the UI under repository settings/Security alerts) is not exposed in the API? I understand that enabling security alerts is, as well as you can get notified of alerts via the API but what if I’d like to grant access to the alerts for the team maintaining the repo?

I’ve asked this here a month ago but didn’t get a reply: https://github.community/t5/GitHub-API-Development-and/Security-vulnerability-alerts/m-p/53504#M4563

Thank you!

4 Likes

I have the same issue. Not being able to specify who can see security alerts via an API is a big oversight when you have 100’s of repositories to manage.

I have the same issue.
Please help

Regards

Hey folks, Dependabot PM here.

The right long term answer here is going to be “custom roles” (Role-based Access Control (RBAC) - Custom Roles with fine-grained repo permissions · Issue #111 · github/roadmap · GitHub), which will allow folks to:

  • create a role like “writer + permissions to read and dismiss dependabot alerts”
  • assign that role to a user or a team

The current UI is basically a workaround of such a feature to grant anyone “read dependabot alerts” so we don’t want to create an API, as it would become irrelevant as soon as custom roles exist.

Hi asciimike,

Here is the timeline of which quarter the roadmap item you refer to would be delivered in, along with whether it was a human or bot that adjusted the estimate.

  • 24 Jul 2020 (bot) - Q4 2020
  • 07 Oct 2020 (bot) - Q1 2021
  • 07 Oct 2020 (not) - Q4 2020
  • 10 Nov 2020 (bot) - Q1 2021
  • 10 Nov 2020 (not) - Q4 2020
  • 02 Dec 2020 (bot) - Q1 2021
  • 02 Dec 2020 (not) - Q4 2020
  • 03 Feb 2021 (not) - Q2 2021
  • 09 Jun 2020 (bot) - Q3 2021

I believe there is the best of intentions in tying this to RBAC, but in doing so it has prevented the delivery of customer value in the context of vulnerable dependency management, and I cannot make any decisions based on the potential delivery of RBAC in Q3 2021, because of the history of it being rescheduled by bots and humans. Additionally, there is no indication in that roadmap item the release of RBAC will include dependabot support.

To be clear, I only want to provide view access to dependabot, though if I have to give access to dismiss then we would. Not being able to share access to dependabot easily with all of our developers is a surefire way to create animosity between teams, and I’m sure GitHub wouldn’t want to encourage that kind of behaviour. (ex: “wow there’s a lot of vulnerable dependencies in this repo!” / “where? I can’t see them!”)

So I reiterate the original issue @piedone, @PaulTurner-awin, and pcortez raised- what is the timeline for API access to dependabot?

Thanks

I’ll let @jamccree comment on the timeline for custom roles, as he knows more about that than me.

I agree that providing view access to Dependabot is important and clearly something that customers want; unfortunately, the path to getting that feature goes through custom roles, as it doesn’t make sense for us to build a second, Dependabot specific version of it.

@asciimike

Can we got an official blessing to script a web browser to turn this on for more accounts?

GitHub Support wouldn’t give it to me when I asked, but after seeing the continually moving timelines, I feel like I have to ask again