Inside Gratipay

This is Gratipay's internal company portal. First time here? Welcome! Start at the top. :-)

Handle Security Issues

Are you a security researcher? Please visit our HackerOne page. This document is for internal Gratipay collaborators.


We use HackerOne to manage our security queue. Our program description lives in this repo. Make changes using GitHub PRs like normal, and then copy and paste into HackerOne once merged.

Be aware of how HackerOne assigns reputation. In particular, if you need to reticket anything from a HackerOne report, have the original researcher make the reticket so that they get the credit. When commenting on HackerOne, always use the “All participants” scope, so that the conversation is made public when we disclose the ticket once it's resolved.

“Request public disclosure” for all HackerOne tickets that you close as “Resolved”, “Informative”, or “Not Applicable”, as soon you close them. If the researcher does not raise any objection, the report will be made public after 30 days. Use this time window to explain our disclosure policy to the researcher if necessary.

Our program uses the CVSS v3.0 severity categories: None, Low, Medium, High, and Critical. Untriaged reports are of unknown severity. When processing the queue, we should tend to work on issues in this order: Critical, High, unknown, Medium, Low, None.

Don't use the “Needs more info” state on HackerOne, because it doesn't show up across the top so it's easy for tickets to get lost in there. Just use “New” (unclear risk) and “Triaged” (in one of the four risk classifications).


We support email as a fall-back reporting mechanism. When we receive disclosures on, ask the researcher to file a report at HackerOne instead. If they are unresponsive or don't want to use HackerOne, then file the issue yourself so we can manage the issue there (you'll get the reputation points in this case). If the researcher doesn't join HackerOne, offer to add them to the old Hall of Fame instead.

Code Changes

For Low- and Medium-severity issues, you may use our normal public GitHub workflow to make code changes (basically, submit a PR, label it “Review”, and ping someone to review it).

Making code changes for High and Critical vulnerabilities is more complex, because we want to avoid telegraphing the presence of such vulnerabilities before they're fixed. Make changes in the security repo in a topic branch. Make a PR (in the same repo) to help with code review, but don't actually comment on GitHub, only comment on HackerOne. Why? We don't have per-PR permissions, so if we have conversation in the security repo then it's not easy to disclose once the bug is fixed. Keep all conversation on HackerOne, so that we can easily make it public when we disclose the issue. If you find comments on PRs in the security repo then please copy them to HackerOne and then delete them from GitHub.

Once the fix is approved and the PR is merged to master in security, here's how to deploy it:

  1. Announce your intention on Slack so that no-one else deploys from the regular repo while you're deploying from security.

  2. Clone the security repo, then configure a couple more remotes:

    git remote add upstream
    git remote add heroku
  3. Run ./ from your local copy of the security repo that has the new fix on master (the deploy script exits if not run on master). After pushing to Heroku, the deploy script will push to master's default remote, which should be the private security repo in this case.

  4. Once the fix is deployed and verified and you're ready to announce it to the world, sync the public repo with the private security repo, like so:

    git push upstream && git push upstream --tags
Table of Contents