HackerOne Process

1. You are here:
2. Engineering
3. Security
4. Security Engineering & Research
5. Application Security
6. Application Security Runbooks
7. HackerOne Process

On this page

• HackerOne Process
  • Working the Queue
  • Awards
  • Managing issues
  • Closing out & disclosing issues
  • Application Security Engineer Procedures for severity::1/priority::1 Issues
  • Closing reports as Informative, Not Applicable, or Spam
  • If a Report is Unclear
  • If a Report Violates the Rules of Engagement
  • Breakdown of Effective Communication
  • Reports potentially affecting third parties
  • Awarding Ultimate Licenses

HackerOne Process

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

• James Ritchey - Primary Program Manager, or
• Ethan Strike - Secondary Program Manager

Working the Queue

• When beginning work on a report, the security team member should assign the report to themselves immediately.
• It is OK to take a report that you will not work on immediately, especially if it is a duplicate or related to another report you are familiar with, just be sure to get it reassigned if you won't be able to meet the estimated triage time.
• When starting a triage work cycle, team members should prioritize as follows:
  1. Identify, triage, and escalate any severity::1/priority::1 issues first.
  2. Close duplicate and invalid reports.
  3. Triage further using Sort by "Oldest" reports.

  If a reporter has questions about the order of report responses, 06 - Duplicates/Invalid Reports Triaged First common response may be used.

• Conduct initial communication with the reporter and investigation, using the following guidelines as necessary:
  • Request clarification
  • Attempt to verify the report and triage the vulnerability.
• When a report contains externally-hosted static content for reproduction (for example some HTML file triggering a CSRF or a vulnerability exploiting a postMessage issue), follow the instructions in this project to re-host it internally
• Potential, non-bounty outcomes:
  • Report is out-of-scope. If actionable, issues may still be created, but further process may not be followed see violating the rules.
  • Report is a ~"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".
  • Report is otherwise Informative, Not Applicable, or Spam. For example, we've gotten a number of reports for inline HTML in markdown that do not exceed the capabilities of markdown itself.
  • Report is a duplicate. Verify that the issue was not previously reported in HackerOne, or that an issue does not already exist in GitLab. If it is a duplicate:
    • Change the state of the report to "Duplicate".
    • If the issue was previously reported in H1, include the report id, as it can impact the reporter's reputation
    • Fill in the 01 - Duplicate common response. Include the link to the GitLab issue.
    • The team member may use their discretion if the reporter asks to be added as a contributor to the original H1 report; however, the default is to not add because the corresponding GitLab issue will be made public 30 days after the patch is released. If it is decided to add the duplicate reporter, ensure that the report does not have reporter sensitive information before allowing access. 05 - Duplicate Follow Up, No Adding Contributors/Future Public Release common response can be used when denying the request to add as a contributor.
    • If the new report makes us realize we have mishandled a previous report (e.g. closed as informative but it was a valid bug) we reopen the original and award the new report a bounty to thank the reporter for putting the mishandled issue back on our radar
      • The bounty we award as a thank you should be $100 for low severity reports and equivalent to the initial bounty we pay on triage for the higher severities
      • If we realize our mistake late in the process and we have already rewarded the new report, the bounty should be raised to the amounts above or left as is if it's already higher
      • The author of the duplicate report should also be thanked in the CVE credits and blog post
    • If the new report demonstrates new and higher impact, we calculate the CVSS score and award to the new reporter the difference between the new severity and what was awarded to the original report
