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.
The #hackerone-feed
Slack channel receives notifications of report status changes and comments via HackerOne's Slack integration.
For information or questions about the GitLab HackerOne program, please contact
If a reporter has questions about the order of report responses, 06 - Duplicates/Invalid Reports Triaged First
common response may be used.
postMessage
issue), 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 - Duplicate
common response. Include the link to the GitLab issue.05 - Duplicate Follow Up, No Adding Contributors/Future Public Release
common 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]
in Slack
h1import
(Severity and PriorityHow to reproduce
section~documentation
label/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 triage00 - Triaged pending further investigation
for reports where the severity or validity is uncertain, and we are discussing with the engineering team.00 - Triaged
for low severity reports, which do not have an initial bounty at the time of triage00 - Triaged with Bounty
for medium, high, and critical reports which do have an initial bounty at time of triageRewards
, 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
02 - Bounty Award
common response04 - Bounty Award / Reviewed and Awarded Prior to Fix
common 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.
We typically request to disclose reports which are unique and interesting, and which will help other researchers learn more about quality reporting. If a researcher requests public disclosure, regardless of quality, we should agree to disclose it (after 30 days) 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.
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 support@hackerone.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.
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:
Triaged
or Resolved
.Hacker One Reporter License
as the request type.
Contact Name
use the reporter's full name if available, otherwise their H1 handleContact Email
use the reporter's [username]@wearehackerone.com
email address20 - Ultimate License Creation
template.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.