How to Secure Android & iOS Apps in Jenkins CI/CD

Last updated April 3, 2024 by Appdome

The Appdome Build-2Secure plugin for Jenkins CI/CD pipelines is an out-of-the-box Jenkins 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. This can be achieved without the need for additional code or SDKs.

The purpose of Appdome’s Build-2Secure plugin for Jenkins is to streamline and accelerate cyber and anti-fraud delivery in CI/CD pipelines. To do this, the Build-2Secure plugin for Jenkins 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.

(3) Certifying the security of each protected mobile app.

The Appdome Build-2Secure plugin for Jenkins 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. It can function as a stand-alone DevSecOps integration or in tandem with other DevSecOps integrations in your CI/CD pipeline.

For more general information on this plugin, see Managing Plugins on the Jenkins website.

Below are the step-by-step instructions on how to use the Appdome Build-2Secure plugin for Jenkins.

Prerequisites for Appdome’s Jenkins plugin

Before you use Appdome’s plugin for Jenkins, there are a few things you need to have:

- An Appdome SRM account
  - Appdome API token
  - Fusion-Set ID
- Jenkins CI/CD server
  - CURL installed on your Node.
  - Environment Injector plugin (Optional)

Step 1: Installing the Build-2Secure plugin in Jenkins

To install the Appdome Build-2Secure plugin:

- 1. 1. Go to the Jenkins homepage.
    2. Select Manage Jenkins on the left menu.
    3. Select the Manage Plugins command.
    4. Add the Appdome Build-2Secure plugin to Jenkins through Jenkins Plugin Index as follows:
      1. Select the Available plugins tab.
        
        Search for Appdome Build-2Secure.
        
        Select the Appdome build-2Secure and click Download now and install after restart.
        
        Restart your Jenkins server.
    5. To confirm the plugin’s successful installation, navigate to Manage Jenkins > Installed plugins and search for Appdome Build-2Secure.

The Appdome Build-2Secure plugin is versatile and can be used in both freestyle projects and pipelines. To utilize the plugin in a freestyle project, it is necessary to add the plugin as a build step, which will be explained in the following section. Alternatively, if you opt to use a pipeline, we have also included instructions on how to incorporate the plugin into the appropriate stage of your pipeline script later in the guide.

Appdome Build-2Secure Plugin in Jenkins (Freestyle Project)

Step 2: Creating the Build-2Secure plugin in Jenkins

This step provides instructions for adding the Appdome Build-2Secure Plugin using both of the following methods:

- - Adding the Appdome plugin to a new project
  - Adding the Appdome plugin to an existing project

Adding the Appdome Plugin to a New Project

To add the Appdome plugin to a new project:

- 1. From the Jenkins menu, click New Item.
    1. Assign a name to your project and select the Freestyle Project type, then click OK.
    2. Select the Build Steps command.
    3. Expand the list. Add the build step and select Appdome Build-2Secure.
    4. Proceed to set the Appdome build-2Secure plugin configuration, as described in the next step.

Adding the Appdome Plugin to an Existing Project

To add the Appdome plugin to an existing project:

- 1. 1. Select the project to which you want to add the plugin.
    2. Go to Configure from the Jenkins menu.
    3. Open the Add build step menu and then select Appdome Build-2Secure.
      Appdome build-2Secure UI shows up, allowing you to enter your configuration.
    4. Proceed to set the Appdome build-2Secure plugin configuration, as described in the next step.

Step 3: Configure Appdome build-2Secure Plugin Configuration

After you select Appdome Build-2Secure as a build step, the screen shown below is displayed.

Screenshot 2023 09 26 At 17.09

- 1. Enter your Appdome Build2Secure API token in the Token field by following the instructions provided in the section Getting and resetting your API Token on the Appdome website.
  2. Enter your Team ID API token in the Team ID field by following the instructions provided in the section Getting a Team’s ID on the Appdome website.
  3. Enter the appropriate Fusion Set ID in the Fusion-set-id field by following the instructions provided in the section Getting a Fusion Set’s ID on the Appdome website.
  4. Depending on the type of application you are building, use the Platform field to select either iOS or Android.
    If you want to learn more about file paths read the description below, otherwise, proceed to the next step.

