Mobile DevSecOps: Building Security into Every Phase of the LifeCycle

The broken access controls recently found in the mobile banking app Money Lover are just another example of an all too familiar story. Earlier this year, a security researcher discovered that their shared wallet feature was leaking transaction data. While the leaked data was limited to email addresses, transactions, and other metadata, there’s still potential for threat actors to use the data for nefarious purposes. Even if the data is never abused, their brand will take a hit in the eyes of consumers.

Despite stories like this, we continue to see a disconnect between the level of mobile app security risk and security practices. To close this gap, it’s imperative that developers integrate security into every stage of the mobile app software development lifecycle (SDLC).

DevOps is evolving into DevSecOps

DevSecOps stands for development, security, and operations. As the name suggests, it’s a more security-conscious approach to mobile app development, in which security tools and processes “shift left” or are integrated into each phase of the lifecycle.

The benefits of adopting DevSecOps include:

• Reducing bottlenecks that can occur when deferring security to the end of the development lifecycle.
• Optimizing security and reducing human-error through automating security testing.
• Easily documenting compliance with regulatory requirements.
• Reducing rework by remediating vulnerabilities before building dependencies upon faulty code.

Learn more about the mobile DevSecOps lifecycle phases and best practices for integrating security throughout the SDLC.

Phases of the mobile DevSecOps lifecycle

See how to strategically integrate security into each phase of the DevSecOps lifecycle.

Phase 1: Plan

The planning phase is iterative, just like the overall development process. Feedback and requests are gathered from various stakeholders, including subject matter experts (SMEs), product owners, customers, and end-users.

These are translated into functional requirements and objectives for the future build, and they’re evaluated in terms of their viability and priority. Some may be prioritized over others, added to the backlog for a later build, or rejected entirely. After finalizing the list of requirements, prior to writing code, the development team will plan their backlog and determine which requirements will be prioritized in the coming releases or sprints.

In this phase, developers should explore what threats their mobile app might face after release, as well as any regulatory requirements or industry standards it may be subject to. Through threat modeling, developers take the perspective of an attacker to gain a deeper understanding of their threat landscape. This exercise can be supported by security professionals in the organization that help challenge the development team during their planning and design.

This exercise can include:

• Planning for common vulnerabilities and threats.
• Addressing industry-specific threats, such as piracy and cheating for gaming apps.
• Mapping process and data flow.

After determining what attack vectors they need to prepare for, developers should evaluate mitigations and potential protections. OWASP MASVS is invaluable here, as it provides a mobile-specific framework for mapping security requirements to the appropriate remediation or protections.

Phase 2: Build

The build phase is usually performed in sprints or iterations, and this is when developers begin writing and committing code to the shared repository. In addition to the code written in house, they will often integrate third-party code dependencies, such as libraries and SDKs. It’s a common and accepted practice that allows developers to repurpose popular components rather than building them from scratch. However, this can introduce new and potentially unknown vulnerabilities.

Phase 2 security practices

In this stage, developers implement a secure design, as well as the mitigations, and protection mechanisms they identified in Phase 1. While they may not be actively used at this stage, the protections should be built in or accounted for as code is being written.

Developers should adopt secure coding best practices. The OWASP Secure Coding Practices guide is technology agnostic, but the principles apply to mobile app development. The resource covers input validation, output encoding, system configurations, file management, and more.

They should also follow security best practices around handling sensitive data, such as the management of authentication credentials that are stored within the code to prevent their leaking into the production release.

• Don’t store unencrypted credentials as readable strings.
• Don’t use a common encryption key for all strings to prevent a single point of failure.
• Have clear protocols for communicating with the server that have been reviewed by a security expert.

The application can be further protected by implementing code hardening, which will obscure the internal logic of the mobile application. This can include code obfuscation, like encryption or renaming classes and other variables, and removing certain metadata.

The team lead should establish a baseline of security knowledge and internal standards, including verification processes, documentation, and training. Not only will this contribute to the security posture of the overall build, but it also ensures the development team will apply these best practices more consistently.

Phase 3: Test

In a CI/CD pipeline, the majority of testing should be automatically triggered with every build, including functional, integration, regression, performance, and other types of tests. This is to ensure the build meets the requirements established in Phase 1 and to identify bugs early for faster and more cost-effective remediation. Each of these tests should generate a report detailing any defects and (ideally) suggested next steps.

