Mobile DevSecOps: Tools and Tips for Secure Mobile Applications in 2024

Mobile DevSecOps is the discipline of applying an organization’s development security policies to mobile applications. Securing mobile applications has traditionally been less of a concern than securing other forms of technology within organizations. However, as software supply chain security regulations increase, so does the need to codify security standards for mobile apps.

This shift is especially felt among organizations that haven’t traditionally considered themselves technology companies, such as banks, healthcare organizations, and airlines. In times past, mobile app development teams enjoyed a degree of autonomy within large organizations—but now organizations are seeking ways to bring these teams into compliance with their broader security policies.

This push for stricter mobile app security makes sense when you consider how many popular mobile apps in vital industries contain known vulnerabilities. According to the mobile app-vetting company NowSecure’s data in April 2023:

Many people rely on these apps (as well as others) to navigate and manage some of the most important parts of their lives. A successful attack can put a company’s reputation—and thousands of lives—in the balance. Securing the mobile app development process is a must.

However, this isn’t an easy issue to navigate. There are a lot of misconceptions about mobile DevSecOps and many common implementation challenges. So, we’ve created this starter guide to help DevSecOps leaders graft their mobile development operations into the greater DevSecOps system.

Here’s what we’re going to cover in this guide:

Mobile DevSecOps: an overview

To understand mobile DevSecOps, it’s important to know where this practice came from. (If you’re already familiar with this, you might want to skip straight to the mobile DevSecOps strategy section.)

Shift Left security testing

Mobile DevSecOps is a grandchild of Shift Left security philosophy. If you imagine the software development lifecycle along a timeline running from left (earlier) to right (later), Shift Left testing is an approach that assumes it’s better to start testing for security earlier in the development process rather than later.

This philosophy advocates for security to be part of the development process—not just something that happens once an application version is built. Hence, development operations (DevOps) began to incorporate security measures.

DevOps vs. DevSecOps

When software development began, teams of developers created applications, while IT operations teams dealt with making those applications work in the context of other systems. The back-and-forth between dev and ops teams ate up time and energy, so organizations began combining development and IT operations team functions into DevOps teams.

DevOps makes building and shipping software simpler and faster, but it doesn’t necessarily make the resulting software more secure. Therefore, many organizations now include security experts and policies in their development processes, turning DevOps into DevSecOps.

DevSecOps teams combine the efficiencies of DevOps with early attention to keeping applications secure. It’s a natural outcome of Shift Left security thinking, and organizations who do DevSecOps well enjoy the benefits of shipping secure code quickly.

DevSecOps vs. Mobile DevSecOps

Mobile DevSecOps is exactly what it sounds like; it applies an organization’s DevSecOps policies to its mobile app development processes. However, the history of mobile development (especially at large non-tech companies) has made mobile DevSecOps tricky.

Since the dawn of smartphones, having a mobile app has become a must for most large organizations—even if they weren’t considered technology companies, per se. For example:

For these companies, mobile app development teams were often given a good deal of autonomy because mobile apps weren’t seen as core business functions. Since app marketplaces imposed their own security standards on incoming apps, for a long time these teams also didn’t have to bother with big, company-wide software security policies.

However, software security is a much higher priority these days, so organizations are applying security standards to all their development efforts. As DevSecOps grows in popularity, once-independent mobile teams are being pulled under that umbrella.

Mobile DevSecOps and the software development lifecycle

