---
layout: handbook-page-toc
title: Working with Security
category: Security
---

## On this page
{:.no_toc .hidden-md .hidden-lg}

- TOC
{:toc .hidden-md .hidden-lg}

## Overview

Occasionally, users will reach out to `security@gitlab.com`, following the [Responsible Disclosure Policy](/security/disclosure/), 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](#identifying-issues-for-transfer-to-security) should be treated with the
same caution as any other suspicious email:

- Don't access any links included, especially if the sender intended to obfuscate links by using something like `hxxp://` or `hxxps://` or 'evil(.).com`.
- If there is any doubt, ask in `#security`, ask your manager or transfer the ticket.
- It's *better* to send along a ticket that Security evaluates and sends back than to mishandle an important report. Be biased to passing things to Security.

### Identifying Issues for Transfer to Security

 * Reports of phishing or malicious content, regardless of hosting source. Keywords:
   * malware/malicious
   * phish
   * campaign
 * Sender claims to be a security related employee at a non-associated company.
 * DMCA Takedown requests
 * Security questionnaires or other requests for documentation.

### Identifying Issues for Transfer to Support

 * User is having problems with 2-factor or other authentication on their account.
 * A vulnerability report that has been triaged by the security team as `working as intended`,
 * Requires actions taken by Support to resolve.

## Workflows

### AppSec and Vulnerability Reports

The primary channel we currently receive vulnerability reports is through our
[HackerOne Bug Bounty](/handbook/engineering/security/#hackerone-process), 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](/handbook/engineering/security/#triage-rotation).

If any team member has *any* concern about a report and an Application Security
engineer is not available, [page the security on call](/handbook/engineering/security/#engaging-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](/handbook/support/internal-support/#light-agent-zendesk-accounts-available-for-all-gitlab-staff)
  as part of their onboarding. When it's necessary to reply or change the
  status of the ticket use the shared account in 1Password.
1. 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`
1. 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.
  1. If you email directly, you are responsible for setting the ticket to
    "Solved" or "Pending", or finding someone with permission to do so.
1. ZenDesk tickets should be responded to in under 1 business day to ensure that
  any tickets not handled by the Security are [identified](#identifying-issues-for-transfer-to-support) 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](/handbook/engineering/security/#hackerone-process).

* If the report would be Not Applicable, reply with the reason why and close as "Solved."
* If the report would be Informative or would be an ~feature, you may ask the the requester to
  file an issue themselves. You can start with the "General -> Ask to create an issue"
  macro.
* If the issue is known, provide a link to the issue. If it is confidential,
    let the reporter know that it will be made non-confidential 30-days after
    a patch is released.
* When closing tickets, include a link to HackerOne program:
  `Please refer to our public bug bounty program policy at https://hackerone.com/gitlab for more information.`
* If the issue appears to be a duplicate of a recent HackerOne report:
  * Add link to the ZD issue as an internal note in the HackerOne report and
      add a link to the HackerOne report as in internal note in the ZD issue,
      along with any comments.
  * If it is clear the report is the same, for example the
      text is identical, or references the HackerOne report with the report number or
      link, respond with ```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.
  * Otherwise, respond with a standard message of the report being a known issue
    that is being worked on.
* If the report is a new, valid issue:
  * If the severity may be an ~S1 or otherwise needs immediate investigation:
    * [page the security on call](/handbook/engineering/security/#engaging-the-security-on-call)
    * Manually create an issue for report following the [creating a security issue instructions](/handbook/engineering/security/#creating-new-security-issues)
  * Otherwise, reply to the reporter to see if they wish to either:
    * Report via HackerOne (if they qualify)
    * Create a confidential issue themselves
    * Have a team member create the issue and reply with their preference for acknowledgement.
    * To ensure timely handling of the report, let the reporter know that if no response
      within 3 business days, a GitLab team member will create the issue.

### 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.
1. 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.
1. 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

1. 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`

1. Add `security`, `customer`, and `bug` or `feature proposal` labels

1. Assign [Severity and Priority Labels](/handbook/engineering/security/#severity-and-priority-labels-on-security-issues)

### If the customer has not yet created an issue

See [Creating New Security Issues](/handbook/engineering/security/#creating-new-security-issues)