Updated: August 8, 2019
Reporting Security Concerns to RolloutCD
If you have found a vulnerability in RolloutCD.com, please contact our security team by email at infosec@RolloutCD.com. If you are reporting a sensitive issue, please use our public key to encrypt the information.
We’re confident in our implementation around various aspects of the deployment system. However, security is an ongoing practices that needs to be in place. There could be something that we might have overlooked.
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 RolloutCD
RolloutCD offers both as
- A hosted service that runs on infrastructure we control (SaaS) in a multi-tenant configuration
- A 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. In both cases, RolloutCD takes security very seriously.
RolloutCD 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.
The primary areas of our security practices related to customer data are:
- Source Code
- Runtime Isolation
- Environment Variables (secrets)
- Console Output and Artifacts
- 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 RolloutCD.
When you sign up for RolloutCD, 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 RolloutCD’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.
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
If you need your account canceled and/or your data deleted, please contact us at hi@RolloutCD.com.
Partners with access to your source code
RolloutCD is built on Cloud, and we check out your code onto Cloud Infrastructure machines. If the cloud service becomes vulnerable, your source code may also become vulnerable to accidental disclosure. Cloud Infrastructure providers discusses their security in great detail.
RolloutCD team respects every developer’s code and the trust it has in us. We or Employees don’t have access to any of the build server
Rollout cares more for its security than anything else. If you find about any vulnerability that exist in rollout please write to us at infosec@RolloutCD.com.
We access your server in the most secured way possible with only SSH Key based authentication. Also We do not access your server without your concent.
We encourage you to keep logging enable for your SSH. So that you can easily audit in case of any security incidents.