Moving to mobile DevSecOps shouldn’t severely disrupt the mobile app development lifecycle—your teams will still plan, build, test, ship, and monitor your mobile apps. However, moving from mobile DevOps to mobile DevSecOps will introduce new layers of security to every step of the process:

  1. Planning: In addition to the regular planning activities, mobile DevSecOps anticipates the security risks and requirements that apply to the mobile app from the get-go.

  2. Building: Moving to mobile DevSecOps involves securing your build environment so only the right people and components get in. This might involve more stringent authentication processes—or tools that scan third-party software components for known vulnerabilities.

  3. Testing: When taking a new mobile app update for a spin (whether manually or via automation), a strong mobile DevSecOps shop will also scan the app for known vulnerabilities and check your proprietary code for security gaps.

  4. Shipping: A good DevSecOps approach will ensure that mobile app code is deployed safely. This may include a series of new tools, like a dynamic application security testing (DAST) tool to check your runtime app for vulnerabilities—or a runtime application self-protection (RASP) tool to detect and block malevolent user behavior.

  5. Monitoring: Your mobile DevSecOps team should have protocols for tracking mobile app security metrics, triaging fixes, and advocating for security measures in the SDLC.

If your organization already has a mature approach to regular DevSecOps, extending these policies to your mobile development teams should be a straightforward and smooth process.

3 key tips for setting up your mobile DevSecOps team

A mobile DevSecOps team isn’t very different from any other DevSecOps team—but there are a few things you should keep in mind if you’re creating a team like this for the first time.

how to establish a mobile DevSecOps team

1. Create a culture of mobile security

The most important thing to do when establishing a mobile DevSecOps team is to ensure the team understands how important it is to source, build, and ship their apps securely. This means bringing mobile developers up to speed regarding broader DevSecOps policies and training your team to look out for common vulnerabilities.

This is important because mobile apps (especially iOS apps) have traditionally required less security attention than Web and desktop software. If you’re moving from mobile DevOps to mobile DevSecOps, make sure that someone on the team has expertise in mobile app security, and consider investing in security and threat awareness training for the rest of the team. This will help them quickly incorporate security measures in their mobile development process.

2. Secure the mobile SDLC from both ends

As your mobile DevSecOps team matures, your security testing workflows will become more comprehensive and sophisticated, eventually saturating every phase of the SDLC. However, you might not be able to launch this team with all these workflows in place, so where should you start?

It’s tempting to simply add security as a final check before shipping an update to the app marketplace. But holding off on security checks until the eleventh hour often leads to surprises—and surprises cause delays.

So, when you start a mobile DevSecOps team, position them for success from the get-go. Set up workflows to scan all the components on which your developers are building your mobile apps. This will allow them to choose secure, compatible package versions, avoid packages with high-risk vulnerabilities, and develop proprietary code with a fuller understanding of how secure the foundational components are.

(If you use an SCA tool like MergeBase, your team can scan your apps, third-party licenses, and open-source code for vulnerabilities anytime—making it easy for your DevSecOps team to secure both ends of the SDLC.)

3. Select your testing methods early

When setting up a mobile DevSecOps team for the first time, clarify what security standards the team is expected to uphold—and articulate the testing methods they should use to gauge success.

Once these are established, set up the timelines, triggers, and triaging protocol for your chosen testing methods. Some of these tests will be entirely dependent upon your team’s productivity (e.g., running a software composition analysis on open-source Dart packages before bringing them into the build environment), and some might need to be checked on occasionally (e.g., checking a runtime application self-protection tool for malevolent user behavior reports once a week).

Having these in place will give your team a clear idea of how security testing should be done, how often it should be done, and how you’ll evaluate performance.

If you’ve followed these tips, you’re off to a strong start. But there’s still one very important piece to consider: the tools you equip your mobile DevSecOps team with.

How to build and prioritize the mobile DevSecOps toolchain

Your mobile DevSecOps toolchain is the set of mobile application security testing (MAST) tools you use to build, ship, monitor, and update mobile apps.

Keep in mind that MAST tools encompass the types of application security testing tools that your other DevSecOps teams are using—they’re just applied specifically to mobile apps. As you build out your mobile team’s toolchain, consider whether any existing AppSec testing tools you’re already paying for can scan your mobile apps.

There are many kinds of AppSec tools you could use, but if you want to catch the biggest threats without bloating your tech stack, we recommend prioritizing your MAST tools in the following order.

