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:
package-and-qa, see the section below for more details.
CVE ID request
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.
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:
qastage and then trigger the
package-and-qabuild will trigger a pipeline on the Omnibus GitLab Mirror project.
Trigger:gitlab-dockerbuild to finish.
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).
Trigger:gitlab-dockerhas been completed, scroll down to the end of the log and find the docker image that was pushed to
gitlab/gitlab-ee:latestimage with the one from the previous step.
0.0.0.0:80in your browser.
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.).
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.
cwevalue (see CWE) and also use the CVSSv3 calculator to determine the
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.
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.