File Paths
When working with files, you can set the files in any of the following methods:
– Provide the full path to the file, which should be located on the node machine.
– Use environment variables with the Environment Injector plugin or Configure the node machine settings in Jenkins.
– Set a remote URL link to a file either on the configuration page or as an environment variable.

For instructions on how to set environment variables, see Appendix A: How to Set Environment Variables.

Warning
When using the configuration form, any input that has the same field as an environment variable (e.g., keystore’s path) will take precedence, i.e., it will override the environment variable. Therefore, to ensure proper use of the environment variable input, you must verify that these variables are unique and do not also appear in the configuration form.

- - - Use the iOS/Android application field to choose any of the following options:
      - Specify the full path to the application file on the node where it is running
      - Set the environment variable name as APP_PATH. If an environment variable is defined, leave the <platform> application field (i.e.: Android application or iOS application) empty.
      - Set a remote URL link to a file either on the configuration page or as an environment variable named APP_PATH.
        Note: The URL link should not contain any commas.
    - Use the keystore file field to choose any of the following options:
      - Specify the full path to the keystore file on the node where it is running
      - Set the environment variable name KEYSTORE_PATH. If an environment variable is defined, leave the keystore field empty.
      - You can set a remote URL link to a file either on the configuration page or as an environment variable named KEYSTORE_PATH.
        Note: The link should not contain any commas.
    - Use the Provisioning Profile field under iOS signing, and choose any of the following options:
      - Specify the full path to the provisioning profile file(s) on the node where it is running, can add as many files as needed, each file on a new textbox
      - You can set a remote URL link to a file either on the configuration page or as an environment variable named MOBILE_PROVISION_PROFILE_PATHS. If an environment variable is defined, leave the Provisioning Profile field empty.
      - Set the environment variable name as MOBILE_PROVISION_PROFILE_PATHS, to insert multiple files in an environment variable, each file must be separated by ‘,’ without any spaces.
        For example: First_file.mobileprovision, second_file.mobileprovision, third_file.mobileprovision…
    - Use the Entitlements field under iOS signing, and choose any of the following options:
      - Specify the full path to the entitlement file(s) on the node where it is running, can add as many files as needed, each file on a new textbox
      - Set the environment variable name as ENTITLEMENTS_PATHS
      - You can set a remote URL link to a file either on the configuration page or as an environment variable named ENTITLEMENTS_PATHS.
        To insert multiple files in an environment variable, each file must be separated by ‘,’ without any spaces.
        For example: First_file.plist,second_file.plist,third_file.plist…
    - Use the Sign Method field to choose the method by which you want to sign your application. The options available will depend on the platform you have.
      The available sign options are:
      - For Android:
        
        Sign on Appdome – for further information, follow the instructions specified in the Knowledge Base article
        How to Code Sign Secured Android Apps in DevSecOps Build System.
        
        Private Signing – for further information, follow the instructions specified in the Knowledge Base article
        How To Privately Code Sign Sealed Android Apps using DevSecOps Build System.
        
        Auto-DEV Signing – for further information, follow the instructions specified in the Knowledge Base article
        How to Automate Secure Android App Code Signing in DevOps CI/CD.
      - For iOS:
        
        Sign on Appdome – for further information, follow the instructions specified in the Knowledge Base article
        How to Use Code Sign on Mac for Secured iOS Apps.
        
        Private Signing – for further information, follow the instructions specified in the Knowledge Base article
        How to Privately Code Sign Sealed iOS Apps using DevSecOps Build System.
        
        Auto-DEV Signing – for further information, follow the instructions specified in the Knowledge Base article
        How to Automate Secure iOS App Code Signing in DevOps CI/CD.
    - Use the Output Location field to enter a new value or leave the default value:
      WORKSPACE/output/appdome_orig_app_name.aab/.apk/.ipa
      If you would like to save the output of the built and secured application in a different location, specify a full path of the application example: <your_path/name_of_original_app’.aab/.apk/.ipa>.
      The certified secure document will also be saved to this location.
    - Build with logs: Mark the checkbox if you’d like to build your app with diagnostic logs.
    - Build to Test: Allows automated testing of Appdome Secured Apps in standard DevOps testing suites.
      Do not use this service for individual device testing.
      Specify the supported Testing Service.
      
      Note: for iOS – only Saucelabs is supported.
    - Second Output (.aab apps only): Mark the checkbox if you’d like to sign the second output. Set a path for the second .apk file to be downloaded.
      Specify a full path for the application, for example, <your_path/second_output>.apk
      Note: this option is relevant only for apps signed with Appdome Auto Sign or Private Sign. Not applicable for Auto-Dev Private Signed apps.

