Upon discovering a vulnerability, we ask that you act in a way to protect our users' data:

Inform us as soon as possible.

Test against fake data and accounts, not our users' private data (please ask if you'd like a free account to work on this).

Work with us to close the vulnerability before disclosing it to others.

Overview of Security at CircleCI

CircleCI offers both a hosted service that runs on infrastructure we control (SaaS) in a multi-tenant configuration and installed software (Behind the Firewall) that runs in single-tenant installations on infrastructure controlled by our customers. These two modalities have very different security considerations, particularly in regards to access by CircleCI personnel. For specific concerns related to running behind your firewall, see our Enterprise security documentation. In both cases, CircleCI takes security very seriously.

CircleCI approaches security first and foremost to protect our customer’s intellectual property and sensitive keys, tokens, and other sensitive secrets. We employ a variety of safeguards to isolate and encrypt customer data and use a tiered security model to protect sensitive customer information such as deployment credentials. We employ layers of access control to prevent unauthorized access to our underlying infrastructure. We also implement application-level security to ensure access to build information and code goes only to those who are authorized.

Source Code Security

We use oAuth to GitHub and/or Bitbucket as our primary authentication mechanism and mirror the permissions to code in those systems. If a user has read/write access to a repository in GitHub, they have access to the configuration and information about that repository in CircleCI.

When you sign up for CircleCI, you tell GitHub or Bitbucket that you are authorizing us to check out your private repositories. You may revoke this permission at any time through your GitHub settings page or Bitbucket settings page by removing CircleCI's Deploy Keys and Service Hooks from your repository's Admin page.

Access by our systems to your source code is always encrypted over the wire using SSH and/or HTTPS.

To run your tests, we check out your code from GitHub or Bitbucket. In many cases, we may cache the code within our infrastructure. In both cases, access to the code and all cached versions of code is based on user tokens that match user permissions from GitHub or BitBucket.

Runtime Isolation

When we run your tests on our own machines, we run them in a secure sandbox, either a Docker/LXC container or a virtual machine. You are unable to access another customer's code or runtime environment and they are unable to access yours.

Each sandbox is firewalled, and it is not possible to access a sandbox from another sandbox, or from the Internet at large. Each job starts in a fresh sandbox, and each sandbox is destroyed after each job, preventing leaking of secrets or other sensitive information from inside the runtime to other jobs.

All communication between our systems and the runtime environment are encrypted over the wire using SSH and/or HTTPS.

Environment Variables (Secrets)

Environment variables are the typical mechanism most of customers use to store and provide various tokens, keys, and other secrets to the runtime environment for doing deployments, integrating with 3rd-party systems, etc. We store all environment variables encrypted at rest associated with a specific repository in source control. Access to environment variables is restricted only to those with access to the repo associated with the environment variables. Environment variables are unencrypted and injected into the runtime environment when each job starts and disappear after the sandbox running the job disappears after the job if finished.

Console Output and Artifacts

Console output of your jobs is stored in our databases and made available only to those with read access to the underlying repositories. Artifacts are stored in private S3 buckets and available only by authenticated users with read access to the underlying repository. In both cases, encryption is employed over the wire using SSH and/or HTTPS.

Canceling Your Account or Deleting Data

Partners with access to your source code

CircleCI is built on Amazon EC2, and we check out your code onto Amazon's EC2 machines. If the EC2 service becomes vulnerable, your source code may also become vulnerable to accidental disclosure.
Amazon's Security Center discusses their security in great detail.

Other partners

A small number of partners, who we choose not to enumerate for security reasons, have access to small amounts of our customer data. We constantly audit the data that is provided to them to ensure that this could not be used to gain access to your account or your code.

Security Researcher Hall of Fame

We maintain a Security Researcher Hall of Fame to thank individuals who have discovered medium or high vulnerabilities and worked with us to resolve them.

To be included on this list, responsibly disclose a security report to us, and provide adequate time to fix the issue. We'd be happy to link to your professional website and/or send you CircleCI schwag.

Feedback

We take data security matters seriously. If you have a concern or suggestion to improve our security (or improve this policy) please contact us at
security@circleci.com.