Extend GitHub's CNA scope

No se identifica ningún archivo del repositorio, prueba ni punto de entrada de la implementación. Empieza revisando el alcance actual de CNA de GitHub y la CVE enlazada y las discusiones de los maintainers; se consideraría terminado cuando un maintainer decida si la política debe cambiar y cómo.

(Possibly this is the wrong place for this request; in that case please point me to where I should request this instead)

TLDR: Extend GitHub's CNA scope so that MITRE or other CNAs cannot file bogus CVE entries for GitHub projects anymore.

In the past there have been multiple bogus CVE IDs assigned for projects on GitHub where the maintainers were either not properly informed, or not informed at all. Some examples are:

• CVE-2023-45960
  (and discussion in https://github.com/dom4j/dom4j/issues/171)
• CVE-2023-35116
  (and discussion in https://github.com/FasterXML/jackson-databind/issues/3972)
• CVE-2023-26750
  (and discussion in https://github.com/yiisoft/yii2/issues/19755)
• CVE-2022-37598
  (and discussion in https://github.com/mishoo/UglifyJS/issues/5699#issuecomment-1316153329)
• CVE-2022-33124
  (and discussion in https://github.com/aio-libs/aiohttp/issues/6772)
• CVE-2020-19909
  (and blog post https://daniel.haxx.se/blog/2023/09/05/bogus-cve-follow-ups/ by maintainer)

In all those cases MITRE was the CNA who assigned the CVE ID.

These CVE entries harm everyone involved:

• The reputation of MITRE (possibly also the GitHub Advisory Database) and the whole CVE system is damaged, see the discussions in the GitHub issues above
• Maintainers: Have to invest a lot of time clarifying with users that this is not a vulnerability, and having a hard time contacting MITRE to get the CVE rejected or marked as disputed
• Users:
  • Are confused that their security tooling inform them about a vulnerability in their dependencies without a fix version and then have to read the discussions to understand why this is not actually considered an issue
  • Have to configure their tooling to ignore certain CVEs; this is possibly error-prone if they suppress it too extensively and suppress all CVEs for a dependency

The CVE site describes MITRE as "CNA of Last Resort" for vulnerabilities which are "not already covered by a CNA listed on this website".
Some of the affected projects (curl and Jackson) are now considering to become their own CNA just to prevent bogus CVEs filed against their projects. This is certainly not the solution to this issue, otherwise you end up with hundreds or thousands of CNAs, and being their own CNA probably also adds additional work for project maintainers.

Nowadays many popular GitHub projects have their own procedure for how vulnerabilities should be reported (described in SECURITY.md files), and are working together with other CNAs, such as HackerOne to handle vulnerability reports.

Additionally, every GitHub project can request a CVE ID themselves, see the documentation.

The CNA scope of GitHub is currently:

GitHub currently only covers CVEs requested by software maintainers using the GitHub Security Advisories feature

Maybe this should be extended so that other CNAs cannot by default file CVEs for GitHub projects, except for rare cases like arbitration or for unmaintained repositories, or when these CNAs are working together with the maintainers already, e.g. HackerOne for some repositories.

For comparison, GitLab's CNA scope is more extensive:

The GitLab application, any project hosted on GitLab.com in a public repository, and any vulnerabilities discovered by GitLab that are not in another CNA’s scope

And in the past years the only disputed CVE for a project hosted on GitLab I could find was CVE-2022-35414, and that actually seems to be reasonable report.
Possibly my script to find these CVEs was not reliable enough, or maybe there are not as much projects on GitLab as on GitHub, but it could also indicate that their CNA scope did actually prevent bogus CVE requests.

I have also sent a similar request to MITRE asking them to reject CVE requests for GitHub projects in most cases and tell the requester to contact the repository maintainers instead, with the same reasoning mentioned above.

What do you think?

Maybe there are current cases though where some maintainers don't want to request a CVE ID themselves, and prefer if the reporter does this. Though possibly because the maintainers are not aware that they can use GitHub Advisories to request a CVE ID?