After filling in all the required parameters, you can save the configuration and begin building your application and securing it with the Appdome Build-2Secure for Jenkins. Skip to Step 5 to do that.

Appdome Build-2Secure Plugin in Jenkins (Pipeline Project)

Step 1: Creating the Build-2Secure plugin in Jenkins

This step provides instructions for adding the Appdome Build-2Secure Plugin in both of the following methods:

Adding the Appdome plugin to a new project
Adding the Appdome plugin to an existing project

Adding the Appdome Plugin to a New Project

To add the Appdome plugin to a new project:

From the Jenkins menu, click New Item.
Assign a name to your project and select the Pipeline type, then click OK.
Use the next page to select the Pipeline command.
Write your pipeline steps as required
Proceed to setting the Appdome build-2Secure plugin configuration, as described in the next step.

Adding the Appdome Plugin to an Existing Project

To add the Appdome plugin to an existing project:

1. Select the project to which you want to add the plugin.
2. Go to Configure from the Jenkins menu:
3. Use the next page to select the Pipeline:
4. Write your pipeline steps as required.
5. Proceed to setting the Appdome build-2Secure plugin configuration, as described in the next step.

Step 2: Configuring Build-2Secure Plugin on Appdome

To use the Appdome build-2Secure plugin, add one of the next pipeline templates:

Inputs explanation:

Replace all placeholders, which are located within brackets (for example, ‘<YOUR_TOKEN>‘) with the right value in accordance with the relevant template:

- To use the token field, replace ‘<YOUR_TOKEN>‘ with your Appdome Build2Secure API token. You can obtain this token by following the instructions provided in the API guide.
- To use the teamId field (optional), replace ‘<YOUR_TEAMID_OR_LEAVE_EMPTY_FOR_PERSONAL>‘ with your team ID or leave it empty for personal workspace. You can obtain this key by following the instructions provided in the API guide.
- To use the fusionSetId field, replace ‘<YOUR_FUSIONSET_ID>‘ with the appropriate fusion-set-id for your iOS or Android application. For details, see the section Getting a Fusion Set’s ID in the API guide. If you want to learn more about file paths, read the description below; otherwise, proceed to the next step.

For instructions on how to set environment variables, see Appendix A: How to Set Environment Variables.

- - - To use the appPath field
      - Replace ‘<FULL_PATH_OR_URL_TO_APP_FILE>‘ with the full path on the node machine.
      - Specify a full path to the file as an environment variable named APP_PATH. If using the environment variable, leave appPath empty.
      - Replace ‘<FULL_PATH_OR_URL_TO_APP_FILE>’ with a remote URL link to a file either on the pipeline page or as an environment variable named APP_PATH. If using the environment variable, leave appPath empty.
        Note: The URL link must not contain any commas.
    - To use the keystorePath field under auto signing for iOS and Android.
      You can choose one of the following options:
      - Replace ‘<FULL_PATH_OR_URL_TO_KEYSTORE_FILE>‘ with the full path to the keystore file on the node where it is running.
      - Specify the full path to the file as environment variable name KEYSTORE_PATH. If using the environment variable, leave keystorePath empty.
      - Replace ‘<FULL_PATH_OR_URL_TO_KEYSTORE_FILE>‘ with a remote URL link to a file either in the pipeline page or as an environment variable named KEYSTORE_PATH.
        Note: The URL link should not contain any commas.
  - - To use the provisioningProfiles field under iOS signing. If you insert multiple files, each path to a file must be wrapped with “StringWarp” as shown in the template.
      You can select any of the following options:
      - Replace ‘<FULL_PATH _OR_URL_TO_MobileProvision_FILE>‘ with the full path to provisioning profile file(s) on the node where it is running. You can add as many files as needed, each path to a file must be wrapped with “StringWarp” as shown in the template.
      - Replace ‘<FULL_PATH _OR_URL_TO_MobileProvision_FILE>‘ with a remote URL link to a file either on the pipeline page or as an environment variable named MOBILE_PROVISION_PROFILE_PATHS. If using the environment variable, leave provisioningProfiles empty.
        Note: The URL link should not contain any commas.
      - Specify a full path to the file as environment variable name MOBILE_PROVISION_PROFILE_PATHS. If using the environment variable, leave provisioningProfiles empty.
        To insert multiple files as an environment variable, each file must be separated by ‘,’ without any spaces.
        For example:
        First_file.mobileprovision, second_file.mobileprovision, third_file.mobileprovision
        or:
        https://url_to_download/first_file.mobileprovision, https://url_to_download/second_file.mobileprovision, https://url_to_download/third_file.mobileprovisionNote: You can combine URL links with the complete path to local files stored on the node machine.
    - To use the entitlements field under iOS signing
      If you insert multi files, each path to a file must be wrapped with “StringWarp” as shown in the template.
      You can select any of the following options:
      - Replace ‘<FULL_PATH _OR_URL_TO_entitlements_FILE#i>‘ with the full path to entitlement file(s) on the node where it is running, you can add as many files as needed, each path to a file must be wrapped with “StringWarp” as shown in the template.
      - Replace ‘<FULL_PATH _OR_URL_TO_entitlements_FILE#i>‘ with a remote URL link to a file either on the pipeline page or as an environment variable named ENTITLEMENT_PATHS. If using the environment variable, leave entitlements empty.
        Note: The URL link should not contain any commas
      - Specify a full path to the file as environment variable name ENTITLEMENT_PATHS as explained above. If using the environment variable, leave entitlements empty.
        To insert multiple files as an environment variable, each file must be separated by ‘,’ without any spaces.
        For example:
        First_file.plist,second_file.plist,third_file.plist
        or:
        https://url_to_download/first_file.plist, https://url_to_download/second_file.plist, https://url_to_download/third_file.plist
        Note: You can combine URL links with the complete path to local files stored on the node machine.
    - To use the outputLocation field
      If you leave outputLocation empty, the default value is set to:
      ‘WORKSPACE/output/appdome_name_of_original_app.aab/.apk/.ipa’
      If you would like to save the output of the build and secured application in a different location, replace ‘<FULL_PATH_TO_OUTPUT_APP_OR_EMPTY_FOR_DEFAULT>‘ with the full path of the application example: <your_path/name_of_original_app’.aab/.apk/.ipa>.
      The certified secure document will also be saved to this location.
    - If the ‘Obfuscate App Logic’ option was selected for Android fusion set, the ‘Deobfuscation_Mapping_Files.zip’ will be automatically downloaded to the same location as the protected application, and it will be named ‘Deobfuscation_Mapping_Files.zip’.
  - Build with logs: Build your app with diagnostic logs. To enable build to test, go to the pipeline inside the AppdomeBuilder section and choose:

buildWithLogs: true

If you don’t want to use ‘buildWithLogs’, you can either omit this parameter or set its value to ‘false’.

buildWithLogs: false

- - Build to Test: Allows automated testing of Appdome Secured Apps within standard DevOps testing suites. To utilize it, specify the supported Testing Service and use this syntax:

Note: It is not designed for individual device testing.

buildToTest: [selectedVendor: '<VENDOR_NAME>' ]

Insert the relevant <VENDOR_NAME> from the list:

SAUCELABS

BITBAR

LAMBDATEST

BROWSERSTACK

Note: Only Saucelabs is supported for iOS.

- - Second Output (.aab apps only): To sign the second output, specify a set path where the subsequent .apk file will be downloaded. Make sure to specify a full path for the application. To utilize it, enter the following syntax:

secondOutput: StringWarp('<PATH_TO_SECOND_OUTPUT>.apk')

The <PATH_TO_SECOND_OUTPUT> represents the full path for the application.
For example: <your_path/second_output>.apk

Note: This option is relevant only for apps signed either with Appdome Auto Sign or Private Sign. It is not applicable to Auto-Dev Private Signed apps.

All parameters within the pipeline template must be situated within the AppdomeBuilder section. Below is a comprehensive example that includes all the parameters:

This example Android_AutoDevSign includes a second output parameter and is for illustrative purposes only.

