Security Best Practices At Shippable

- By Manisha Sahasrabudhe on October 11, 2017

In light of a recent blog post about a competitor's security vulnerabilities, I wanted to be completely transparent about our security best practices to reassure our customers that they're in good hands.

From the start, we've been very aware of the fact that when customers click on the Authorize button to grant us access to their GitHub or Bitbucket repositories, they trust us with their Intellectual Property.  This is a tremendous step, especially since we're all aware of hackers attacking almost every major site and stealing personal information.

Our security measures fall under two pillars, Product and Process, both of which are explained below.

Security through Product

 We have the following safeguards in place from a product perspective:

1. Separate domains for Marketing Website, Docs, Blog, and App

This approach effectively silos the needs of every domain. For example, we use Intercom on our marketing and docs pages, but not on our actual product pages that have access to your tokens or other sensitive information.

This also allows us to enforce the strict rule of not adding Javascript from any third-party analytics companies to our product page loads

Screen Shot 2017-10-10 at 8.59.32 PM.png

 

2. Integrations to connect to third-party services

Most CI/CD providers offer a way for you to encrypt your secrets so that you're not forced to include passwords, token, and other sensitive information in plain text your automation scripts. At Shippable as well, we support secure environment variables which are encrypted key:value pairs you can use in your configuration.

However, we believe that encrypted strings are problematic due to the unwieldiness of managing a completely meaningless sequence of characters. For example:

Screen Shot 2017-10-10 at 9.55.09 PM.png

To improve the experience around handling secrets, we have introduced the concept of Integrations, which allow users to store their sensitive information with a friendly name that can be used to configure CI or Assembly Line workflows. These Integrations are encrypted at rest and in flight, and are stored in our Vault

For more on the advantages of using Integrations, read our docs here

 

3. No separate Shippable Account

We do not require you to create a separate account for Shippable, and instead support sign-in through OAuth with GitHub, Bitbucket, and Gitlab.  As a result, we do not request any sensitive information or store anything unless it been allowed to be publicly shared as part of your source control system. 

We do cache the authorization token provided by  GitHub/Bitbucket/Gitlab, but this can be invalidated with a single action which will force you to redo the authentication process. We also store SSH keys that can access your source control repositories, but they are encrypted at rest in Vault and only available during the build process on the builder node.

 

4. No storage of credit card information

If you want to upgrade your Subscription to a paid plan, someone with Admin privileges for that  Subscription needs to set up billing/payment processing. Nobody else from your organization has any access to billing information. To handle payments, we use Braintree, which is a PCI compliant 3rd party service. Shippable does not store any information pertaining to credit cards other than a Transaction ID which is used to identity the information on Braintree.

 

5. Build security

When a build is triggered, we spin up a build node and pull your source code on your build node. This is a transient node that is permanently destroyed if there is more than a maximum of 50 minutes of idle time.

Results of a build like logs, reports etc. are stored in our DB or S3 bucket. S3 buckets are secured for every single customer with separate keys and the DB is not accessible to anyone other than the API and operations team.

All build artifacts are deleted permanently when a repo is disabled or a build is deleted.

 

6. Custom Nodes and Shippable Server

For customers who cannot use a SaaS service for compliance reasons or personal preference, we offer two alternatives:

  • Custom Nodes, where all the build orchestration happens through SaaS but the actual build nodes can be on-premises behind your firewall with no incoming traffic initiated from our SaaS service, and,
  • Shippable Server, our Enterprise solution that you can install and manage behind your firewall

 

Security through Process

Regardless of the steps we take from a product perspective, we also make sure we have the right processes in place with respect to who has access to what.

Our operations team consists of 5 people who are all Full Time employees of Shippable Inc and Shippable India Pvt Ltd, a wholly owned subsidiary of Shippable Inc. All the members of operations team undergo security as well as PII training and they sign an additional security policy and guidelines document in addition to the employment agreement. 

Nobody other than our Operations team has Admin access to Shippable. If a customers opens a support ticket which requires our developers to access build logs or any other information, they go through a request process which includes asking the customer for permission. 

I think I've covered everything but if you have any questions or concerns, please don't hesitate to reach out! I'm always available for a chat :)

Topics: continuous integration (CI), devops, continuous delivery, security