Previously, GitLab utilized the email address email@example.com 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
firstname.lastname@example.org 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.
Triage vulnerability reports in a similar manner to our HackerOne process.
Please refer to our public bug bounty program policy at https://hackerone.com/gitlab for more information.
This report will be triaged in the order it was received on the HackerOne platform. That will be used as our single channel of communication for this report.and close the ticket as resolved.
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?"
Following the Responsible Disclosure Policy, a confidential issue will be created and tracked internally. The contents of the confidential issue should not be shared.
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