How to Secure Android & iOS Apps in Bitrise CI/CD Pipelines

This Knowledge Base article provides instructions for using the Appdome Build-2Secure step for Bitrise CI/CD pipelines. Appdome’s Build-2Secure step for Bitrise is an out-of-the-box Bitrise CI/CD integration, making it easy for mobile developers to automate the building, signing, and certification of security, anti-fraud, and other protections in Android & iOS apps in Bitrise CI/CD pipelines. No code and no SDKs are required.

The purpose of Appdome’s Build-2Secure step for Bitrise is to streamline and accelerate cyber and anti-fraud delivery in CI/CD pipelines. To do this, the Build-2Secure step for Bitrise automates three important steps in delivering more secure mobile applications to your users fast: (1) building app-level protections into mobile apps, (2) code signing the protected mobile app, and (3) certifying the security of each protected mobile app. The Appdome Build-2Secure step for Bitrise can be used to deliver Certifed Secure™ mobile app security, anti-fraud, anti-malware, mobile anti-bot, and other cyber defense updates to mobile apps on the Appdome Cyber Defense Automation Platform. Use this step for Bitrise as a stand-alone DevSecOps integration or in combination with other DevSecOps integrations in your CI/CD pipeline.

For more general information on Bitrise Workflow Steps, see Managing Tools on the Bitrise website. 

Below are the step-by-step instructions on using the Appdome Build-2Secure step for Bitrise. Enjoy!

Prerequisites to Appdome’s Build-2Secure Step for Bitrise

Before you begin using Appdome with Bitrise you’ll need to have:

• An Appdome SRM account
• Appdome API token
• Fusion-Set ID
• A Bitrise account

Step 1: Getting Started with Build-2Secure Step for Bitrise

The Appdome Build-2Secure step takes the unprotected application file (apk, aab or ipa), rebuilds the file, and signs it by using the On-Appdome platform, based on the selected fusion set and signature method. This step can be performed either as part of an existing workflow or as a new workflow where you must provide the application file as part of the input for this step.

If you already have an existing Workflow, you can skip to Step 3.

Step 2: Creating a New Workflow for Build-2Secure Step in Bitrise

You can use Appdome’s Build-2Secure step as part of your existing workflow. If you already have a workflow and you’d like to add Appdome’s Build-2Secure step in, you can skip this section and move to step 3.

To create a workflow with Appdome Build-2Secure:

1. Log in to Bitrise and go to the dashboard.

   A list of your current mobile app projects is displayed on the right side of the screen.

   

2. Select the requested app from the apps list. If your app is not on the list, follow the Bitrise process for adding an app. In this example, android-demo-app is selected. After you select a project, a build history screen is displayed.
   
   
3. Click the Workflows button on the top right side of the screen to display the Workflow Editor screen.
   
   By default, every app has two pre-defined workflows: primary and deploy, which are automatically generated by Bitrise. The images above only display the default primary workflow. When using an existing workflow, it is important to add the Appdome Build-2Secure step to be in the correct position in the flow, namely:
   • After the build step which generates a valid (apk/aab/ipa) file
   • Before the build artifact has been signed and deployed
   • While you can add the Appdome Build-2Secure step into any existing workflow, for the sake of simplicity this document specifies creating a new workflow for building and signing an existing app file.
4. Click the + sign near the WORKFLOW to create a new workflow. The Add new workflow dialog box is displayed.
   

5. Provide a workflow name. In this example, the name Appdome_Build_Sign is used.

   

6. Select the value Empty workflow from the Based on: list, as shown below.
   A new workflow named Appdome_Build_Sign is created

   

7. Click the Save button (on the top right corner). Alternatively, click ⌘ +S for Mac or Ctrl+S for PC. After the save is completed, the button’s color will change to gray and to Saved label.
    Note: For Android apps, Bitrise selects by default a medium-sized Android & Docker on Ubuntu stack machine. For iOS apps, Bitrise selects a medium-sized Apple Silicon M1 based Xcode, on macOS. You can change the stack type and size by going to Stacks & Machines bar and selecting a different stack or a different size. However, Appdome Build-2Secure step itself does not require more than the default stack.As a first step in the new example workflow, add the Appdome Build-2Secure step from the Bitrise steps repository.

Step 3: Adding Build-2Secure Step to Bitrise Workflow

The following example shows the process of adding Appdome’s Build-2Secure step to a newly created empty workflow. However, when adding Appdome’s Build-2Secure step to an existing workflow, it must be added in the correct position, i.e after the build step which has generated a valid app (apk/aab/ipa) file, and before the build artifact has been signed and deployed.

