Permalink
257 lines (189 sloc) 8.89 KB

Security

This document is intended to help our customers' security, risk, compliance, or developer teams evaluate what we do with our customers' code and data.

Because Hound is open source, in this document we refer to portions of the application code and its dependent libraries, frameworks, and programming languages.

Vulnerability Reporting

For security inquiries or vulnerability reports, please email security@thoughtbot.com. If you'd like, you can use our PGP key when reporting vulnerabilities.

thoughtbot

Hound is operated by thoughtbot, inc., a Massachusetts corporation.

A small team within thoughtbot is responsible for Hound. We can't afford to hire a third party security company to audit Hound, but the codebase is open source. We believe that transparency and this document can help keep Hound as secure as possible.

What happens when you authenticate your GitHub account

Hound uses the OmniAuth GitHub Ruby gem to authenticate your GitHub account using GitHub's OAuth2 flow and provide Hound with a GitHub token.

Using OAuth2 means we do not access your GitHub password and that you can revoke our access at any time.

Your GitHub token is needed in order to fetch file content, comments, repo information and update Pull Request status. This token is stored in our Postgres database on Heroku and is base64 encoded using a protected key.

To browse the portions of the codebase related to authentication, try greping for the following terms:

grep -R omniauth app
grep -R github_token app

What happens when Hound refreshes your GitHub repositories

We pass your GitHub token to our Ruby on Rails app (the app whose source code you are reading right now), which runs on Heroku.

Our app passes your GitHub token from memory in RepoSyncsController to our Redis database, as part of scheduling a background job (RepoSynchronizationJob). The Redis database is hosted by Redis to Go.

As part of this process, we temporarily store your GitHub token in the Redis database when enqueueing a Resque job to fetch a list of your repos.

Heroku is a "Platform as a Service", which runs on Amazon Web Services' "Infrastructure as a Service." Read Heroku's security policy for information about their security assessments, compliance, penetration testing, environmental safeguards, network security, and more.

Refreshing your GitHub repos allows you to later enable Hound on those repos.

What happens when you enable Hound on your GitHub repository

When you click the "Activate" button in the Hound web interface for one of your private GitHub repositories, we send your GitHub token from the web browser's session to the Ruby process on Heroku through the SubscriptionsController.

We use your GitHub token to add the @houndci GitHub user to your repository via the GitHub collaborator API. @houndci will be added to a team that has access to the enabled repository. If an existing team cannot be found, we'll create a "Services" team with push access to the enabled repository. This is necessary for @houndci to see pull requests, make comments, and update pull request statuses.

We also create a webhook on your repository via the GitHub webhook API. This allows us to receive pull request notifications.

To browse the portions of the codebase related to enabling repos, try greping for the following terms:

grep -R add_hound_to_repo app
grep -R create_webhook app

What happens when you pay for Hound

When you enable a private GitHub repo with Hound, we use Stripe Checkout to collect and send your credit card information to Stripe, a payment processor.

Your credit card data is sent directly from your web browser to Stripe over a TLS connection. It is never sent through Hound's Ruby processes and we never store your credit card information.

We receive a token from Stripe that represents a unique reference to your credit card within the context of Hound's application. We store that token in our Postgres database.

Read Stripe's security policy for information about PCI compliance, TLS, encryption, and more.

To browse the portions of the codebase related to payment, try greping for the following terms:

grep -R card_token app
grep -R stripe_customer app

What happens when we receive a pull request notification

When you open a pull request on your GitHub repo, or push a new commit to the branch for that pull request, Hound receives the payload in the BuildsController. This payload doesn't contain any code. It contains metadata about the pull request such as repo, user, and commit.

The payload is stored in Redis so that BuildRunner can check style on it in a background job.

BuildRunner pulls the payload out of Redis and back into Ruby memory on Heroku. Using the information from the payload, it makes a new HTTP request to GitHub's API to get the pull request's patch and file contents. Hound never fetches a complete version of your codebase.

In Ruby memory, BuildRunner passes your pull request's contents to StyleChecker, which loops through the changed files and delegates to the appropriate StyleGuide Ruby classes based on file extension (.rb, .js, etc.).

The StyleGuide classes wrap the language-specific open source libraries that we use to check the style of the code in each pull request notification:

Those libraries find style violations and pass them back up through StyleGuide and BuildRunner. The violations are collected in the Violations class, which is passed to Commenter, which uses the GitHub commenting API to comment about the violations on the pull request.

BuildRunner also saves the violations, the pull request number, and the commit SHA in the builds table of our Postgres database. This saves the line number and a reference line number to GitHub's patch. We do not save any of your code in Postgres, or Redis. It only lives in the memory of the Ruby process.

To browse the portions of the codebase related to receiving and processing pull request notifications, try greping for the following terms:

grep -R StyleChecker app
grep -R Commenter app

Employee access

All thoughtbot employees have access to change Hound's source code (the repo you're reading right now, which is open source) and to push it to GitHub.

All thoughtbot employees have access to Hound's staging and production Heroku applications and databases. They can deploy new code, or read and write to the databases.

What you can do to make your Hound use safer

Use environment variables in your code to separate code from configuration.

Third-party auditing

We can't afford to hire a third party security company to audit Hound, but the codebase is open source. We believe that transparency and this document can help keep Hound as secure as possible.