This is a Controlled Document
Inline with GitLab's regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged.
This procedure applies to vulnerabilities identified in GitLab the product or its dependency projects and ensures implmentation of the Vulnerability Management Standard. This procedure is designed to provide insight into our environments, promote healthy patch management among other preventative best-practices, and remediate risk; all with the end goal to better secure our environments and our product.
The procedure laid out here apply to vulnerabilities identified in GitLab the product or its dependency projects.
During the time period defined for the backlog review issues labeled with security and HackerOne or bug will be reviewed.
For gitlab-org/gitlab project:
Other projects in scope:
| Role | Responsibility |
|---|---|
| Appsec Engineers | The stable counterpart for each development team will be responsible for ensuring the backlog is accurate and assisting the development team review and triage the backlog for their team. For teams with larger backlogs, help will be requested from other engineers. |
| Development | Responsible for reviewing the backlog, triaging, and remediating vulnerabilities according to procedure. |
| Appsec Manager(s) | Responsible for providing support and help make determinations for findings that need additional input. |
| Security Leadership | Responsible for making final determination on risk acceptance (exceptions). |
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 customersOnce the issue is created, a security engineer will set the correct ~group:: and ~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
with ~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 ~group::not_owned
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 ~severity:: and ~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 in the GitLab web application and all other products bundled with our Omnibus packages 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 @gitlab-com/gl-security/appsec.
GitLab products that follow an independent release cycle and are not aligned with the monthly GitLab security release are also required to have a process for developing security fixes and disclosing them to the customers. Either the GitLab security release process or a recommended bare minimum process as below can be followed:
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:
~"security-fix-in-public" label.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.
Fixed vulnerabilities are mentioned in the security release blog posts and it's possible to receive notifications either through email or RSS.
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.
Security issues fixed in GitLab products may be mentioned in the security release blog post only if they are released along with the monthly GitLab security release. All issues that need to be mentioned in the security release blog posts are expected to be linked to the ~"upcoming security release" issue. If linking is not possible, please contact the Security release managers to include security issue in the security release blog post.
GitLab products that follow an independent release cycle and are not aligned with the monthly GitLab security release could make use of CHANGELOG.md file or a separate security advisory file in the project repository to publish details about security fixes in their new releases.
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:
~security-backlog::valid~security-backlog::closed~security-backlog::reclassified~security-backlog::risk-acceptance~security-backlog::needs-input~security-backlog::review-completeFor 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.
The ~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.
~security-backlog::valid labelAn 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.
~security-backlog::closed label/duplicate <#issue> slash command to close issueAn issue is reclassified if it can be considered a ~type::feature, ~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.
~security-backlog::reclassified label~type::bug label and apply the appropriate label.~security 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:
~security-backlog::risk-acceptance labelAn issue needs input if the appsec engineer cannot determine the appropriate category.
~security-backlog::needs-input labelWhen 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:
~type::feature)~type::maintenance)~type::maintenance)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-private project to update the CVE record, and mention @gitlab-org/vulnerability-researchRefer to Vulnerability Management Standard Risk Acceptance (Exceptions)