Handling GitHub Security Advisories

Community
1

There’s been some discussion on how to manage security issues through the GitHub Security Advisory mechanism.

The hardest part about this is that there are two steps (“Accept” from third party, “Request CVE”) that should be low-threshold, but from the way GitHub sets up things can only be done by members of a group whose role is Admin. We should keep Admin small because this grants a bunch of other privileges that a) probably not everyone should have, and b) people may not even want (like, I prefer to keep my privileges low for accounts I’m logged in with a lot).

The current proposal for workflow with these is:

  • User reports a GSA
  • Someone in the Owners or Maintainers does a few cheap steps
    • Check whether the report is spam or plausibly a RIOT security issue. This doesn’t need to be thorough, like, no need to read any code, just reject if someone is obviously trolling. If it’s good,
    • add a particular group to the report (see below)
    • click “accept”
    • click “request CVE” (unless one is assigned already, in which case the button is not there anyway)
  • From there, maintainers can take it – adding comments, interacting with the reporter, editing the advisory, possibly going through the private fork which is yet something to be explored.
  • When a fixed version is released, we’ll need someone from Owners or Maintainers again.

If the current Owners and Maintainers can do the assignment steps, I’d be glad to have the security group (currently just Kaspar and me) removed again, as it gives me more rights than I should have – but if not, I can stay there to help with the triage.

An open question is which group should be assigned – I wouldn’t view this as a secrecy concern (security issues are regularly discussed on the riot-maintainers channel; being a maintainer is good enough here) but as a concern of being pinged about every new security issue. What do you prefer there?

  • Assign “all maintainers” to security issues (eg. because I prefer everyone to push security issues to the group)
  • Assign a new subgroup of maintainers to security issues (eg. because I don’t want to be pinged about every security issue)
  • Don’t care (eg. because I would enter the security team anyway and thus receive notifications)

0 voters

2

I didn’t know github could assign CVEs… it’s great news, because MITRE’s processes were really annoying. (even after I figured out how to edit the overly complicated JSON) This process you describe tends to assign CVEs early, which is very good, but might assign them needlessly. That can be annoying, but I suggest doing it anyway. We had a few cases in TCPDUMP where we assigned CVEs for things that turned out not to be a problem, and some distros got upset, and I had to say shove it.

3

Yeah, I’m also on “better assign one needlessly than reject an actual one”. We can still set the severity to minimal in hindsight.

I learned meanwhile that the threshold for being a CNA (CVE Numbering Authority; organization that assigns CVEs, such as Mitre and now GitHub) is rather low: Many Linux distros, and even the Zephyr project are their own CNAs. No contract or money transfer involved. We could even do it ourselves, and hand out CVEs of our own. (I think that practically we still don’t get a block, but we’d get a form at Mitre where we don’t have to block on them).

But it’s still some administrative effort, which GitHub takes away for us – so, meh. (As: I’m still happy with the current road of allowing both handling issues via GitHub and via the mailing list. But I’m happier now that if Mitre continues to suck and GitHub shows us too many ads on security, we have an easier way out).

4

I did this in 2019 for tcpdump. I can’t recommend it. It can turn into about a 1/10 of a FTE of overhead. That’s fine if you are putting out a few hundred CVEs/year, but at <20, we’ll be using the github button from now on.

1 Like