To add a Build-2Secure step to the Bitrise flow:

1. Add a new step by clicking on the + icon on the left side of the screen, in the step section (below the workflow name). A dialog box appears, displaying all Android valid steps.
   Note: Ensure that you do not click the + icon to the right of the workflow name, as this will result in opening a dialog box for adding a new workflow. If you click this icon by mistake, click Esc to abort the action. The screenshots below are relevant to Android-related steps. If your workflow is designed for an iOS app only steps relevant to iOS will be displayed.
   
   Note: The black icon on the right of the search bar, which displays the platform for which the displayed steps are relevant.
2. Use the Search steps field to perform the following operations:
   1. Type Appdome Build-2Secure.
      
   2. Click on this field after it is found. The new Appdome Build-2Secure step is added to your workflow.
   3. Click the Save button on the top right corner. Alternatively, click ⌘+S for Mac or Ctrl+S for PC. After the save is completed, the button’s color will change to gray and to Saved label.

   4. Optional step: If you wish for the build output files to be automatically placed in the artifacts section, add the “Deploy to Bitrise.io – Build Artifacts, Test Reports, and Pipeline intermediate files” step, by selecting it from the steps library:

      Click on the + sign on the left side of the screen, in the step section (just below the Appdome_Build-2Secure step).
      A new window with the available steps library will be displayed on the right.
      This step is valid for Android and iOS apps.

      
      Once selected, it will be added to your workflow as the last step.

      
      Note: This step is optional as the build outputs will be represented in environment variables, as described in the last chapter.

   5. Click the Save button (on the top right corner). Alternatively, click ⌘+S for Mac or Ctrl+S for PC. After the save is completed, the button’s color changes to gray and to Saved label.

Step 4: Configuring Bitrise Environmental Variables in the App Workflow

This section provides instructions for configuring Bitrise environment variables, which you can refer to later in the Configuration:

1. Click the Code Signing & Files tab. This tab allows you to store code signature-related files (for example, certificates and provisioning profiles). The bottom part of the tab allows you to upload generic files.
   Note: As both the Keystore File and the Generic File Storage sections allow file sizes of up to 5MB each, it is not possible to upload an app file here.
2. Upload the project signature-related files in accordance with your project type.
3. For an Android app project:
   When signing an Android app project by using On-Appdome method, Android Keystore file must be uploaded by following the steps below.
   Note: Signing Android apps by using Private-Signing or Auto-Dev-Signing methods does not require any file upload. If you are not planning to use On-Appdome signing for your Android apps, you can skip to step no. 3 – Define Secrets.
   1. Upload the Android Keystore file to the ANDROID KEYSTORE FILE section, by clicking Upload file. After the file has been uploaded, its name will be displayed under the ANDROID KEYSTORE FILE section. Bitrise automatically assigns an environment variable to this field.
      
   2. Enter the keystore password in its assigned field. Bitrise automatically assigns an environment variable to this field.
   3. Enter the keystore alias in its assigned field. Bitrise automatically assigns an environment variable to this field.
   4. Enter the private key password in its assigned field. Bitrise automatically assigns an environment variable to this field.
   5. When done, click Save metadata.
