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.
For security inquiries or vulnerability reports, please email hello@houndci.com.
Hound is operated by Hound Group LLC, a California limited liability company.
A small team within Hound Group LLC 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.
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 encrypted and encoded
using ActiveSupport::MessageEncryptor and stored in our Postgres database
on Heroku.
ActiveSupport::MessageEncryptor uses aes-256-cbc
for encryption and base64 for encoding.
To browse the portions of the codebase related to authentication,
try greping for the following terms:
grep -R omniauth app
grep -R token appWe 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 Heroku Redis Addon.
As part of this process, we temporarily store your GitHub token in the Redis database when enqueueing a Sidekiq 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.
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-bot GitHub user to your repo via the GitHub collaborator API. @houndci-bot is added as a collaborator to the enabled repository. This is necessary in order for us to be able to make comments as @houndci-bot and to update pull request statuses, or to read file contents if no other valid token is found for the enabled repository.
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 appWhen 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 appWhen 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 StartBuild can prepare configuration
and file contents for each enabled linter, then send the files off for review
via Sidekiq (uses Redis) to the linters service.
StartBuild pulls the payload out of Redis and into Ruby memory on Heroku.
Using the information from the payload, it makes a HTTP requests to GitHub's
REST API to get the pull request's patch and file contents.
Hound never fetches a complete version of your codebase.
In Ruby memory,
StartBuild passes your pull request's contents to ReviewFiles,
which loops through the changed files and delegates to the appropriate
Linter Ruby classes based on file extension (.rb, .js, etc.).
The Linter classes schedule a job on a queue with all the necessary
information (configuration file, file contents to review, and metadata).
The job is then picked up by linters service, which will actually do the
linting using specific open source libraries, like:
Those libraries find code violations
and pass them back up through Sidekiq for CompleteBuild to finish.
The violations are collected in the Violation classes, and also stored in
our PostgreSQL database. SubmitReview fetches them, converts them to a
format that fits GitHub comments, and submits the PR review to GitHub,
to comment about the violations on the pull request.
CompleteFileReview saves each violation, the line number, and patch position,
in the violations table of our Postgres database.
We do not save any of your code in Postgres.
We do store the contents of the files to review temporarily in Sidekiq, and it
gets cleared out as soon as the job is processed.
To browse the portions of the codebase related to
receiving and processing pull request notifications,
try greping for the following terms:
grep -R ReviewFiles app
grep -R CompleteFileReview app
grep -R SubmitReview appAll Hound Group 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 Hound Group 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.
Use environment variables in your code to separate code from configuration.
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.