Skip to main content

Code security

Abstract

Every Bitrise build runs in a new virtual machine that has no access to previous builds. We do not store your source code and you can set up how it is accessed.

To guarantee the security of your code, every Bitrise build runs in its own, clean virtual machine and we discard the whole virtual machine after the build finishes, erasing every file your build uses and every change you make during your build.

This is also true for the Android & Docker stacks, which use Docker containers to run the build. The build itself still gets a full virtual machine where no other Docker container is started, only the one used as the environment of the build. In short, we only use Docker containers to manage the environment, not for build environment isolation - that’s ensured by using full virtual machines for every build.

This way your builds are always protected from changes made by others and from your previous builds, no one else can access your code and you can use a stable environment to define your build Workflow. Every build is completed in an isolated environment, unrelated to any previous or parallelly running builds.

Source code

We don’t store your source code. The source code is only accessed on the build machines (virtual machines) the way you define it in your Bitrise configuration. If you don’t have a Git Clone Step or some other Step that accesses your Git repository in your configuration, then the source code won’t be touched at all. At the end of the build the whole virtual machine is destroyed. As such, any change you made to your source code on the virtual machine will be lost unless you commit your changes and push them to a remote repository.

Code signing and other files

The files you upload in the Code Signing tab of the Workflow Editor are stored on Amazon S3 in a way that it’s only accessible for the web servers.

The required credentials are not stored in any database, it is only available in the web servers’ environment. Build servers can’t access the files directly either. When a build starts, the web server generates a read-only, time limited access URL for these files, using Amazon S3 pre-signed URLs.

Passwords

Passwords are stored in a hashed, encrypted form. We are encrypting the passwords with bcrypt algorithm, using multiple stretches.

In this section:

A build stack indicates the full configuration of the virtual machine that Bitrise uses to run your build. Each stack includes an operating system, and a large number of pre-installed software and tools. For example, our Xcode stacks run on macOS operating systems and contain, among many other tools, the Xcode version that is indicated in the name of the stack.

A Workflow is a collection of Steps, Environment Variables, and other configurations. When Bitrise starts a build, it runs one or more Workflows according to the configuration defined in the bitrise.yml file.

A Step is a block of script execution that encapsulates a build task on Bitrise: the code to perform that task, the inputs and parameters you can define for the task, and the outputs the task generates.

The Bitrise Workflow Editor allows you to edit your Workflows, configure Steps, upload files (including code signing files) and manage your app's triggers and stacks on a graphical user interface. It is available both online and offline.