Repo: Move to GitHub Private Security Reporting

[LeoDog896]

Suggestion

This allows GitHub to handle the process as a neutral third party and automatically file CVEs with Mitre, streamlining the process for typescript-eslint whenever a security vulnerability is found.

Both options can still be available, but GitHub's private security reporting is easier to work with.

Docs link

[bradzacher]

We already have a security policy which is just to privately email us at our (actively monitored) email address. https://github.com/typescript-eslint/typescript-eslint/security/policy Is that not easy enough to work with?

[JoshuaKGoldberg]

As a not-security person I am curious on what the benefits of GitHub's security reporting are. Like, what's the advantage of the dedicated channel over just a private email?

For example, the "Start a temporary private fork" idea is interesting. Is that a strong positive?

[LeoDog896]

Oh absolutely! There are a few benefits:

• Start a temporary fork allows the reporter to collaborate with developers to see if the issue at hand still exists
  • Multiple outsiders can collaborate on the fork (e.g. security research teams)
• GitHub will automatically publish CVEs for the library once the vulnerability has been disclosed, meaning the vulnerability can be automatically sent to other security platforms outside of GitHub (snyk, GitLab, etc..)
  • GitHub also looks for these CVEs (or their GHSAs) and sends notifications to all library users - I think npm audit does this too.
• All reported incidents are available on GitHub's security tab, and it integrates pretty nicely with GitHub notifications

Of course, the downside to using it would be that staff (with higher-level permissions) at GitHub can see these private reports, but they have yet to act in bad faith.

[bradzacher]

I guess I personally wonder if that heavy process is really worth it for our project?

• In the life time of our project (like >7 years?) we've gotten just 1 security report (which was an incorrect report about checked-in credentials).
• We're a local, developer-only tool that has no network access, runs with normal permissions and does not execute untrusted code. Almost all of our input is just a user's code via ESLint.
  • i.e. the surface area for vulns is low and the impact of vulns is low.

[LeoDog896]

Ah, alright! Those concerns make sense - I've seen that private security reporting is generally easier to set up than email (because of the whole manually registering CVEs), but given the security scope of this project, I can see why it may be better to just stay simple with reporting 👍