Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Working with Security

On this page


Overview

Occasionally, users will reach out to security@gitlab.com, 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.


General Guidelines

Support tickets identified as needing transfer to security should be treated with the same caution as any other suspicious email:

Identifying Issues for Transfer to Security

Identifying Issues for Transfer to Support

Workflows

AppSec and Vulnerability Reports

The primary channel we currently receive vulnerability reports is through our HackerOne Bug Bounty, but we still make security@gitlab.com available for reporting as well. Triaging and responding to these tickets in a timely manner is a responsibility of the AppSec Rotation.

If any team member has any concern about a report and an Application Security engineer is not available, page the security on call.

General Guidelines

  1. Always use your Light Agent account when making internal comments. All members of the Security Team should have followed the Light Agent request process as part of their onboarding. When it's necessary to reply or change the status of the ticket use the shared account in 1Password.
  2. Always cross-link any relevant ZenDesk, HackerOne, and GitLab issues, in internal comments where appropriate and available. ZenDesk links in GitLab issues should be noted as "GitLab internal only": Reported via ZenDesk (GitLab internal only): https://gitlab.zendesk.com/.../xxxxx
  3. When responding directly via email, you must include the requester's email address as a recipient, since emails replies to ZenDesk from Light Agent accounts will only be processes as internal notes and not sent to the requester.
  4. If you email directly, you are responsible for setting the ticket to "Solved" or "Pending", or finding someone with permission to do so.
  5. ZenDesk tickets should be responded to in under 1 business day to ensure that any tickets not handled by the Security are identified and reassigned, so the AppSec Engineer on rotation should review the queue once a day for new tickets.

Triage Workflow

Triage vulnerability reports in a similar manner to our HackerOne proccess.

Transfer from Security to Support

In the case that something ended up in the Security inbox and was forwarded on via email:

  1. Open the ticket in ZenDesk.
  2. Depending on the content of the forward, you can usually change the requestor to the user. Sometimes, it's preferable to create a new ticket. In either case, proceed as if it's a regular ticket from a user.
  3. Often, these tickets will lack the name and email address of the user. You can usually find the original email by searching in the #security-alert-manual channel (everything emailed to security [at] is also shared there). Should that search turn up short, feel free to reach out to the individual who forwarded the ticket for this information.

Transfer from Support to Security

In the case that a security issue was reported through a Zendesk support ticket:

  1. Change the Form to Security Issue.

Escalate ZenDesk ticket to Security

In the case that a security issue was reported through a support ticket:

  1. Update the assignee in ZenDesk to Security

  2. Link to the issue reporting the vulnerability

If the customer has already created an issue

In the case that the customer has already filed an issue for the vulnerability:

  1. Mark the issue is confidential

  2. Add security, customer, and bug or feature proposal labels

  3. Assign Severity and Priority Labels

If the customer has not yet created an issue

See Creating New Security Issues