Mobile DevSecOps tools to prioritize

1. Mobile software composition analysis (SCA)

If you only have the budget for one MAST tool, it should be an SCA. A robust SCA tool in the hands of a good DevSecOps team can catch transitive vulnerabilities before they even enter your build environment—protecting you from the majority of code security threats your mobile app will face.

Most of the code in mobile apps is open source, which means if one of the components you built your mobile app on is vulnerable, your app is vulnerable, too. Open-source libraries are enticing targets to hackers because instead of needing to figure out how to hack your app specifically, they can attack “upstream” using publicly-known vulnerabilities to find their way into multiple targets.

A good SCA tool will protect you from this—but not all SCAs are created equal. When building your mobile DevSecOps testing stack, start with an SCA tool that:

There aren’t many mobile SCAs currently available, as the large SCA companies can’t scan Dart and Swift programming languages for vulnerabilities. MergeBase is currently the only tool on the market with Dart support that can offer the above level of protection to Android DevSecOps teams. (If you’d like to try it for yourself, start a free trial now!)

2. Mobile static application security testing (SAST)

The second MAST tool to add is one that scans your proprietary code. This, combined with the scans an SCA does for you on third-party code libraries, will give you a comprehensive view of your mobile app’s vulnerabilities and security readiness.

3. Mobile app hardening

Mobile app hardening tools set up your application to protect itself in runtime. App hardeners often combine automated vulnerability scanning and penetration testing to determine where your mobile app is vulnerable and mitigate those vulnerabilities.

This might involve automatically disabling vulnerable components and functions within the app or removing components that the mobile app rarely or never uses. This reduces the app’s risk exposure and often brings the bonus benefits of making the app more lightweight, stable, and fast.

4. Mobile dynamic application security testing (DAST)

Of the three main types of MAST tools, DAST is almost always the least vital to mobile DevSecOps. DAST tools scan your mobile application for vulnerabilities in runtime, which can be helpful when trying to understand how people are attacking your apps.

However, given how mobile apps have relatively lower exposure to malevolent Internet users, DAST usually shouldn’t be prioritized over SCA and SAST in a mobile DevSecOps context.

Common mobile DevSecOps challenges to watch out for

Establishing mobile DevSecOps teams, toolchains, and policies isn’t always easy. Beyond the generic difficulties that any organizational change incurs, you’re likely to face a series of obstacles specific to the world of mobile development—especially if you’re not primarily a software company.

1. Organizational apathy regarding mobile security

Traditionally, securing the mobile app development process hasn’t been a high priority among organizations. Some of this is for good reason:

Mobile programming languages have fewer known vulnerabilities than that of conventional desktop and web app programming languages—there aren’t as many ways to hack an iPhone app as there are to hack an app parked on a publicly accessible website.

Mobile app marketplaces require apps to meet some degree of security standards before they’re even approved for listing in the store—which means some mobile development teams have been essentially outsourcing application security testing to the Android and Apple markets.

All of this can contribute to the assumption that mobile DevSecOps isn’t worth the time and resources it consumes. DevSecOps advocates shouldn’t be surprised when they receive this kind of pushback. Instead, build a case for consistent security measures across in-house technology: show leadership how your organization’s mobile applications stack up against your broader security standards and what kinds of threats your current state of mobile DevSecOps leaves you vulnerable to.

2. Overextended mobile development talent

For non-tech organizations that make their own mobile apps, development talent is often already stretched thin. Adding security protocols to the mobile app development lifecycle only stretches them thinner.

To mitigate this, invest in a mobile DevSecOps toolchain that automates new (and existing) security work. The right set of tools will make it easy for your team to spot, prioritize, and fix vulnerabilities faster than they could before. If you use a tool as accurate as MergeBase, you’ll save your developers a lot of time that they’d otherwise spend on false positive–induced wild goose chases.

3. Resistance to red tape

