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

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

The purpose of Appdome’s Build-2Secure Integration for GitLab is to streamline and accelerate cyber and anti-fraud delivery in CI/CD pipelines. To do this, the Build-2Secure Integration for GitLab 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 Integration for GitLab can be used to deliver Certified 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 integration for GitLab as a stand-alone DevSecOps integration or in combination with other DevSecOps integrations in your CI/CD pipeline. 

Here are the step-by-step instructions on using the Appdome Build-2Secure Integration for GitLab. Enjoy!

Prerequisites​

• An Appdome SRM account
  1. Appdome Build-2Secure API token

  2. Fusion Set’s ID

• A Gitlab account
• As Appdome Build-2Secure is a Docker-based solution, you will also need a Docker-based Gitlab runner. See below instructions:
  • How to install GitLab Runner
  • How to register the new runner
    The tag you choose during the runner registration process will be used later.

Step 1: Create a new Gitlab repository or use an existing repository

Step 2: Configure the Build-2Secure GitLab Integration

1. Retrieve the Appdome Build-2Secure API Token by copying it, as described in the article Getting and resetting your API Token.
2. Define CI/CD variables in the GitLab UI by following the steps below.

1. 1. On the menu on the left, click Settings > CI/CD.
      
      
   2. Click Expand to expand the Variables section.
      
      
   3. Click Add variable.
      
   4. Fill in the variables as seen in the image below.
      – Key: APPDOME_API_KEY
      – Value: <YOUR_APPDOME_TOKEN>
      – Type: Variable
   5. Click Add variable.
      
   6. Add your iOS or Android Fusion Set ID to Gitlab environment variables:

• • • For iOS apps, add the following variables:
      • Key: APPDOME_IOS_FS_ID
      • Value: <Appdome_Fusion_Set_ID_FOR_iOS>
    • For Android apps, add the following variables:
      • Key: APPDOME_ANDROID_FS_ID
        • • • Value: <Appdome_Fusion_Set_ID_FOR_ANDROID>

Step 3: Add the Appdome Build-2Secure Integration job to your GitLab pipeline

1. Create a file called .gitlab-ci.yml in your repository if such a file does not yet exist.
   Note:
   You can create a new .gitlab-ci.yml file by clicking Set up CI\CD in your repository gitlab web page.
   
   

   Below is a complete example for using GitLab build-2Secure that you can copy. The following steps provide more detail on how to complete each section of the file.
   

   image: appdome/gitlab_build-2secure
   
   stages:
     - appdome
   
   appdome-job:
     stage: appdome
     tags:
       - <Your runner tag>
     variables:
       APP_LOCATION: "app.apk"
     script:
       - appdome_android_sign_on_appdome
     artifacts:
       paths:
         - ./appdome_outputs/
       expire_in: 1 week

2. Specify the usage of appdome/gitlab_build-2secure docker image.

   image: appdome/gitlab_build-2secure

3. Declare a new stage for the appdome build process.

   stages:
     - appdome

4. Declare a new job in the pipeline.

   appdome-job:
     stage: appdome

5. Specify the runner that will execute the Appdome build-2secure job (same runner from section No.1).

   tags:
       - automation-docker

6. Set the required inputs. For details, see Appendix B, Possible Input Types.

   variables:
       APP_LOCATION: "app.apk"

Step 4: Code Sign Mobile Apps with Build-2Secure Integration

Declare the operation you want to perform out of the following types of operations. When the job runs, GitLab CI initiates Appdome Build-2Secure.

• appdome_android_sign_on_appdome
  For further information, follow the instructions in the Knowledge Base article How to Code Sign Secured Android Apps in DevSecOps Build System.
• appdome_android_private_signing
  For further information, follow the instructions in the Knowledge Base article How To Privately Code Sign Sealed Android Apps using DevSecOps Build System
• appdome_android_auto_dev_signing
  For further information, follow the instructions in the Knowledge Base article How to Automate Secure Android App Code Signing in DevOps CI/CD.
• appdome_ios_sign_on_appdome
  For further information, follow the instructions in the Knowledge Base article How to Use Code Sign on Mac for Secured iOS Apps.
• appdome_ios_private_signing
  For further information, follow the instructions in the Knowledge Base article How to Privately Code Sign Sealed iOS Apps using DevSecOps Build System.
• appdome_ios_auto_dev_signing
  For further information, follow the instructions in the Knowledge Base article How to Automate Secure iOS App Code Signing in DevOps CI/CD.
  Note:
  Each of the operations specified above requires different inputs. For details see Appendix B: Possible Input Types.

  script:
      - appdome_android_sign_on_appdome

Step 5: Configure the Build-2Secure GitLab Integration artifacts

1. Save the build outputs (Secure Application and Certifed Secure™ certificate)

   artifacts: 
      paths: 
       - ./appdome_outputs/ 
      expire_in: 1 week

Step 6: Retrieve DevSecOps Certification with Build-2Secure

Each build produces a Certified Secure™ artifact used to clear your release and ensure DevSecOps compliance. If you set an artifacts attribute, you can browse for the build outputs or download them.

To see the artifacts, go to CI/CD>Artifacts

Step 7: How to Access Appdome-Secured apps in the CI/CD Process

Output location – For using the Appdome secured app in the jobs to follow, you can add the following lines to your yaml file:
Note: For the “second output” described above, the universal .apk file will be generated in “./appdome_outputs/app_second_output.apk”

