Occasionally, users will reach out to
firstname.lastname@example.org, following the Responsible Disclosure Policy, with questions that may be better addressed by Support (e.g., help resizing a repository in response to a mass notification).
Other times, users will reach out to Support to report a security issue.
Support tickets identified as needing transfer to security should be treated with the same caution as any other suspicious email:
#security, ask your manager or transfer the ticket.
working as intended,
The primary channel we currently receive vulnerability reports is through our
HackerOne Bug Bounty, but we still
email@example.com available for reporting as well. Triaging and
responding to these tickets in a timely manner is a responsibility of the
If any team member has any concern about a report and an Application Security engineer is not available, page the security on call.
Reported via ZenDesk (GitLab internal only): https://gitlab.zendesk.com/.../xxxxx
Triage vulnerability reports in a similar manner to our HackerOne proccess.
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.
In the case that something ended up in the Security inbox and was forwarded on via email:
In the case that a security issue was reported through a Zendesk support ticket:
In the case that a security issue was reported through a support ticket:
Update the assignee in ZenDesk to Security
Link to the issue reporting the vulnerability
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