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.