script: 
  - |
    export APPDOME_SECURED_APP=$(ls ./appdome_outputs/*app*)
    export APPDOME_SECURED_APP_SECOND_OUTPUT=$(ls ./appdome_outputs/app_second_output.apk)

After completing this step, APPDOME_SECURED_APP will contain the path to your secured app and you may use it for the CI process.

Appendix A: How to Add Files to the Environment Variables by Using Base64 Encoding

To add files as environment variables:

1. Open a terminal.
2. Encode the requested file with base64, and save (paste) it in a temporary text file:

   Usage:	base64 [-i in_file] [-o out_file]

   For example:

   base64 -i appdome.keystore -o example_temp.txt

3. Copy the contents of the text file into the matching environment variable, as shown in the images below.
   

Appendix B: Possible Input Types

Each of the operations mentioned in this article requires different inputs.
Every input can be set as either of the following types:

• Gitlab environment variable – applies to the entire environment
• Job variable – applies to a specific job

If you set an environment variable you do not have to set a job variable, and conversely.
For environment variable, see examples above.
For Job variable, you can follow this example:

variables:
    APP_LOCATION: "app.apk"
    APPDOME_ANDROID_FS_ID: "abcdefg"

Note:

Certain sign options require files, which can be retrieved by using any of the following ways:

• From a local location
• From a public URL (or example, https://[URL_of_your_file])
• A base64 encoded string, as described in Appendix A: How to Add Files to the Environment Variables by Using Base64 Encoding.

Common inputs for every operation type:

• APP_LOCATION
  A local location or a public URL (or example, https://[URL_of_your_non_protected_app]) for the non-protected application.
• APPDOME_TEAM_ID
  Insert your team-id. For details, section Getting and resetting your API Token in Appdome’s API guide.
  Note
  This line is optional and may be removed when working on a personal workspace.
• APPDOME_ANDROID_FS_ID
  Your Android fusion-set-id. For details, see the section Getting a Fusion Set’s ID in Appdome’s API guide.
  – or –
  APPDOME_IOS_FS_ID
  Your iOS fusion-set-id. For details, see the section Getting a Fusion Set’s ID in Appdome’s API guide.

Specific inputs for each operation type are:

• appdome_android_sign_on_appdome:
  • ANDROID_KEYSTORE_FILE
  • ANDROID_KEYSTORE_PASSWORD
  • KEYSTORE_ALIAS
  • KEYSTORE_KEY_PASSWORD
  • GOOGLE_PLAY_SIGNING (Boolean, Optional)
  • SIGN_FINGERPRINT (Required if Google Play Signing is true)
• appdome_android_private_signing:
  • SIGN_FINGERPRINT
  • GOOGLE_PLAY_SIGNING (Boolean, Optional)
• appdome_android_auto_dev_signing:
  • SIGN_FINGERPRINT
  • GOOGLE_PLAY_SIGNING (Boolean, Optional)
• appdome_ios_sign_on_appdome:
  • IOS_CERTIFICATE_FILE
  • IOS_CERTIFICATE_PASSWORD
  • MOBILE_PROVISION_PROFILE_FILES – separate multiple files by comma (‘,’).
  • ENTITLEMENTS_FILES – separate multiple files by comma (‘,’).
• appdome_ios_private_signing:
  • MOBILE_PROVISION_PROFILE_FILES – separate multiple files by comma (‘,’).
  • ENTITLEMENTS_FILES – separate multiple files by comma (‘,’).
• appdome_ios_auto_dev_signing:
  • MOBILE_PROVISION_PROFILE_FILES – separate multiple files by comma (‘,’).
  • ENTITLEMENTS_FILES – separate multiple files by comma (‘,’).

General inputs for all operation types:

• BUILD_WITH_LOGS:
  If marked “True”, the build will be executed with diagnostic logs.

• SECOND_OUTPUT (.aab only):
  If marked “True”, this will generate a secure universal .apk file from an .aab file, in addition to the secure .aab.
  Note: this option is not supported for auto dev signing option

• BUILD_TO_TEST:
  If specified, this will build the app ready for automated testing in standard DevOps testing suites.
  Do not use this service for individual device testing.
  Supported testing services: “bitbar” | “browserstack” | “lambdatest” | “saucelabs”.
  iOS: only “saucelabs” is supported.

• OUTPUT_APP_NAME:
  (Optional)If specified, this will override the default output name for appdome’s secured app output(It will also affect the universal apk for .aab apps).
  App name shouldn’t include the extension.

Appendix C: Manually running Appdome Build-2Secure job

If you want to run the pipeline manually, see below. To set the attributes of job artifacts, proceed to step 5.

To run the pipeline manually:

1. Go to CI/CD > Pipelines from the left menu.
   
2. On the top right corner, click Run pipeline.
   
3. Select the working branch and, optionally, specify the required inputs. When done, click Run Pipeline.
   
   

Related Articles:

• How to Optimize File Size, Code Obfuscation Best Practices in Android & iOS Apps
• How to Privately Code Sign Sealed iOS Apps using DevSecOps Build System
• How to Add an Android or iOS app to DevSecOps Build System in DevOps CI/CD

How Do I Learn More?

The description above is designed to help you secure Android & iOS apps in GitLab CI/CD pipelines.
If you have questions about using this Build2Secure Integration for GitLab. 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 make mobile app security easy. We hope we’re living up to the mission with your project. If you don’t already have an account, you can sign up for free.