Trial GitHub vulnerability reporting

[minrk]

GitHub can allow private vulnerability reporting, which means any GitHub user can start a draft repository.

This is not available by default, we have to enable it (the org-level setting doesn't appear to exist despite being documented, but scripting enabling via the API shouldn't be a huge pain and only needs to be done once).

jupyter/security has begun accepting these advisories on the jupyter/security repo, one of which led to JupyterHub 4.1. It's nice to be able to go straight into a draft advisory, without needing to ask email folks for their github handle to migrate from security@ipython email to the advisory.

In that process, where advisories are opened on jupyter/security, migrating is a bit of a pain because advisories cannot be migrated, and really need to be attached tot he appropriate repo on GitHub (the vulnerability discussions on the jupyter/security org cannot be migrated, and are private, so often few people can actually see both places). This isn't really different from alternative of starting from email. It would probably be smoothest if reporters could open advisories

The only disadvantage I see of enabling this on all repos is the possibility that a draft advisory on one repo might be missed, as it would create more places for maintainers to watch. We could also trial just enabling it on the most likely repos, e.g. jupyterhub, z2jh, oauthenticator.

Tasks:

• enable private vulnerability setting on repos
• update security policy to point to draft advisory link instead of email

related to #716

cc @rpwagner

[manics]

Sounds fine to me. We're already (in theory!) watching all repos for PRs and issues, so also watching for security advisorys isn't additional work. In the unlikely event it turns out to be a problem we could have a daily GitHub workflow to compile a private list- or maybe this sort of centralised reporting across all organisations is something jupyter/security could do anyway?

[minrk]

I don't think there's any view to see all draft advisories on an org, so if a draft is opened and falls off of our radar before resolving, there is nothing raising its visibility, and nowhere to check other than visiting the security page of all possible repos. We do know that we don't keep up with all issues, especially on lower traffic repos, so there is a risk of that for draft advisories as well. Security issues are generally rare enough and high priority, so I don't think this is especially likely, just a possible issue to keep track of.

We could construct a view from the security advisories api via a workflow, like you said. But it would need to be private.

[minrk]

I'd like to roll this out. I suppose it means a PR to security.md for every repo. Do we want to have a vulnerability-reporting doc in this repo that they link to?

Private advisory reporting can be enabled across all org repos with the gh cli:

for repo in $(gh repo list --no-archived --visibility public --source --limit 999 jupyterhub --json nameWithOwner | jq -r '.[].nameWithOwner'); do
  echo $repo;
  gh api --silent --method PUT /repos/$repo/private-vulnerability-reporting
done

and all draft/triage advisories can be viewed with (very slow - perfect use case for graphQL, but repository advisories don't appear to be in the graphQL API):

for repo in $(gh repo list --no-archived --visibility public --source --limit 999 jupyterhub --json nameWithOwner | jq -r '.[].nameWithOwner'); do
  for state in triage draft; do
    gh api "/repos/$repo/security-advisories?state=$state" | jq '.[] | {html_url, state, summary, created_at}' || break
  done
done

[sgibson91]

Is it worth centralising the security.md file into a .github repo, or are they all different? https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/creating-a-default-community-health-file

[minrk]

Yeah, I think we should do that.