The processes laid out here apply to vulnerabilities identified in GitLab the product or its dependency projects.
Vulnerabilities reports have many sources but always end up as an issue in GitLab.
gitlab-org/gitlab, usually those are reports from GitLab Team Members or customers
Once the issue is created, a security engineer will set the correct
~devops:: labels and
@-mention the engineering and product managers for the team that owns the affected feature.
If there is no obvious group nor stage owning the code affected by the vulnerability, the engineer should avoid labeling
~group::not_owned at this point as this will often lead to missed SLOs because the issues don't show up
in any specific group's dashboards. The security engineer can try to find a group based on the last people who
modified the code by using the git blame
feature or by asking in the
#development Slack channel.
Occasionally the receiving group won't be the correct one, but the security engineer and the group can work together
to find the appropriate group to reassign to. A
~devops:: label is good enough if a
~group:: cannot be determined.
The security engineer should assign the issue to the stage's director/Sr. EM in this case and may apply the
label now that a DRI has been found.
If an issue is judged to not be a vulnerability but rather a security enhancement, it will be made public, labeled
~"type::feature" and the prioritization will be left to the product team as with any other regular issue. (See: Vulnerability vs. Feature vs. Bug?). For vulnerabilities, the security engineer will set the
~priority:: labels and those will determine the due date and SLO for the issue as described in the main Security Engineering page of the handbook.
If the report is a
~severity::1 report, there is a special procedure to follow to engage SIRT and leadership.
Vulnerabilities are fixed following the security release process. GitLab has two types of security releases: a regular monthly release, and a critical security release whenever a
~severity::1 issue is reported. See the Security Releases section of the main Security Engineering handbook page for more information.
If you're working on a vulnerability that you feel could be treated as a security enhancement and skip the security release process, feel free to ping
The Application Security Team may give approval for a security issue to be addressed in public, either wholly or in part. Public issues and MRs must never include information that should remain confidential. Application Security engineers should:
The team monitors for unintended information disclosure via public MRs referencing confidential issues and will delete public branches and MRs that do not follow this process.
Issues that were handled outside of the security release process can be mentioned in the regular release posts if the product manager deems it appropriate.
The application security team will do reviews of the vulnerability backlog to ensure that it accurately reflects the vulnerabilities present in the product. The frequency of these reviews will be determined based on compliance requirements or as determined by the team. The process is intended to determine if open issue are still valid, can be closed, or are eligible for risk acceptance.
Scoped labels will be used to categorize each issue. The labels are as follows:
During the time period defined for the backlog review issues labeled with
bug will be reviewed.
Other projects in scope:
For each issue, it's categorization will need to be determined. The following are guidelines the appsec engineer should follow to determine the appropriate category, and the steps that should be taken.
~security-backlog::review-complete label should be applied to issues that have been reviewed to help us filter and track.
An issue is
valid if it is a vulnerability that continues to be present in the product.
An issue is
closed if it is determined that the issue has previously been fixed,
is a known duplicate of another issue, or is not longer relevant due to evolution of the product.
/duplicate <#issue>slash command to close issue
An issue is
reclassified if it can be considered a
~type::maintenance, or a non-security
~type::bug, based on the evolution of the product, our threat model, or our understanding of the issue. Use the Vulnerability vs. Feature vs. Bug questions below to guide you.
~type::buglabel and apply the appropriate label.
The general guidelines for issues eligible for risk acceptance are laid out below. There is no perfect formula, so the judgement of the engineer will be relied upon.
~"type::maintenance"by the product managers based on a use case? (e.g. Guest user can see a count of X but don't have access to view individual X)
If an issue is eligible for risk acceptance:
needs input if the appsec engineer cannot determine the appropriate category.
When receiving or reclassifying issues, especially S4/P4s, it can be difficult to determine whether it's a vulnerability, an enhancement, or a bug. Here are some questions which might help:
If it's unclear, err on the side of caution, and treat the issue as a vulnerability. The Engineering Work Type Classification page may also serve as a guide.
Occassionally after a release has occurred, a discussion in the AppSec team may lead to a better understanding of a bug and its CVSS. Follow the S1/P1 process if an issue is increased in severity to Critical. Otherwise:
cves-privateproject to update the CVE record, and mention