4. For an iOS app project: The Code Signing & Files screen looks different than the one for Android. Follow the steps below.
   1. Upload the provisioning profile file to the PROVISIONING PROFILE section. After the file has been uploaded, its name is displayed in this section. You can upload up to 60 provisioning profile files to the platform, each with a maximum size of 5MB.
      
      Note: Bitrise platform supports up to 60 provisioning files. If you have uploaded multiple certificate files and not all of them are required for a specific build, you will be able to specify which files to use for signing later, during the step configuration process.
   2. If On-Appdome signing method is planned to be used for app signing, you need to upload the .p12 certificate file to the CODE SIGNING CERTIFICATES section and enter the file password in the PASSWORD field.
      Note: If you plan to use only Private-Signing or Auto-Dev-Signing methods, uploading .p12 certificate file is not required. After the certificate file has been uploaded, its details are displayed under the CODE SIGNING CERTIFICATES section.
      
      Note: Though Bitrise platform supports up to 60 certificate files, Appdome_Build-2secure step supports only one certificate file. If you have uploaded multiple certificate files, you can specify which file to use for signing later, during the step configuration process.
   3. Entitlement files should be uploaded to the GENERIC FILE STORAGE section at the bottom of the screen. You can upload up to five entitlement files (up to 5MB each).
   4. Before uploading a file, you must provide it with a unique ID in the File Storage ID field.
      
      In this example, the File Storage ID assigned to the entitlements file is ENTITLEMENTS_1.
      Note: Uploading the file is only possible after providing File Storage ID.
      
   5. Upload your entitlements file by clicking on the Upload file.
      Note: Bitrise may alter the ID you have provided to the file. Its final name will be displayed marked in green below the file name after it had been uploaded. In this example, Bitrise has assigned it the variable name $BITRISEIO_ENTITLEMENTS_1_URL. This name will be the environment variable referred to in the workflow.
      
      You can upload up to five entitlement files (up to 5MB each).Ensure that you give each entitlement file a unique file storage ID, and mind the variable name Bitrise had assigned to it.
   6. Define Secrets: Secrets are environmental variables that hold sensitive data. These are securely stored in the Bitrise platform.

      1. Click the Secrets tab.

         

      2. Click Add new.
         
      3. Define a Key named APPDOME_API_KEY with the value of your Appdome API token.
      4. Click Save.
      5. Click Add New.
      6. Define a Key named GOOGLE_PLAY_FINGERPRINT. This key is required if you are building an Android app project that is planned to be uploaded to Google Play. This variable should be holding your Google Play fingerprint.

      7. Define a Key named SIGN_FINGERPRINT. If Google Play signature is not required, then this variable should be holding your signing fingerprint.

         

Step 5: Configuring the Appdome Build-2Secure Step

To configure the input variables for the Appdome Build-2Secure Step:

1. Click the Appdome Build-2Secure step. The right side of the screen displays details about the step, as well as the required input variables.
   
2. Fill-in the parameters as listed below.
   1. App file URL (mandatory) 
      App file (apk/aab/ipa) location to be built and signed by On-Appdome. This field can be a URL address of an external location or an environment variable indicating the file location.
      Note: You can define your own environment variables under the Env Vars tab. If you are using the Appdome Build-2Secure step as part of an existing workflow, this field should be populated with the output of the previous step; for example, $BITRISE_APK_PATH, $BITRISE_AAB_PATH, and $BITRISE_IPA_PATH.

   2. Fusion Set ID (mandatory)
      Appdome fusion set ID. Ensure that this ID is valid for the type of project you are using (Android/iOS).

   3. Team ID (optional)
      The team ID on the On-Appdome platform.
   4. Select Signing Method (mandatory)
      Use the Signing Method field to select the appropriate method for signing your app. Each signing method requires additional parameters, as detailed below.