• If the report is valid, in-scope, original, and requires action, security-related documentation change, or if the report needs further investigation by the responsible engineering team:
  • Verify and/or set the appropriate Severity in H1
  • Verify and/or set the appropriate Weakness in H1
  • Calculate the CVSS score and post the resulting vector string (e.g.: 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
    • We do not use the HackerOne field for CVSS because our bounties are based on our own assesment of severity and business impact rather than the CVSS score and sometimes those will differ
  • If the report is permissions related, check for similar issues in the API, GraphQL, and Elasticsearch, as appropriate. Also check with alternate authentication mechanisms like Deploy Tokens, Deploy Keys, Trigger Tokens, etc.
  • Add your initial suggested bounty in H1
  • Import the report into a GitLab issue using /h1 import <report> [project] in Slack
    • Verify the Severity/Priority assigned by h1import (Severity and Priority
    • On the imported issue:
      • Assign the appropriate Due Date
      • Have a proper How to reproduce section
    • If the report is a security-related documentation change, add the ~documentation label
  • @-mention product manager of appropriate teams for scheduling and/or the engineering managers if additional engineering feedback is required to complete the triage, based on the product categories page
    • add labels (/label ~ command) corresponding to the DevOps stage and source group (consult the Hierarchy for an overview on categories forming the hierarchy)
    • As applicable, notify relevant team members via the issue, chat, and email, depending on the chosen security level.
  • Change the state of the report to "Triaged" in HackerOne:
    • See GitLab's H1 Policy, under Rewards, for portions of bounty rewards which are awarded at the time of triage
    • Choose from the following common responses:
      • 00 - 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 triage
      • 00 - Triaged with Bounty for medium, high, and critical reports which do have an initial bounty at time of triage
    • In the comment, include link to the confidential issue
  • If full impact is needed to be assessed against GitLab infrastructure, instead of testing in https://gitlab.com, use https://staging.gitlab.com/help to sign in with your GitLab email account
    • If multiple users are needed, use credentials for users gitlab-qa-user* stored in 1password Team Vault to access the staging environment

Awards

• See GitLab's H1 Policy, under Rewards, for portions of bounty rewards which are awarded at the time of triage
  • It is OK to delay awarding at time of triage. Examples are when we aren't sure if a report is intended behaviour, or if it will be a documentation change. Remember to return and make a partial award if/when appropriate.
  • It is OK to have awarded a partial bounty at time of triage and later learn we have overpaid due to an adjustment of validity or severity
• Use the /h1 bounty <report> Slack bot to post a note on the current ~"bug bounty council" issue
  • Add descriptions, similar issues, and other commentary as appropriate
  • Two thumbs up indicate approval of the bug bounty amount
  • Two bug emoji indicate approval of the CVSS string
  • For documentation updates, an award can be paid without waiting for two thumbs up
• After Bug Bounty Council approval:
  • Once a fix is shipped, award the remaining amount (or full amount if none was awarded at time of triage) using the 02 - Bounty Award common response
  • If 30 days have passed since the issue was triaged, the award may be paid in advance of a confirmed fix using the 04 - 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.

Managing issues

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:

• Once the corresponding GitLab issue has been assigned a milestone, an automated process will add a comment to the H1 report with the planned fix date. If the issue has not been assigned to a milestone within 1 week of the product manager being @ mentioned on the issue, follow up with the product management team.
• In the case where fixes are not as clear or discussion is still on-going as to whether a patch will be created at all, reporters should be notified of updates at least monthly.
• In any case, no report should go "stale" where updates are not provided within the last month.

Closing out & disclosing issues

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.

Application Security Engineer Procedures for severity::1/priority::1 Issues

Please see Handling severity::1/priority::1 Issues

Closing reports as Informative, Not Applicable, or Spam

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:

• Informative: Report contained useful information but did not warrant an immediate action.
• Not Applicable: Report was invalid, ineligible, or irrelevant.
• Spam: Report is not a legitimate attempt to describe a security issue.

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

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 Engagement

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.

Breakdown of Effective Communication

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.

• Take a step back from the situation. Do not respond immediately.
• Seek advice from the H1 triage engineer or, if you are more comfortable, a manager on how best to move forward.
• Consider writing the response multiple times, and have the response reviewed by the person you consulted.
• Once diffused, if the general situation is not currently documented, open an MR to the handbook on how it can be handled in the future.

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.

Reports potentially affecting third parties

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.

Awarding Ultimate Licenses

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:

1. Validate that the three reports were valid. That means they are Triaged or Resolved.
2. Validate that the three reports have not been used to obtain a previous license.
3. If the reports are not valid, respond to the reporter on H1 explaining the reason the license is not being issued.
4. If the reports are valid, visit the GitLab Support Internal Requests page and select Hacker One Reporter License as the request type.
   • For Contact Name use the reporter's full name if available, otherwise their H1 handle
   • For Contact Email use the reporter's [username]@wearehackerone.com email address
5. Enter the associated license information in the H1 License Award sheet
6. Reply to the report on H1 use the 20 - 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.