GitLab utilizes HackerOne for its bug bounty program. Security researchers can report vulnerabilities in GitLab applications or the GitLab infrastructure via the HackerOne website. Team members authorized to respond to HackerOne reports use procedures outlined here.
#hackerone-feed Slack channel receives notifications of report status changes and comments via HackerOne's Slack integration.
Newcontains all reports in the New state
GitLab Teamcontains reports that have been validated by the HackerOne triage team, but are yet to be assigned to a specific GitLab team member
H1 Triageare reports being triaged by the HackerOne triage team
Pending Disclosureare reports that should be reviewed and disclosed
GitLab's bug bounty program is managed by HackerOne. The HackerOne triage team are the first responders, and will work with researchers to validate reports before assigning to
We usually trust the HackerOne Triage Team and don't necessarily validate the report a second time. There are however cases when the GitLab team member on rotation may want to re-validate it, for example (non exhaustive list):
If a reporter has questions about the order of report responses,
06 - Duplicates/Invalid Reports Triaged First common response may be used.
postMessageissue), follow the instructions in this project to re-host it internally
~"type::feature"as defined above and would not need to be made confidential or scheduled for remediation. An issue can be created, or requested that the reporter creates one if desired, but the report can be closed as "Informative".
01 - Duplicatecommon response. Include the link to the GitLab issue.
05 - Duplicate Follow Up, No Adding Contributors/Future Public Releasecommon response can be used when denying the request to add as a contributor.
AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L) as an internal comment on the report, this will be used later when requesting a CVE ID
/h1 import <report> [project] [options]in Slack
h1import(Severity and Priority)
How to reproducesection
/label ~command) corresponding to the DevOps stage and source group (consult the Hierarchy for an overview on categories forming the hierarchy)
Rewards, for portions of bounty rewards which are awarded at the time of triage
00 - Triaged pending further investigationfor reports where the severity or validity is uncertain, and we are discussing with the engineering team.
00 - Triagedfor low severity reports, which do not have an initial bounty at the time of triage
00 - Triaged with Bountyfor medium, high, and critical reports which do have an initial bounty at time of triage
Pending Disclosuretab and follow our disclosure process
Exposure of information and secrets is handled a little differently to vulnerabilities, as there is nothing to patch and therefore no need for a GitLab Project Issue, CVSS, or CVE. When a leak occurs:
/securityslack command to initiate an incident
https://gitlab.com/gitlab-sirt/incident_XXXX/-/issues/1the reference should be
/h1 bounty REPORT_IDto create a comment on the Bug Bounty Council issue
Sometimes researchers will report a vulnerability in features behind a feature flag. These reports are excellent as they allow us to patch vulnerabilities prior to them affecting our wider audience that utilizes the default settings. These bounties are eligible for the full amount of their calculated bounty.
For a CVSS, use
AC:H to reflect that "A certain setting has to have a non-default value to make the attack possible".
Vulnerabilities in deprecated features are triaged normally. See discussion for more information.
DNS record takeovers typically require multiple teams in order to triage. The workflow is slightly different:
/h1 import $REPORT infrastructure
/securityin Slack. This will allow SIRT to perform their investigatory duties related to this type of attack.
@sre-oncallin Slack. This notifies the SRE (but does not intiate a PagerDuty ping) on-call of a situation requiring their attention. In the relevant SIRT issue, the responder should be added to the issue by the GitLab SIRT. Remediation of this vulnerability happens within the SIRT issue and typically involves deleting the dangling CNAME record. For issues involving MX record takeovers we typically work with our MX SaaS vendor, Mailgun to obtain control of the record. More information on MX record takeovers can be found here.
Rewards, for portions of bounty rewards which are awarded at the time of triage
/h1 bounty <report>Slack bot to post a note on the current ~"bug bounty council" issue
#sec-appsecwhen your note has not received enough votes
04 - Bounty Award / Reviewed and Awarded Prior to Fixcommon response.
02 - Bounty Awardcommon response
We can award GitLab swag to reporters who have submitted a quality report that did not qualify for a monetary reward in our Bug Bounty program. To award swag, please follow the swag nomination process that is managed by our Community Relations team.
Discussion and remediation of vulnerabilities can sometimes take longer than we would prefer. Even so, frequent communication with reporters is far better than leaving reporters in the dark, even if our progress is slow. Therefore:
When a patch is released and the award process complete, it is time to close the HackerOne issue.
After 30 days, follow the process for disclosing security issues. Once this has occurred, the HackerOne issue can also be publicly disclosed on a case-by-case basis, following the same process to remove sensitive information. We should not disclose, or request to disclose, a HackerOne issue while the GitLab issue remains confidential.
Comments made by GitLab Security Bot (
@gitlab-securitybot) can be redacted by AppSec or SecAuto team members using the
/h1 redact <comment_url> Slack command.
To create a HackerOne Hactivity page which will help other researchers learn more about quality reporting we welcome disclosure of resolved reports which are unique and interesting.
If a researcher requests public disclosure of a closed non-resolved
report (e.g. Informative or Not Applicable), we opt to cancel
disclosure requests using the
08 - Canceled Disclosure Message
template. Reporters should instead consider opening a public GitLab
issue as this is the best
way to raise and address non-vulnerability issues.
If a researcher insists on disclosure via HackerOne we should agree to disclose it regardless of quality unless there is a good reason not to.
Please see Handling severity::1/priority::1 Issues
If the report does not pose a security risk to GitLab or GitLab users it can be closed without opening an issue on GitLab.com.
When this happens inform the researcher why it is not a vulnerability. It is up to the discretion of the Security Engineer whether to close the report as "Informative", "Not Applicable", or "Spam". HackerOne offers the following guidelines on each of these statuses:
We mostly use the "Informative" status for reports with little to no security impact to GitLab and "Not Applicable" for reports that show a poor understanding of security concepts or reports that are clearly out of scope. "Spam" results in the maximum penalty to the researcher's reputation and should only be used in obvious cases of abuse.
It may be appropriate to suggest opening a public GitLab Issue for reproducible bugs that are not vulnerabilities.
If a report is unclear, or the reviewer has any questions about the validity of the finding or how it can be exploited, now is the time to ask. Move the report to the "Needs More Info" state until the researcher has provided all the information necessary to determine the validity and impact of the finding. Use your best judgement to determine whether it makes sense to open a confidential issue anyway, noting in it that you are seeking more information from the reporter. When in doubt, err on the side of opening the issue.
One the report has been clarified, follow the "regular flow" described above.
If a report violates the rules of GitLab's bug bounty program use good judgement in deciding how to proceed. For instance, if a researcher has tested a vulnerability against GitLab production systems (a violation), but the vulnerability has not placed GitLab user data at risk, notify them that they have violated the terms of the bounty program but you are still taking the report seriously and will treat it normally. If the researcher has acted in a dangerous or malicious way, inform them that they have violated the terms of the bug bounty program and will not receive credit. Then continue with the "regular flow" as you normally would.
Sometimes there will be a breakdown in effective communication with a reporter. While this could happen for multiple reasons, it is important that further communication follows GitLab's Guidelines for Effective and Responsible Communication. If communication with a reporter has gotten to this point, the following steps should be taken to help meet this goal.
Where appropriate, follow HackerOne's "See something, say something" policy as described in their Code of Conduct. Use a "Team Only" comment on this issue in question and
@ mention the HackerOne triager, email
email@example.com, or ask an AppSec team member to reach out direct via the HackerOne Customer Slack.
When GitLab receives reports, via HackerOne or other means, which might affect third parties the reporter will be encouraged to report the vulnerabilities upstream. On a case-by-case basis, e.g. for urgent or critical issues, GitLab might proactively report security issues upstream while being transparent to the reporter and making sure the original reporter will be credited. GitLab team members however will not attempt to re-apply unique techniques observed from bug bounty related submissions towards unrelated third parties which might be affected.
Vulnerabilities on third-party software are accepted according to the following rules, as stated in our HackerOne policy: The report includes a new vulnerability, for which a patch is not available, or
This does not include websites of third party software and services and only includes dependencies & packaged software.
GitLab reporters with 3 or more valid reports are eligible for a 1-year Ultimate license for up to 5 users. As per the H1 policy, reporters will request the license through a comment on one of their issues. When a reporter has requested a license, the following steps should be taken:
Hacker One Reporter Licenseas the request type.
Contact Nameuse the reporter's full name if available, otherwise their H1 handle
Contact Emailuse the reporter's
20 - Ultimate License Creationtemplate.
The license will be sent to the reporter by CustomersDot. If the reporter claims that the license has not arrived, the app can be used to resend the license. When that happens, the creation of a new license should be avoided.
Members of the public can ask questions about our HackerOne bug bounty program here: https://gitlab.com/gitlab-com/gl-security/appsec/hackerone-questions/. Note that this repository is not the place to discuss or disclose reports and vulnerabilities.
All members of the HackerOne triage team have access to GitLab Ultimate licenses. HackerOne will inform us annually when the license needs to be renewed.
Two new licenses are needed for our HackerOne Triage+ team. This team helps us triage HackerOne reports and will need at least two licenses with 50 users each. They need ultimate licenses to validate reports affecting any feature of the product. License 1: `firstname.lastname@example.org` License 2: `email@example.com` Company: HackerOne Inc. License type: Ultimate Number of users for each license: 50 License duration: 1 year