Previously, GitLab utilized the email address firstname.lastname@example.org to report and inquire about security concerns. However, as GitLab and our Security Department has grown and expanded, we were unable to provide the high level of service our customers deserve utilizing that singular queue. Users who reach out to
email@example.com will now receive an auto-reply providing them with specific instructions for reporting the various types of security concerns. If the auto-responder does not answer their questions or a security-related ticket is submitted to Support you can utilize the macro
Security::All Security Questions to provide the user with detailed instructions.
Please do not transfer to security and refer to the relevant workflow for the following:
You can also utilize the
Security::All Security Questions macro for more details on the language. If the workflows above and the Macro do not resolve the customer's concern, please post a link to the ticket in the #sec-fieldsecurity Slack Channel.
Vulnerability disclosures are no longer triaged via ZenDesk. When in doubt, please involve the Application Security team.
Sometimes, a customer will request details on a security update that was released. e.g. "Should I worry about this? What's this patch about?".
A summary of GitLab CVEs for specific versions is available in Customer Success' "What's New Since" tool.
If the customer is asking about a security vulnerability published as part of a release, the only information we can provide is what is in the security blog post. For more information on security communication, please see the security incident communication page.
Security will make the issue public if possible after a set number of days.
If you believe more information should be made available in the blog post, or to a specific customer, please open a confidential issue in the security communication tracker.
Note: Confirmed mitigation strategies are typically added to the security blog post. If none are listed, the only recommendation is to upgrade to a version where the issue is fixed. While some suggestions (such as disabling a feature) may seem like they would mitigate an issue, without validation from the security team, we cannot be fully certain.
Following the Responsible Disclosure Policy, see below on reporting a security issue.
Reported via ZenDesk (GitLab internal only): https://gitlab.zendesk.com/.../xxxxx
In the case that the customer has already filed an issue for the vulnerability:
Mark the issue is
feature proposal labels
Assign Severity and Priority Labels