Handle Security Issues
Are you a security researcher? Please visit our HackerOne page. This document is for internal Gratipay collaborators.
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 email@example.com, 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.
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
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
Once the fix is approved and the PR is merged to
how to deploy it:
Announce your intention on Slack so that no-one else deploys from the regular repo while you're deploying from
securityrepo, then configure a couple more remotes:
git remote add upstream firstname.lastname@example.org:gratipay/gratipay.com.git git remote add heroku email@example.com:gratipay.git
./deploy.shfrom your local copy of the
securityrepo 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
securityrepo in this case.
Once the fix is deployed and verified and you're ready to announce it to the world, sync the public
gratipay.comrepo with the private
securityrepo, like so:
git push upstream && git push upstream --tags