There are about as many reasons to test apps for vulnerabilities as there are apps. For the purposes of this article, we’ll look at testing both as a creator of apps (and so trying to reduce the likelihood of an escape defect on our side doing harm at our company) and a consumer of them (being harmed due to a defect).
The Open Web Application Security Project (OWASP.org) is a foundation that has been working for a long time to set security standards for application security testing and I strongly recommend checking out their testing guide available at https://owasp.org/www-project-mobile-security-testing-guide/. Some of their techniques are architectural, like making sure that anything that is in an app is absolutely needed, documented, and that those dependencies have good security controls. Others include how apps communicate. Many of the controls from OWASP will call for vulnerability testing and/or scanning at some point. Luckily, much of this can be plugged into our automated build trains used to compile, test, and submit apps to their destinations.
Types of Scanning
There are two main types of vulnerability scanning, which can easily be automated: static and dynamic analysis.
Static analysis is scanning the source code of an app, so analyzing it from the inside out. Because we need the source to complete static analysis we either have to decompile an app or have access to the source and so it’s typically done by an application developer as a part of the pre-compilation step of the CI/CD process.
Dynamic analysis is scanning an app for vulnerabilities from the outside, in. This involves looking at the app as it’s running and/or decompiling the app to check the frameworks and libraries in use - looking for any potential vulnerabilities.
What is right for me?
Both have their place in a security-minded CI/CD implementation. The static analysis might see things that dynamic can’t and not only does dynamic provide run-time analysis but it can also uncover problems that came in due to a flaw or attack on the CI/CD infrastructure itself.
And it turns out that many of the tools available do both, so most of us don’t have to pay for two separate tools. So most of us can do both. Whether an internal app development team or one who builds tools destined for the consumer or enterprise app stores, scanning (even a hardened runtime) has should be done by most organizations.
The more complicated topic is which is the specific tool to use. If there’s a seasoned application security expert on the team, MobSF is a great tool that can do both static and dynamic access. We have to build out our own infrastructure to use it and there’s a bit of a learning curve - but anyone with the skills can use it free of charge (unless we want to pay for a support contract or training. More on MobSF can be found at https://github.com/MobSF/Mobile-Security-Framework-MobSF.
For those that just want to plug a tool into the build system, or into a device management infrastructure if just consuming apps (and so relying on dynamic vulnerability scanning), there are a number of tools available that each have their own pros and cons. Given that every environment is different (some can’t use SaaS providers, some have privacy restrictions, some need compliance, some might rely on a specific endpoint availability, etc) we’ll just provide a list here and say “ymmv - build a list of requirements and check each):
App-Ray: https://www.crunchbase.com/organization/app-ray Based in Austria and one of the more MDM-friendly of tools.
Codified: https://www.crunchbase.com/organization/codified-security Based in London and one of the older toolsets on the market.
Ostorlab: https://www.crunchbase.com/organization/ostorlab Built by a former Google Security Engineer and based in Morocco
Quixxi: https://www.crunchbase.com/organization/quixxi Based in Sydney and has an additional feature of phoning home to check for unlicensed use of the software
Immuniweb: https://www.crunchbase.com/organization/immuniweb Based in Geneva, also scans web apps (ymmv based on the language used)
AppKnox: https://www.crunchbase.com/organization/appknox Based in Singapore, can also scan our API endpoints
Data Theorum: https://www.crunchbase.com/organization/data-theorem Based in San Francisco, they offer a pretty expansive product and a full support and services infrastructure
All of these vendors do android and IPA scanning. For those integrating with a device management tool and scanning when purchasing apps, Ostorlab and App-Ray have the most integrations with other vendors, it’s easy to imagine a workflow where any .ipa added gets a dynamic analysis done upon upload and those from the app store are checked before making them available for distribution once they’re seen in Apple Business Manager or the Google Enterprise Play Store.
Note: None that I looked at currently support scanning Mac apps, but some do support scanning Windows and/or Chromium apps).
Conclusion
While many of the code pipeline tools do some forms of security scanning (e.g. dependabot alerts from Github), none get this in-depth or provide the pipelining for consuming and building. In the future I suspect they will - given the prevalence of OWASP and public vulnerability feeds - but we can’t build our plans around “some day”.
Every developer needs to protect our reputation and nothing will destroy a reputation faster than a CVE - or worse, a zero day vulnerability that gets exploited and results in a breach of customer data. None of us want law suits. This type of scanning can take as little as 15 minutes per build and some of the tools out there allow doing so using a freemium model. There’s no reason not to check our code and our runtimes before they leave our environments. The time and focus doing so takes away from other projects will be paid back with a high ROI when we don’t get pwned.