How to incorporate mobile app security testing into your build pipeline

DevSecOps is a philosophy that integrates security into the DevOps process: it has gained significant traction in recent years.

Build pipelines serve as the backbone of this approach, automating the software delivery process and incorporating various stages of testing, including mobile app security testing. By embedding security checks into the build pipeline, you can identify and remediate vulnerabilities early in the development lifecycle, and so reduce the risk (and costs) associated with security breaches.

If you're interested in understanding how to incorporate mobile app security testing into your build pipelines, then read on.

In this article, you’ll learn about different types of security testing, the tools that are available, and some best practices to make sure your mobile applications are as secure as possible.

You've probably heard of the Open Web Application Security Project (OWASP). It has identified the top ten mobile vulnerabilities, which include insecure data storage, insufficient cryptography, and insecure communications. These often serve as entry points for attackers to compromise mobile applications.

Here’s the OWASP Top 10 list in full:

It’s worth pointing out that M2 and M8 in this list don’t relate only to mobile security. You can see them as part of a more holistic security strategy your organization might employ that requires incorporating DevSecOps practices into your day-to-day work.

The importance of following guidelines like those championed by OWASP is reinforced daily by news articles highlighting the dire consequences experienced by those who haven’t followed them. These include financial losses, legal repercussions, and a tarnished brand image. 

According to Cybersecurity Ventures, the cost of cybercrime is estimated to reach $10.5 trillion USD annually by 2025 (a 15 percent yearly increase). And a significant portion of this can be attributed to mobile security lapses.

In order for a car to reach the dealer’s warehouse, a complex manufacturing process must take place behind the scenes. The metal arriving at the factory is converted into the chassis, the spare parts are assembled together, and then a quality check will be performed. 

Only then will it be delivered to the dealers.

A similar process happens with software, including with mobile apps. A build pipeline is an automated workflow that encompasses every step involved in building, testing, and deploying code. It serves as a crucial element in implementing Continuous Integration/Continuous Deployment (CI/CD) practices. 

Your typical pipeline will consist of the following stages:

Source Control. This is when developers commit their code to GitHub, Gitlab, Bitbucket or a similar system. The build system then copies the code from a repository there.

Static code analysis. Developers are human beings, which means they can make mistakes because of a lack of attention or distractions. Automated static code analysis tools can spot security bugs that might otherwise have crept in. 

Dependency resolution. Every application uses third-party libraries. The build pipeline should download these dependencies from the systems like Sonatype Nexus, CocoaPods, Swift Package Manager, and so on.  

Compilation. The source code should be transformed into the code representation understandable by target devices. Java/Kotlin code gets compiled into the DEX format, and Objective-C/Swift is compiled to the arm instructions.

Unit Testing. Unit tests are small programs which run isolated parts of the application and make sure that they work as expected. 

Integration Testing. Integration Tests run the app through different scenarios to make sure that it works as a whole.  

Application Security Testing. Security tests try to find vulnerabilities in the app before it reaches the production stage. 

Application Hardening. Your app will face multiple security challenges in the wild world it operates in after launch. App hardening measures are vital in fighting these threats.

Deployment. This is when the validated code is rolled out to a staging or production environment and your app is sent to Google Play channels, TestFlight, and/or custom services like Azure AppCenter for testing.

Each of the stages above can contribute in some way to enhancing the security of your application. 

Dependency resolution and static analysis can protect against supply chain attacks. Unit and integration testing should catch problems in app logic like authentication. And deployment should securely deliver the application to app stores. 

You've probably read about the "shift-left" movement in DevSecOps.

Instead of treating security as an afterthought, shift-left is all about bringing it front and center, right from the get-go.

Imagine you spot a nasty bug in your app early on in the development process. Not only does this save you days and days of debugging time, but you also make your app safer for your end users and you don’t suffer all the negative consequences of a breach that we touched on earlier.

Early detection saves you money as well as time, of course. Fixing a security issue at the outset is a bit like catching a leak before your whole basement floods.

Then there are the compliance requirements that you need to follow. Whether you're dealing with GDPR, HIPAA, or PCI-DSS, integrating security measures early can make the auditing process a breeze. 

But let’s go back to the end user for a second and the importance of building trust. A secure app is a trusted app. And in today's market where everyone is more aware of privacy and data security, having a secure app can give you a leg up on the competition.

Let's take a look at a couple of examples from two different industries:

Firstly, imagine a financial services app whose developers decided to integrate Static Application Security Testing (SAST) right into their build pipeline. Because they catch some serious SQL injection vulnerabilities before they hit the production phase, they could save a huge sum in potential breach costs.

Secondly, a healthcare provider uses DAST (Dynamic Application Security Testing) to scan their application. By doing so, they discover they were storing patient data in an insecure manner. Fixing this not only saves them from potential legal headaches but also makes sure they stay HIPAA compliant.

Hopefully, you're getting the sense that integrating mobile app security testing into your build pipeline isn’t a "nice-to-have". It's a "must-have". 

It saves you money, it keeps you compliant, and it builds trust with your users.

So, what does mobile application security testing actually involve? 

Well, it's important to understand that it isn’t a one-size-fits-all kind of thing. There are different flavors of mobile app security testing, and each one has its own advantages.

Let's take a look at them.

SAST for mobile apps

