Enforce the "GitHub Recommended" security configuration

[consideRatio]

The Jupyter enterprise is able to enforce a configuration across all Jupyter orgs. In the most recent security meeting, @rpwagner and I discussed working towards adopting this configuration and enforcing it in Jupyter's orgs.

I suggested that I will champion piloting its use in the JupyterHub org, and that we'll followup after we have gained some experience of using it.

Below you can see what the "GitHub recommended" advanced security configuration implies, as seen from an admin view of a GitHub org or the Jupyter enterprise. Note that adopting this would resolve #73.

[minrk]

We talked through enabling this on JupyterHub, and gave it a test by enabling it on jupyterhub/jupyterhub. The only real negative was CodeQL, but I think it's bad enough to be disqualifying.

CodeQL opened 22 issues, Secret scanning opened 4. None were of any consequence, though one was actionable: jupyterhub/jupyterhub#5049 . One of the secret scanning issues revealed a real logging problem in an old Issue comment, but which had been fixed years ago.

The majority of the CodeQL issues were reasonable to flag as "double check this, it might not be safe," but ultimately incorrect. I think it is appropriate to use a static analysis tool that notices these and require looking more closely and marking them explicitly with # noqa notes, etc. But this brought me to what I think makes GitHub Code Security entirely disqualifying: github/codeql#11427 . It is an explicit product choice for force checks to be only dismissible via GitHub UI. This means the only storage for important security information is GitHub itself, not the repo, not public, and not available to any other tool and all information is lost if we move away from GitHub. This is standard user-hostile vendor lock-in behavior.

It appears to be technically possible, though complicated and ultimately unreliable and unavailable with default configuration, to enable this most basic feature. It seems relevant to note that when GitHub Code Scanning swallowed the original LGTM, they removed this feature, which appears to have already been working for some time on LGTM.

As a result, I do not believe we (or anyone, really) should use CodeQL (or specifically GitHub Code Scanning) anywhere, in JupyterHub or any Jupyter project, and we can use better tools like bandit that more appropriately align with open source goals. I think we as a project should have an official recommendation against GitHub Code Security, at least until they choose to address github/codeql#11427 (comment) .

So I think it's fine to enable a default policy, and I think everything except Code Scanning in the default policy is fine.

[krassowski]

It looks like we could start from the smallest possible set of configurations, for example just enforcing that private security reporting is enabled, solving:

• Enable GitHub feature to report vulnerabilities privately #73
• Create Security manager teams for all Jupyter Orgs that have the same people everywhere.  #68 (comment)

[krassowski]

@jupyter/security does anyone object to enabling private vulnerability reporting across Jupyter Enterprise? If I do not hear an objection within a week I will submit a request to EC to enable it so that we can close #73.

[krassowski]

Feedback from EC:

• "First send an email"
• "Deadline"
• "How it impacts me?"
• "How does it change my life?"

[krassowski]

During the meeting from EC the example of how 2FA was introduced was given as a good practice. This makes the bar to implement any changes higher. I understand that for 2FA there was:

• blog post
• discourse post
• announcements on team compass repos of subprojects

I do not think that the bar should be as high as for 2FA as 2FA meant that some users would have been kicked out of repos. This does not change membership, nor privileges.