1. 1. 1. For An Android app project with On-Appdome signing method:
         1. Android Keystore file, Keystore password, Keystore alias, and Private key password.

            These mandatory parameters were already defined in the Code Signing & Files tab and are taken from there.

         2. Google Signing > Google Play Signing (Android only)
            To add the Google Signing parameters, click on the Google Signing category to expand it.
            Set to true if Google Play signing is required, or false if not. If set to true, Google Sign Fingerprint must be provided (see below).

            

         3. Google Signing > Google Sign Fingerprint (Android only)
            Google Sign Fingerprint or enter a Secret name holding your Google Sign Fingerprint. This field is mandatory if Google Play Signing is set to true.
         4. Private/Auto-Dev Signing -> Sign Fingerprint (Android only)
            This field is only applicable for Private or Auto-Dev Signing. For On-Appdome signing this field can be left blank.

      2. For an Android app project with Private-Signing /Auto-Dev-Signing method.

         1. Google Signing > Google Play Signing (Android only)
            Set to true if Google Play signing is required, or false if not.
            If set to true, Google Sign Fingerprint must be provided (see below). To configure the Google Signing parameters, click on the Goggle Signing category to expand it.
            Set to true if Google Play signing is required, or false if not.
            If set to true, Google Sign Fingerprint must be provided (see below).

            

         2. Google Signing > Google Sign Fingerprint (Android only)
            Google Sign Fingerprint or enter a Secret name holding your Google Sign Fingerprint. This field is mandatory if Google Play Signing is set to true.
            
         3. Private/Auto-Dev Signing -> Sign Fingerprint (Android only)
            If Google Play Signing is set to false, you can enter here your private Signing Fingerprint or a Secret holding it.
      3.  For an iOS app project with On-Appdome signing method:
         1. Code signing certificates (.p12) file name (iOS only) – Code signing .p12 certificate file, which was previously uploaded to the Code Signing & Files tab.
            Appdome signing supports only one certificate file, so if you have uploaded multiple certificate files you must specify which file to use in the Code signing certificates (.p12) file name field.
            
            Note: If this field is not populated, the first uploaded code signing certificate to the Code Signing & Files section will be used. If you are not sure about the certificate’s file name, you can determine it by the following actions:
            • • Go to the Code Signing & Files tab
              • Scroll down to the Code Signing Certificates section
              • Locate the desired certificate
              • Click on the three dots on its right, a menu will be displayed
              • Select Download
              • The certificate file will be downloaded to your computer
              • The downloaded file name (including its extension) is the certificate file name to be used
         2. Provisioning profile file name/s (Optional, iOS only) – Enter the provisioning profile file name/s to be used for this build, From the files which you have previously uploaded to the Provisioning Profile section under the Code Signing & Files tab.
            Note: If this field is not populated, all the uploaded provisioning profiles to the Code Signing & Files section will be used.
            You can enter multiple provisioning profiles separated by commas (no file extensions needed). The file names must be exactly the same as they appear in the Provisioning Profile section under the Code Signing & Files tab. Spaces in file names are supported.
            
         3. iOS Entitlement EnvVar/s (iOS only) – If iOS Entitlements are provided, they will be used for signing the iOS app. You should enter the environmental variable names of the entitlement files you want to use, and which you previously uploaded to the Generic File Storage section under Code Signing & Files tab. For multiple entitlement files, you can enter multiple names separated by space.
      4. For an iOS app project with Private-Signing/Auto-Dev-Signing method:
         1. 1. Provisioning Profile (iOS only) – Enter the provisioning profile file name/s to be used for this build, From the files which you have previously uploaded to the Provisioning Profile section under the Code Signing & Files tab.
               Note: If this field is not populated, all the uploaded provisioning profiles to the Code Signing & Files section will be used.
               You can enter multiple provisioning profiles separated by commas (no file extensions needed).
               The file names must be exactly the same as they appear in the Provisioning Profile section under the Code Signing & Files tab. Spaces in file names are supported.
            2. iOS Entitlement EnvVar/s (iOS only) – If iOS Entitlements are provided, they will be used for signing the iOS app. You should enter the environmental variable names of the entitlement files you want to use, and which you previously uploaded to the Generic File Storage section under Code Signing & Files tab. For multiple entitlement files, you can enter multiple names separated by space.
      5. Secondary Output (Android only)
         Set to true if your app type is .aab and you require a secondary output in a form of a secured universal apk file. The output file will always be named as “Appdome_Universal.apk” and will be represented by the $APPDOME_SECURED_SO_PATH environment variable. This option applies only to Android type builds with .aab app types, when using On-Appdome or Private Signing methods.
      6. Build With Diagnostic Logs
         Set to true if you want to build with diagnostics logs.
      7. Build to test Vendor
         Some protected builds cannot run or be tested on real device clouds due to the nature of the vendor’s cloud environment. By selecting a device cloud vendor, the build will be suitable for testing on the selected vendor. You will not be able to run this build on other vendors or on an end user device. For production or general purpose builds select None.
         Note: Use this option only for testing purposes on one of the selectable cloud vendors. For other purposes select None.
         

Step 6: Run the Workflow – Build & Sign Android & iOS Security with Build-2Secure

Click the Run Workflow purple button on the right.
Note: If several workflows are available, ensure that you run the correct workflow.

If you are required to provide a branch name for your build, enter the branch name and click Run Workflow.

A new window will be displayed, showing the build and sign process log.

The Appdome Build-2secure will automatically listen for the build and sign commands sent from Bitrise and add the mobile app security, anti-fraud, and other protections to your Android or iOS mobile app as specified in the Fusion Set associated with this app.

Step 7: Retrieve DevSecOps Certification with Build-2Secure Step

Congratulations! you can now use your secured mobile app.

Related Articles:

• How to Secure Android & iOS Apps in Jenkins CI/CD pipelines
• How to Secure Android & iOS Apps in GitLab CI/CD Pipelines
• How to Use Secure Android & iOS Apps in GitHub CI/CD

Conclusion

Need Additional Help? 

The description above is designed to help you secure Android & IOS apps in Bitrise CI/CD pipelines. If you have any questions, please send them our way at support@appdome.com or via the chat window on the Appdome platform.

Thank you!

Thanks for visiting Appdome! Our mission is to secure every app on the planet by making mobile app security easy. We hope we’re living up to the mission with your project.