pipeline {
    agent any
    stages {
        stage('AppdomeBuilder') {
            steps {
                script {
                    AppdomeBuilder (
                        outputLocation: '<FULL_PATH_TO_OUTPUT_APP_OR_EMPTY_FOR_DEFAULT>',
                        platform: AndroidPlatform(
                            appPath: '<FULL_PATH_OR_ENV_VAR_OR_URL_TO_APP_FILE>',
                            certificateMethod: Android_AutoDevSign(
                                fingerprint: '<Your_SHA1_Fingerprint>'
                                googleSigning: true/false
                            ),
                            fusionSetId: '<YOUR_FUSIONSET_ID>'
                        ),
                        teamId: '<YOUR_TEAMID_OR_LEAVE_EMPTY_FOR_PERSONAL>',
                        buildToTest: [selectedVendor: 'VENDOR_NAME'],
                        secondOutput: StringWarp('<PATH_TO_SECOND_OUTPUT>.apk'),
                        buildWithLogs: true/false,
                        token: hudson.util.Secret.fromString('<YOUR_TOKEN>')
                   )
                }
            }
        }
    }
}

Step 3: Select the signing method for your iOS or Android application.

- For Android:
  Auto Signing – For additional information, follow the instructions specified in the Knowledge Base article How to Code Sign Secured Android Apps in DevSecOps Build System.

stage('Appdome Builder') {
    steps {
        AppdomeBuilder (
            outputLocation: '',
            platform: AndroidPlatform(
                appPath: '',
                certificateMethod: Android_SignOnAppdome( #Note: Previously was "Android_AutoSign",has backward compatibility
                    keyPass: hudson.util.Secret.fromString(''),
                    keystoreAlias: hudson.util.Secret.fromString(''),
                    keystorePassword: hudson.util.Secret.fromString(''),
                    keystorePath: '',
                    googleSignFingerPrint: Android_AutoGoogleSign(googleSignFingerPrint: ''),
                ),
                fusionSetId: ''
            ),
            teamId: '',
            token: hudson.util.Secret.fromString('')
        )
    }
}

Private Signing – For additional information, follow the instructions in the Knowledge Base article How To Privately Code Sign Sealed Android Apps using DevSecOps Build System.

stage('Appdome Builder') {
  steps {
    AppdomeBuilder(
 	outputLocation: '<FULL_PATH_TO_OUTPUT_APP_OR_EMPTY_FOR_DEFAULT>',
 	platform: AndroidPlatform(
  		appPath: '<FULL_PATH_OR_ENV_VAR_OR_URL_TO_APP_FILE>',
  		certificateMethod: Android_PrivateSign(
    			fingerprint: '<Your_SHA1_Fingerprint>',
                        googleSigning: true/false
  			),
  			fusionSetId: '<YOUR_FUSIONSET_ID>'
  		),
 		teamId: '<YOUR_TEAMID_OR_LEAVE_EMPTY_FOR_PERSONAL>',
 		token: hudson.util.Secret.fromString('<YOUR_TOKEN>'))
   }
}

Auto-DEV Signing – for additional information, follow the instructions specified in the Knowledge Base article How to Automate Secure Android App Code Signing in DevOps CI/CD.

stage('Appdome Builder') {
    steps {
      AppdomeBuilder (
 	outputLocation: '<FULL_PATH_TO_OUTPUT_APP_OR_EMPTY_FOR_DEFAULT>',
 	platform: AndroidPlatform(
  		appPath: '<FULL_PATH_OR_ENV_VAR_OR_URL_TO_APP_FILE>',
  		certificateMethod: Android_AutoDevSign(
    			fingerprint: '<Your_SHA1_Fingerprint>',
    			googleSigning: true/false
  			),
  			fusionSetId: '<YOUR_FUSIONSET_ID>'
  		),
 		teamId: '<YOUR_TEAMID_OR_LEAVE_EMPTY_FOR_PERSONAL>',
 		token: hudson.util.Secret.fromString('<YOUR_TOKEN>'))

 	}
}

For iOS:
Auto Signing – for additional information, follow the instructions specified in the Knowledge Base article How to Use Code Sign on Mac for Secured iOS Apps

