Create a form for reporting vulnerabilities that need a CVE number

Problem to solve

Users will need to report vulnerabilities to and request CVEs from GitLab once we are a CNA. They can do this over email, but that is a slow and manual process that is prone to errors.

Intended users

Further details

Proposal

Create a hosted web form that users can use to report vulnerabilities that they want to be considered for a CVE number. * We decided to move away from the form, since there is a simpler solution possible.

Create an issue template for vulnerability submission inside the GitLab project.

Link to creating a new issue with this template off of the Responsible Disclosure Policy page. Add a link to it is part of the policy that discusses CVEs.

Newly submitted issues must be created as Confidential by default and not require a user to manually specify that. Otherwise, they may forget and inadvertently publicize a live vulnerability.

Fields to collect

Non-optional fields that require user-input

  • Reporter name & contact info
  • Description: (format:text) Description of the problem. The description text has to contain product, version, and problem type information. In the onboarding video, they suggest to use the pattern
[VULNTYPE] in [COMPONENT] in [VENDOR][PRODUCT] [VERSION] allows [ATTACKER] to [IMPACT] via [VECTOR]
  • Product Name (format:text) Name of the affected product.
  • Problem Type (format:text) Ideally this would refer to an existing CWE ID
  • References (format:array of URI strings that adhere to rfc3986) URLs that point to resources related to the CVE request. Based on the CNA rules there should be at least one reference.
  • Versions (format:text) List of affected versions. For simplicity, it would be great if we could use some common/simple notation to express affected version ranges in the UI. For example =v3.0.0 || >v4.1.2, <v5.4.2 where || is a disjunction and , is a conjunction. The CVE JSON format supports many other ways to express version constraints some of which can be quite confusing but using disjunctions of conjunctions should be sufficient in practice.
  • Legal Notice (format:checkbox) I think we need to ask the contributor to accept the CVE's program's Terms of use so that CVEs can be actually published.

Optional fields that are nice-to-have

  • Impact (format:string that adheres to the CVSS specs) The impact is described through a CVSS vector. It would be great if we could integrate something along the lines of https://cvssjs.github.io/ to make the generation of CVSS vectors a bit easier for contributors.
  • Solution (format:text) Description about how to fix the vulnerability.
  • Credit (format:text) Honorable mentions.

Once the form has been submitted, create a new confidential issue with information from the form and automatically assign to the groupvulnerability research team with a label.

  • Question: Should this go in a different project than gitlab-org?

Permissions and Security

Documentation

Availability & Testing

What does success look like, and how can we measure that?

Links / references

Edited by Sam Kerr