Skip to content

Instantly share code, notes, and snippets.

@oreoshake
Created July 2, 2018 15:46
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save oreoshake/7e3a57fbe65aae2f096aabd2b00bdc85 to your computer and use it in GitHub Desktop.
Save oreoshake/7e3a57fbe65aae2f096aabd2b00bdc85 to your computer and use it in GitHub Desktop.

GitHub's bug bounty workflow with chatops and slack integration

We make heavy use of bounty platform features such as common responses, interstitials, and chatops so we can respond, filter, and manage reports. This is the actual workflow that is described at a high level on the GitHub Engineering blog

Passive commands

These commands won't change any state but they can be helpful when working with the other commands.

  • .bounty responses [common_response_id] lists or shows common responses. Many of the commands accept a common_response_id that will be used to deliver consistent messaging to researchers.
  • .appsec-new will show all reports that have not been triaged.

New report comes in

  • Message sent to #appsec, the primary room for appsec/prodsec + lurkers (and often those responsible for sensitive code).
  • Anyone around can make a quick decision to dismiss a report.
    • .bounty spam <report id>
    • .bounty na <h1 report id> [common_response_id] (Default: "No Risk")
    • .bounty info <h1 report id> [common_response_id] (Default: "No Risk")
    • .bounty dup <h1 report id> [common_response_id] (Default: "Known issue (prior to Hackerone transition)")

We have found that we can dismiss a large number of reports immediately based on the title and the description that is posted to #appsec. Anyone can do this, so the obvious spam/garbage reports are handled quickly without having to open up email or the web interface. If we find ourselves frequently issuing these commands (especially dup) for the same type of report we would decide whether or not we can add or improve an interstitial. Sometimes we have an issue that predates our transition to a bounty platform in which case we don't have a report to link it to.

The report is deemed valid or worth more investigation

We issue .bounty investigating <h1 report id> | <"*"> to mark one or all issues as receiving 👀. We don't do this just to make our response time look good, we do it when someone is going through the queue. We have a one-person rotation that changes daily. This person is primarily responsible for handling bounty submissions for the day - if only to triage the issue and escalate, but typically seeing it through to resolution. The investigating command will leave a common response mentioning that we're looking into it.

Triage

If we can clearly tell that the issue is legitimate or someone has confirmed the issue, we use .bounty triage --stealth <h1 report id> <repo> [common_response_id]. This will create an issue in <repo> and include the contents of the report. If the --stealth flag is not supplied, it will also comment and let the reporter know that we have validated and triaged. We use the --stealth flag if we need to escalate internally to validate the report.

"Thank you" payouts

From time to time, we discover issues that we deem insignificant but valid. Or issues that may have turned out to be invalid or mitigated by some unforeseen control that pointed to a potential weakness or unexpected code path. We may thank the reporter for inspiring work that may not be related to the original report ($555). We also have a informal policy that if a report leads to changes, it deserves a payout sometimes including out of scope items ($200).

.bounty thanks <h1 report id> <amount> (200, 555) will close the report and reward the researcher with money and swag.

Resolved issue payouts

.gh-bounty payout <h1 report id> <amount> awards money and swag (managed by our swag team) to the reporter, marks the issue as resolved, leaves a common response on the report. We also apply coupons based on current promotions with .bounty coupon <github username> <coupon_name>("hacktheworld" | "lifetime"). Turns out giving away free repositories can help entice researchers to look at your bounty program.

After the bounty

This section is very specific to GitHub. We don't disclose on bounty platforms.

Assuming no breach occurs, we move on to writing up the more significant bugs. .bounty writeup <h1 report id> <github_username> [writeup_repo] (Default: "github/bounty") and creates a pull request in the repository that contains the code for https://bounty.github.com. It fills out as much frontmatter as possible to populate things like the leaderboard, badges, and more. The person resolving the issue then writes a short summary of the bug and an explanation about the resolution. After 👍 the site is updated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment