This document is intended to help our customers' security, risk, compliance, or developer teams evaluate what we do with our customers' code and data.
In this document we refer to portions of the application code and its dependent libraries, frameworks, and programming languages.
For security inquiries, please email firstname.lastname@example.org.
Stickler CI uses the github3.py to authenticate your GitHub account using GitHub’s OAuth2 flow and provide Stickler 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 MySQL database on DigitalOcean.
Our frontend application uses your GitHub token and synchronously fetches all your repositories, syncing only repository metadata to our MySQL database. Refreshing your GitHub repos allows you to later enable Stickler CI on those repos.
When you click the "Enable" button in the Stickler CI web interface for one of your private GitHub repositories, we use your GitHub token to add the
@sticklerci GitHub user to your repository via the GitHub collaborator API. This is necessary for
@sticklerci 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.
When you enable a private GitHub repo with Stickler CI, 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 Stickler CI's servers 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 Stickler CI’s application. We store that token in our database.
Read Stripe’s security policy for information about PCI compliance, TLS, encryption, and more.
When you open a pull request on your GitHub repo, or push a new commit to the branch for that pull request, Stickler CI receives the payload a enqueues a job in RabbitMQ with a subset of the payload. This payload doesn't contain any code. It contains metadata about the pull request such as repo, user, and commit.
A review consumer gets the message from RabbitMQ. Using the information from the payload, it creates a docker container to review your code. The created container has no shared volumes and is automatically deleted once the review process is complete. The review process clones your repository. This is necessary, as several linting tools use configuration files or custom rules that are contained in your source code.
In python, the reviewer executes the required linting tools in subprocesses capturing and processing their results. Violations are collected and submitted to GitHub through the commenting API.
Once the review is complete, the docker container and all your code is deleted from our servers.
All Stickler CI employees have access to change Stickler’s source code and to push it to GitHub.
All Stickler CI employees have access to Stickler’s staging and production applications and databases. They can deploy new code, or read and write to the databases.