stage('Appdome Builder') {
    steps {
 	AppdomeBuilder(
 		outputLocation: '<FULL_PATH_TO_OUTPUT_APP_OR_EMPTY_FOR_DEFAULT>',
 		platform: IosPlatform(
  		appPath: '<FULL_PATH_OR_ENV_VAR_OR_URL_TO_APP_FILE>',
  			certificateMethod: iOS_SignOnAppdome( #Note: Previously was "iOS_AutoSign",has backward compatibility entitlements: [
      StringWarp('<FULL_PATH_OR_ENV_VAR_OR_URL_TO_entitlements_FILE#1>'),
      StringWarp('<FULL_PATH_OR_ENV_VAR_OR_URL_TO_entitlements_FILE#2>'),
      StringWarp('<FULL_PATH_OR_ENV_VAR_OR_URL_TO_entitlements_FILE#N>')
    ],
    			keystorePassword: hudson.util.Secret.fromString('<YOUR_KEYSTORE_PASSWORD>'),
    			keystorePath: '<FULL_PATH_OR_ENV_VAR_OR_URL_TO_KEYSTORE_FILE>',
    			provisioningProfiles: [
      StringWarp('<FULL_PATH_OR_ENV_VAR_OR_URL_TO_MobileProvision_FILE#1>'),
      StringWarp('<FULL_PATH_OR_ENV_VAR_OR_URL_TO_MobileProvision_FILE#2>'),
      StringWarp('<FULL_PATH_OR_ENV_VAR_OR_URL_TO_MobileProvision_FILE#N>')
    ]
  			),
  			fusionSetId: '<YOUR_FUSIONSET_ID>'
  		),
 		teamId: '<YOUR_TEAMID_OR_LEAVE_EMPTY_FOR_PERSONAL>',
 		token: hudson.util.Secret.fromString('<YOUR_TOKEN>'))
	}
}

Private Signing – for additional information, follow the instructions specified in the Knowledge Base article How to Privately Code Sign Sealed iOS Apps using DevSecOps Build System.

stage('Appdome Builder') {
  steps {
  	AppdomeBuilder (
  		outputLocation: '<FULL_PATH_TO_OUTPUT_APP_OR_EMPTY_FOR_DEFAULT>',
 		platform: IosPlatform (
  		appPath: '<FULL_PATH_OR_ENV_VAR_OR_URL_TO_APP_FILE>',
  		certificateMethod: iOS_PrivateSign ([
      StringWarp('<FULL_PATH_OR_ENV_VAR_OR_URL_TO_MobileProvision_FILE#1>'),
      StringWarp('<FULL_PATH_OR_ENV_VAR_OR_URL_TO_MobileProvision_FILE#2>'),
      StringWarp('<FULL_PATH_OR_ENV_VAR_OR_URL_TO_MobileProvision_FILE#N>')
                 ]),
  		fusionSetId: '<YOUR_FUSIONSET_ID>'
  		),
  	teamId: '<YOUR_TEAMID_OR_LEAVE_EMPTY_FOR_PERSONAL>',
 	token: hudson.util.Secret.fromString('<YOUR_TOKEN>'))

 	}
}

Auto-DEV Signing – For additional information, follow the instructions specified in the Knowledge Base article How to Automate Secure iOS App Code Signing in DevOps CI/CD.

stage('Appdome Builder') {
  	steps {
  		AppdomeBuilder (
 			outputLocation: '<FULL_PATH_TO_OUTPUT_APP_OR_EMPTY_FOR_DEFAULT>',
 			platform: IosPlatform(
  			appPath: '<FULL_PATH_OR_ENV_VAR_OR_URL_TO_APP_FILE>',
  				certificateMethod: iOS_AutoDevSign(
    				entitlements: [     
       StringWarp('<FULL_PATH_OR_ENV_VAR_OR_URL_TO_entitlements_FILE#1>'),
       StringWarp('<FULL_PATH_OR_ENV_VAR_OR_URL_TO_entitlements_FILE#2>'),
       StringWarp('<FULL_PATH_OR_ENV_VAR_OR_URL_TO_entitlements_FILE#N>'),
   			 ],
    				provisioningProfiles: [
      StringWarp('<FULL_PATH_OR_ENV_VAR_OR_URL_TO_MobileProvision_FILE#1>'),
      StringWarp('<FULL_PATH_OR_ENV_VAR_OR_URL_TO_MobileProvision_FILE#2>'),
      StringWarp('<FULL_PATH_OR_ENV_VAR_OR_URL_TO_MobileProvision_FILE#N>')
    			]
  				),
  				fusionSetId: '<YOUR_FUSIONSET_ID>'
  			),
                       teamId: '<YOUR_TEAMID_OR_LEAVE_EMPTY_FOR_PERSONAL>',
                       token: hudson.util.Secret.fromString('<YOUR_TOKEN>'))  
                 
        }
}