SAST (Static Application Security Testing) is a bit like an English tutor who corrects your essay for grammatical and structural errors before you hand it in. It does this by scanning your source code, bytecode, or binary code during the development phase.

By doing so, SAST allows developers to identify vulnerabilities such as insecure data storage, weak encryption algorithms, and hard-coded secrets early in the development cycle. For Android apps developed in Java or Kotlin, SAST tools can identify vulnerabilities specific to Android SDKs, such as insecure SharedPreferences or misuse of Android KeyStore. 

For iOS apps developed in Swift or Objective-C, SAST tools can flag issues like insecure data storage in UserDefaults or insecure network calls that don't use App Transport Security (ATS). These vulnerabilities can be classified as M9: Insecure Data Storage if we return to the OWASP Top 10 list above.

Android Studio Lint provides good security capabilities from an Android app perspective. And, though not mobile specific, SonarQube offers plugins for both Android and iOS. It can analyze Java, Kotlin, Swift, and Objective-C codebases.

DAST for mobile apps

DAST (Dynamic Application Security Testing) is a black-box testing methodology that analyzes a running application, often from an external perspective, to identify vulnerabilities that may be exploited during real-world attacks. Unlike SAST, which examines the codebase, DAST focuses on the application in its operational environment.

Mobile applications are susceptible to a variety of runtime vulnerabilities, such as insecure data transmission, broken authentication, and insecure direct object references. DAST is important for mobile app security because it allows you to simulate how an attacker might exploit these vulnerabilities. This gives you a more realistic assessment of your app's security posture.

Mobile apps frequently communicate with backend services, and DAST can help here too by identifying insecure API calls or data leaks over the network. It can also test the robustness of unique authentication mechanisms such as biometric authentication.

Some popular DAST tools for mobile development include:

OWASP ZAP: An open-source tool that can be configured to proxy mobile traffic, allowing you to identify vulnerabilities in API calls and data transmission.

Burp Suite: A mobile extension that can be used to intercept and modify HTTP/S traffic between the mobile app and the backend, providing insights into potential vulnerabilities.

Mob-SF: A tool that provides both security and dynamic testing.

Frida: While Frida is often used by bad actors for dynamic instrumentation, its ability to inject custom code into binaries and hook to function calls means it has also become a popular form of DAST for mobile apps. 

IAST for mobile apps

IAST (Interactive Application Security Testing) is a security testing methodology that combines elements of both SAST and DAST.

It analyzes an application's source code and its behavior during runtime to provide a more comprehensive view of potential vulnerabilities. IAST tools are typically integrated into the application as agents or libraries, allowing them to monitor the application from the inside.

Mobile applications often have complex interactions between the frontend and backend, as well as third-party libraries and services. IAST allows you to monitor these interactions in real time, offering insights into how data flows through the application and where vulnerabilities may exist. This is particularly useful for identifying issues like insecure data transmission between the mobile app and backend services, or vulnerabilities in third-party libraries.

Mobile apps often have complex data flows involving multiple services, databases, and APIs. IAST can track data as it moves through these components, identifying insecure practices like SQL injection or data leakage. Mobile apps also often use third-party libraries for functionalities like payment processing or social media integrations. IAST identifies vulnerabilities within these libraries that could compromise the application.

Hopefully by this point we’ve convinced you of the merits of mobile app security testing. But you might be wondering how you actually go about incorporating it into your build pipeline.

Fortunately, it's not as daunting as you might think.

Assessment and Planning

First things first, you've got to know what kind of threats your app might be up against and where it could be vulnerable. That’s where a threat model comes in. 

This process should help you to answer some important questions:

What are the security requirements for your app? 

Are you storing sensitive user data? 

Are you processing payments? 

Only after creating a threat model can you start picking out the right tools for the job. That’s because the risks you’ve identified will dictate your setup strategy.

Configuration and Setup

You'll probably be tweaking build scripts, most likely in YAML if you're using something like Github Actions, GitLab CI or Bitrise. The goal here is to make sure that your security tests run smoothly every time someone pushes new code.

Execution

This is where your security tests kick in and you can begin scanning your code for vulnerabilities in earnest. And here's a pro tip: try to parallelize your tests. It will make your pipeline run faster. The trick with mobile app security testing is not only performance, but also flakiness: so you will also probably need to run them several times. 

Monitoring and Reporting

You can't fix what you can't see. So, make sure you've got a solid monitoring system in place, which will provide test reports. And don't keep those test insights to yourself; share them with your team. Generate reports that can help you to make better data-driven decisions over time.

Feedback Loop

Last but not least, keep the lines of communication open. If a test finds a vulnerability, make sure it's flagged and sent back to the development team for fixing. This isn't a one-and-done deal; it's an ongoing process that keeps getting better with each iteration.

The integration of mobile app security testing into your build pipeline for mobile development is not merely an optional best practice; it’s a critical necessity.

The digital landscape is fraught with evolving security threats that pose significant risks to user data, corporate reputation, and financial stability. And so the adoption of a robust DevSecOps strategy, underpinned by a well-configured build pipeline, is vital for any organization committed to delivering secure, reliable mobile applications.

Testing enhances cost-effectiveness by reducing the resources required for late-stage remediation, it facilitates compliance with regulatory standards, and it contributes to building and maintaining customer trust. 

By actioning some of the steps outlined in this article, our hope is that you can significantly mitigate the risks associated with mobile application development.