Continuous Integration (CI) pipelines are a well established part of app development workflows: Every time you push changes, the pipeline automatically checks if the tests work as expected and code quality metrics are inside acceptable boundaries.
While generic code analysis tools running on e.g. Swift source code provide helpful tips to iOS developers as well, you should also make sure your app adheres to security standards that are specific to mobile apps, such as OWASP’s MASVS. One tool that can help you discover relevant weaknesses in your app is AppSweep, Guardsquare’s Mobile Application Security Testing solution: In this article, we will focus on how your existing CI infrastructure can take care of uploading the current version of your app to AppSweep and checking if the results match your guidelines, e.g. that there are no high severity findings.
First, we will show how to integrate AppSweep in Fastlane setups, while the second part of this post will show you how to do it if Xcode Cloud is your CI system of choice. Feel free to skip ahead to the section you’re most interested in.
Fastlane
A very popular tool among iOS developers is Fastlane, which aims to help you automate as much as possible across the different app development workflows, such as building, signing key management, distributing to the App Store and generating screenshots for the store listing.
Before we can set up your Fastlane config to integrate with AppSweep, we need to make sure certain prerequisites are in place:
You installed the Guardsquare CLI in your CI environment
An API key has been created for the AppSweep application where you want to upload your app: Those can be generated in your application´s settings page
The
APPSWEEP_API_KEYenvironment variable in your CI environment is set up to contain the API key you just created
Assuming your Fastfile has a lane called build that builds an IPA using the build_app command, adding a lane that allows you to upload the resulting app to AppSweep is as easy as installing the Guardsquare CLI and adding this snippet:
desc "Upload to AppSweep" lane :appsweep_upload do build result = JSON.parse(sh("guardsquare scan --dsym #{lane_context[SharedValues::DSYM_OUTPUT_PATH]} #{lane_context[SharedValues::IPA_OUTPUT_PATH]} --format json 2>/dev/null")) lane_context[:APPSWEEP_ID] = result['id'] lane_context[:APPSWEEP_URL] = result['url'] end |
Once this is added, you can trigger a rebuild of your app followed by an upload to AppSweep by executing fastlane appsweep_upload
Uploading to AppSweep is only the first step to proper CI integration though! As mentioned before, we might of course also want to fail the CI pipeline in case there are too many AppSweep findings. This can be achieved by adding this to your Fastfile as well:
desc "Check AppSweep Results"
lane :appsweep_check do
appsweep_upload
result = JSON.parse(sh("guardsquare scan summary --wait-for static #{lane_context[:APPSWEEP_ID]} --format json 2>/dev/null"))
high_severity = result["high"]
findings_pluralized = high_severity == 1 ? "finding" : "findings"
UI.user_error!("AppSweep scan contains #{high_severity} high severity #{findings_pluralized}: #{lane_context[:APPSWEEP_URL]}") if high_severity > 0
end
|
Now, when you run fastlane appsweep_check, your app will first be built, then uploaded to AppSweep and once the scan is complete, the finding count will be checked: In the current example, if you have at least one high severity finding, the pipeline step will fail and print the following warning message.
After visiting the AppSweep scan via the URL printed in the logs, you can investigate what the finding in question is, fix it in your code and push another commit to CI. The Fastlane workflow will run again, but this time we fixed the finding, allowing the pipeline to succeed:
Xcode Cloud
While Fastlane allows you to streamline your build process locally and in your CI, Apple also provides their own CI solution with Xcode Cloud. It is very tightly integrated with XCode and as such, it usually requires very little to no customization to get it up and running for your iOS applications. Integrating AppSweep into this workflow is of course also possible, which will be the topic of this upcoming section.
Xcode Cloud has support for custom build scripts in a dedicated ci_scripts directory within your Xcode project. It recognizes and executes three specific types of scripts based on their naming and timing in the workflow:
Post-clone (
ci_post_clone.sh): Executes after cloning the git repository, making it suitable for initial setup tasks like installing tools or modifying files.Pre-Xcodebuild (
ci_pre_xcodebuild.sh): Runs before the xcodebuild command, useful for compiling extra dependencies.Post-Xcodebuild (
ci_post_xcodebuild.sh): Activates post-build, allowing your script to perform extra tasks with the final app bundle built in this CI run.
For our use case, the Post-Xcodebuild step is what we are looking for. Uploading the newly built xcarchive to AppSweep and failing the pipeline whenever there are high severity findings can be achieved with storing this script in ci_scripts/ci_post_xcodebuild.sh:
#!/bin/sh
set -eo pipefail
if [ "${CI_XCODEBUILD_EXIT_CODE}" -ne 0 ]; then echo "xcodebuild didn't finish successfully, skipping AppSweep upload" exit 0 fi
echo "Installing Guardsquare CLI" curl -sS https://platform.guardsquare.com/cli/install.sh | sh -s -- -y
echo "Uploading to AppSweep" AS_ID=$(guardsquare scan ${CI_ARCHIVE_PATH} --format {{.ID}})
echo "Created AppSweep scan at ${AS_URL}. Waiting for results..." guardsquare scan summary --wait-for=static ${AS_ID} --format json > as-result.json AS_HIGH_FINDINGS=$(jq ".high" as-result.json)
if [ "${AS_HIGH_FINDINGS}" -eq 0 ]; then echo "No high severity findings detected" && exit 0 elif [ "${AS_HIGH_FINDINGS}" -eq 1 ]; then echo "One high severity finding detected!" else echo "${AS_HIGH_FINDINGS} high severity findings detected!" fi
exit |
When you now commit your changes to Git, Xcode Cloud will pick up the new script automatically and show its output in Xcode’s build log view:
As you can see in the screenshot, the AppSweep scan URL is printed to the build logs, as well as a message indicating whether there are any high severity findings. After investigating and fixing the findings in question, just commit and push your changes again and let the pipeline run another time, this time successfully:
Conclusion
As we’ve seen in this post, AppSweep can be easily integrated into your CI pipeline, ensuring that mobile app security testing happens continuously for all changes to your app.
Start getting notified today whenever a new vulnerability is about to be introduced to your code base!