Note: When using pipelines, your initial build attempt might fail because of the use of the fromString function. If this happens, navigate to the failed build and select Console Output. You will see the following message:

Scripts are not allowed to use “staticMethod hudson.util.Secret fromString java.lang.String”. Administrators can choose to approve or reject this signature.
Clicking the hyperlink takes you to a new page where you can approve the script. To proceed with your pipeline build, make sure you approve the script by clicking the Approve button.

Step 4: Build Android & iOS security with the Build-2Secure plugin

After setting up the Build-2Secure plugin for Jenkins, you can initiate the build process in Jenkins. Once the build is complete, you can access its output by navigating to the “workspace“.

Workspace

The Appdome Build-2Secure will automatically verify the request sent from Jenkins and add the mobile app security, anti-fraud, and other protections to your Android and/or iOS mobile app as specified in the Fusion Set associated with this app. After the build process is finished, the protected application will be accessible at the designated Output Location that you defined in the Build-2Secure plugin setup. Alternatively, if you left the location as default, you can just go to your job and click on Workspace to find the output folder that contains the Appdome secured application.

Congratulations, you can now use your secured mobile app.

Step 5: Retrieve DevSecOps Certification with Build-2Secure

Each build produces a Certified Secure™ artifact used to clear your release and ensure DevSecOps compliance. This file will be located in the designated Output Location that you defined in the Build-2Secure plugin setup. Alternatively, if you left the location as default, you can just go to your job and click on Workspace to find the output folder that contains the Appdome secured application

Step 6: Confirming Cyber Build and Sign on Appdome

In Jenkins, you can monitor the build process and results by checking the following sections:

- - - Build History
      Displays the status and result of each build.
    - Console Output
      Provides detailed information about the build process and any errors or warnings that may have occurred.

Appdome plugin for Jenkins - Monitor build process

You can also use Appdome’s platform to monitor the status of your builds and see a complete history of all your builds.

Appendix A: Jenkins Environment Set Up for Build-2Secure

To set environment variables:

- 1. 1. Go to Manage Jenkins.
    2. Go to Manage Nodes and Clouds.
    3. Select the agent on which you want to build.
    4. Click Configure.
    5. Scroll down to Node Properties and select the Environment variables check box if it has not already been selected.
    6. Add as many environment variables as required and save.

Need Additional Help?

The description above is designed to help you secure Android & iOS apps in Jenkins CI/CD pipelines. If you have questions about using this Build-2Secure plugin, 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.

How to Secure Android & iOS Apps in Jenkins CI/CD

Prerequisites for Appdome’s Jenkins plugin

Step 1: Installing the Build-2Secure plugin in Jenkins

Appdome Build-2Secure Plugin in Jenkins (Freestyle Project)

Step 2: Creating the Build-2Secure plugin in Jenkins

Adding the Appdome Plugin to a New Project

Adding the Appdome Plugin to an Existing Project

Step 3: Configure Appdome build-2Secure Plugin Configuration

Appdome Build-2Secure Plugin in Jenkins (Pipeline Project)

Step 1: Creating the Build-2Secure plugin in Jenkins

Adding the Appdome Plugin to a New Project

Adding the Appdome Plugin to an Existing Project

Step 2: Configuring Build-2Secure Plugin on Appdome

Step 3: Select the signing method for your iOS or Android application.

Step 4: Build Android & iOS security with the Build-2Secure plugin

Step 5: Retrieve DevSecOps Certification with Build-2Secure

Step 6: Confirming Cyber Build and Sign on Appdome

Appendix A: Jenkins Environment Set Up for Build-2Secure

Related Articles:

Need Additional Help?

Thank you!

Supercharge the Experience in Mobile App Defense

Better User Experience in Mobile Defense

Shifting Dynamics in Mobile Fraud Prevention: A Call for Developer Responsibility

Eliminating Information Asymmetry in the Attack Chain With GenAI