For many large organizations, the mobile app team has been able to run their own show for over a decade. But now, organizations adopting DevSecOps practices are bringing new official policies to mobile teams—which means these teams aren’t as autonomous as they once were.

Adjusting to this sort of change can be difficult—especially since many of the folks who ended up on these free-floating mobile development teams were attracted to the “Wild West” nature of in-house mobile app development. Good leaders will recognize this and seek to understand how mobile app teams have been running themselves instead of simply handing down new standards from on high.

4. Skepticism regarding MAST tools

Unfortunately, the mobile-oriented AppSec tool market isn’t as mature as the general AppSec space. It’s not easy to find tools that can scan mobile programming languages for vulnerabilities and provide accurate, actionable reports. Experienced mobile developers may have been burned before by tools that missed vulnerabilities, wasted time on false positives, or didn’t provide adequate guidance to help them fix issues.

They don’t want that experience again.

One way to work around this is to build out your mobile DevSecOps toolchain only with tools that legitimately make the process of securing your apps less time- and labor-intensive. This might look like creating a list of must-have capabilities for every piece of your MAST toolchain and only bringing on a new tool if it meets those needs.

The good news: MergeBase is a fully functional mobile SCA tool for apps built in Dart. It enables you to scan your applications and components for known vulnerabilities accurately and provides top-of-the-line guidance to developers. No other SCA on the market right now covers your Dart-built mobile apps like MergeBase—start a free trial to test it for yourself!

5. Mixed opinions on mobile’s inherent security

We’ve discussed how developers familiar with mobile app security know that mobile apps tend to be more secure than more traditional applications. However, stakeholders don’t always share this understanding. Because mobile apps are newer than desktop and web apps, it’s easy for non-technical leaders to assume mobile apps are inherently less secure.

This confusion can make it challenging to cultivate buy-in on mobile development teams. If they get the idea that DevSecOps policies are being enforced by out-of-touch worrywarts, they’ll be less likely to take them (both the policies and the leadership) seriously.

You can counteract this by presenting mobile DevSecOps rollouts as synchronizing your mobile team’s security practices with those of the broader organization. This keeps the conversation around mobile DevSecOps changes neutral—so non-technical stakeholders won’t assume mobile teams are doing something wrong, and developers won’t feel condescended.

6. Loss of institutional knowledge

Some organizations built their first mobile apps fifteen years ago—and the developers who built them are long gone. Depending on your organization’s state of DevSecOps and documentation, your mobile DevSecOps rollouts might reveal long-neglected issues. If your mobile team has been largely free-reign and has experienced significant turnover, be sure to factor technical debt into your rollout plan.

7. Testing across various devices

There are myriad models of mobile devices—especially of the Android variety. Strong DevSecOps policies will ensure that your apps are secure across all the devices a user might install. This can be a tedious process, so take this into account when estimating how long the testing process will take in your SDLC.

8. Overestimating the strain mobile DevSecOps puts on a team

It’s a common misconception that transitioning to mobile DevSecOps is a big hassle, but it’s a more straightforward process than most people think. As discussed, mobile programming languages have fewer known vulnerabilities to exploit, and mobile apps are usually less exposed to malevolent activity.

Beyond this, mobile development platforms tend to stay up-to-date and include sophisticated package dependency managers. This speeds up and simplifies the process of upgrading components—which means fixing a vulnerability in a mobile app can be far less of a hassle than it is for other applications.

Uplevel your mobile DevSecOps with MergeBase mobile SCA

An accurate and helpful mobile SCA is the cornerstone of the mobile DevSecOps toolchain—and MergeBase is the only SCA that can scan Dart-built apps with high levels of accuracy and developer guidance.

If you want to improve and streamline security testing for your mobile apps, MergeBase is here to help. Start a free trial of MergeBase today and discover how easy it is to find and fix vulnerabilities in your mobile (and other) apps!

Related Posts