Security in Phase 3 includes both manual and automated security tests, through which the app is scanned for vulnerabilities, credentials stored as readable strings, or API tokens that could be exploited later. Again, these tests should generate a report with their findings, priority levels, and recommendations to guide remediation efforts.

Static Application Security Testing (SAST) is used at this stage. It analyzes the mobile app’s source code, searching for vulnerabilities that would allow threat actors to access the internal logic of the mobile app.

When all the components of the app have been assembled, it should be tested at runtime. Dynamic Application Security Testing (DAST) mimics an outside attack when the application is in use, searching for any additional vulnerabilities that would allow a threat actor to gather information, reverse engineer, or modify the intended behavior of the app. Pre-release, this is completed on test devices.

Manual pentesting may be used here as well, to meet internal security requirements or as mandated by compliance requirements in more highly-regulated industries. Pen tests focus on end-to-end scenarios and search for more complex issues, making them a great complement to the security tests listed above.

Phase 4: Release

Verification before release is a critical part of this phase. The development team works to ensure that all bugs and coding errors that were uncovered through testing have been sufficiently addressed.

By shifting security left, developers should’ve moved much of the heavy lifting to earlier stages of the lifecycle. Now, the priorities are to verify that the protection mechanisms are implemented and functioning correctly and that regulatory requirements are being adequately addressed.

Even if DAST and manual pentesting were implemented in the Test Phase, they should be completed on the final version of the code to verify that no last-minute vulnerabilities were added to the code.

After the app’s initial release, manual pentesting will likely need to be completed periodically throughout the lifecycle of the app. This process is too costly and time consuming to implement after every build or subsequent releases, but it is required to verify that the app meets (and maintains) specific security requirements in highly-regulated industries.

Phases 5 & 6: Operate and monitor

It’s go time! The mobile application has been released and end-users have downloaded it to their devices. At this stage, developers should be monitoring usage, noting new feature requests, and releasing patches.

While the development team has been working toward an improved security posture throughout the SDLC, much of their work will come to fruition after the app has been released. These two monitoring functions actively run during this phase.

• Runtime Application Self-Protection (RASP) monitors for suspicious behavior at run-time, seeking to detect any dynamic analysis and tampering.
• Threat monitoring provides real-time visibility and context around suspicious activity, new threat vectors, usage patterns, and more.

By monitoring the app’s usage and performance, developers can understand any issues that result from implementing security measures and use that to tune the future builds of their app. Threat monitoring will also help developers gain further insight into real-world threats, enabling them to refine their mobile application and respond to the actual threat model observed in the wild.

Set your development team up for success

Education

Many development teams are playing catch up when it comes to mobile app security, largely due to a lack of expertise. The ongoing cybersecurity gap has forced developers to approach security on a trial and error basis or seek security knowledge on their own.

To more effectively bridge these two disciplines, companies should facilitate additional training on security best practices and common threats from experts like OWASP. Not only does employer-sanctioned training demonstrate the organization’s commitment to cybersecurity to internal and external parties, but it also ensures a more consistent and cohesive application across the development team.

Technology & automation

Learning about and implementing comprehensive mobile app security is no small task. Testing tools and protection solutions can be in house or purchased from a third party based on internal resources and expertise.

Tools with automation capabilities should be prioritized because they help prevent development teams from getting bogged down with manual tasks and ensure security processes are repeatable and scalable.

But developers should carefully evaluate any solution they consider. For example, app shielding and no-code solutions may be easier to set up at the outset, but compiler-based solutions provide more robust protection.

Finding the right balance

DevSecOps may look different from one organization to the next based on their threat model, release schedule, relevant regulatory requirements, and so on. Regardless, security can and should play an important role in each stage of the software development lifecycle.

While it may take time and experimentation to find the right balance between security concerns, operational requirements, and consumer demand, mobile app security can seamlessly integrate into developer workflows, reducing bottlenecks and rework.

By proactively aligning people, processes, and tooling behind the shared goal of a robust security posture, mobile app development teams will be able to deliver secure apps faster.

Executive Summary (TL;DR)

• Mobile DevSecOps is a necessary evolution of DevOps that addresses increasing and more sophisticated threats.
• In DevSecOps, mobile app security is woven into each phase of the SDLC.
• Education, technology, and automation are key to ensuring your implementation of DevSecOps is successful and your mobile app is protected.