Verifying Security Fixes
The review of a fix by an application security engineer is triggered by the engineer implementing the fix. As the engineer engaging in the verification, these are the steps that should be followed:
- Doing a code review from the security perspective.
- Validating the security fix using the Docker image generated by
package-and-qa, see the section below for more details.
- Once the validation is done, update the security issue with a link to the CVE.
- The link goes in the Summary > Links table of the security implementation issue, next to the cell labeled
CVE ID request
- If the fix does not require a CVE, post in the security implementation issue that no CVE will be requested with the reason why.
- If a CVE was created on import from HackerOne, double check the submission contains up-to-date details
Note: Approval is only required for the merge request targeting
master, it’s not required for the merge requests
targeting a versioned stable branch (
Note: The process described above is particular to validate GitLab fixes. The process to verify fixes for other subcomponents (Omnibus GitLab, Gitaly, and GitLab Pages) might be different.
Validating security fixes using
The relevant application security stable counterpart is responsible for validating the security fixes using the
package-and-qa process described below. The security engineer that triaged the vulnerability report can be involved as necessary or be considered a backup in the event that the stable counterpart is unavailable.
Note: The Delivery team recorded a video about summarizing this process, it’s highly encouraged for AppSec team members to see it.
package-and-qa build runs end-to-end tests against an Omnibus package that is generated from the merge request changes.
In order to validate that the security fix introduced on the merge request remediates the vulnerability, Security engineers will use this package
to spin up a docker image in their local environment.
For that, Security Engineers need to follow these steps:
- On the security merge request, click on the
qastage and then trigger the
- Internally the
package-and-qabuild will trigger a pipeline on the Omnibus GitLab Mirror project.
- On the Omnibus GitLab Mirror pipeline, wait for the
Trigger:gitlab-dockerbuild to finish.
- In the meantime,
- Ensure you’re logged in to
registry.gitlab.com. You can login with your pre-configured Docker credentials, or with a Personal Access Token or a Deploy Token using the command
docker login registry.gitlab.com(or
nerdctl login registry.gitlab.com -u <username>depending on what you’re using).
- Complete the Set up volumes location on the Omnibus
- Ensure you’re logged in to
Trigger:gitlab-dockerhas been completed, scroll down to the end of the log and find the docker image that was pushed to
- To start the docker image on your local environment, follow the documentation and replace the
gitlab/gitlab-ee:latestimage with the one from the previous step.
- Wait for the installation to be completed, and after that, you’ll be able to access the local instance
by going to
0.0.0.0:80in your browser.
- Visit the gitlab-org/cves repository issue tracker. You will be requesting CVEs by making issues using the templates in this repository.
- For each vulnerability (CVSSv3 score > 0) affecting the self-managed version of GitLab, request a CVE identifier by creating a new issue and selecting the
Internal GitLab Submissiontemplate. Please note that some merge requests included in the security release do not require a CVE identifier (e.g., only third-party dependency upgrades, gitlab.com-only issues, etc.).
- The CVSSv3 score should have been approved by at least two team members in the Bug Bounty Council issue. For reports that predate this process, do not hesitate to add a note to the current Council issue only to discuss the CVSSv3 score with other team members.
- If a CVE identifier is almost certainly going to be needed, please check the ‘Automatically request a CVE ID’ box. This will make sure that a CVE identifier is requested at the beginning of the process.
- For the
Titleof each issue, please use the respective vulnerability title that is going to be included in the blog post entry.
reportersection refers to us as requesters of the CVE and not the vulnerability reporter, the default values for those fields should be used.
- Fill in the remaining fields with the relevant information using the template or other previous submissions as examples. Please note that you will likely need to look up the appropriate
cwevalue (see CWE) and also use the CVSSv3 calculator to determine the
- Note: some information, such as
solution, may not be readily available when the CVE request issue is created. Be sure to update the CVE issue once you have that information.
- Submit the issue. It will be reviewed by the vulnerability research team. They will follow up with any questions and then submit it to be assigned a CVE identifier.
- For each CVE request submission, link the relevant security issue to it. Once a CVE identifier is assigned, please also comment with that on the relevant issue and ensure that it gets included in the blog post.
Most vulnerabilities are credited either to a HackerOne researcher or a team member. These reports are always credited using the existing CVE template.
When a vulnerability is reported directly as a GitLab issue or by a customer via ZenDesk, provide an opportunity to be publicly credited:
To update a CVE after it has been published, open a merge request in [https://gitlab.com/gitlab-org/secure/vulnerability-research/advisories/cves-private] which modifies
gitlab-org/secure/vulnerability-research to review and merge. The Vulnerability Research team will then handle updating the CVE with MITRE and/or NVD.