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.
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.
~featureas 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
/h1import <report> [project]in Slack
00 - TriagedCommon response as a template.
04 - Bounty Award / Reviewed and Awarded Prior to Fixcan be used as the template for the bounty award if approved.
Please see Handling severity::1/priority::1 Issues
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.
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.
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.
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:
Nameuse the reporters fullname if available, otherwise their H1 handle
H1 Reporter Award
User Countis up to 5
20 - Ultimate License Creationtemplate.
The license will be sent to the reporter by LicenseDot. 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.