This is a multi-part blog series about Appdome as a mobile DevSecOps platform. In a DevSecOps world, organizations need to rapidly build in-app mobile security features into iOS and Android apps quickly, at every phase of the software development lifecycle (SDLC). In this post, I will discuss how taking an SDK-based approach to implementing mobile app security makes that impossible. This blog explains how SDKs can NEVER fit into a DevSecOps model.
First, let’s get a few definitions straight.
What is DevSecOps?
DevSecOps is a software delivery methodology that automates the delivery and implementation of security at every phase of the software development lifecycle, from initial design, through integration, testing, deployment, and software delivery. My colleague Jan touched on this concept in a previous blog where he described how the worlds of the “DEV” and “SEC” teams are often not aligned (partly because everything in the DEV world is automated, and most things in the SEC world are manual). The true promise of DevSecOps is about built-in mobile app security, which is delivered as a fundamental part of an agile software delivery model, and where security is integrated into the mobile application at every phase – not bolted-on at the end of the release cycle. Implementing mobile SDKs often requires significant changes to source code, and that requires lots of time, resources and effort. Therefore, implementing SDKs simply does not fit into the modern agile release model (because the length of time required to implement mobile security SDKs is often longer than the entire release process). Allow me to elaborate.
What is an SDK (aka Mobile SDK)?
An SDK is a document whose purpose is to guide a mobile developer on how to modify the source code of a mobile application in order to implement a feature or connect to some service via APIs. There is nothing automated about an SDK, because an SDK is nothing more than a toolkit….SDKs are not real unless mobile developers actually implement the functionality in their Android and iOS apps (and that means changing the code). Now that we covered what an SDK is, let’s discuss what SDK is NOT:
- An SDK is not a product
- An SDK is not a feature
- An SDK is not an outcome
- An SDK is not a solution
- An SDK is not even a plan
Debunking SDK myths
Simply put, to ‘implement’ an SDK in a mobile app requires humans (aka mobile developers) to either write brand new code or change existing code in their mobile application to make the mobile application do something that it does not do today. An SDK represents the ‘potential’ of what the application ‘could’ or ‘might be able to do’ IF mobile developers ‘implement the SDK’. When it comes to mobile app security, the providers of SDK-based security solutions often downplay the effort required to implement their SDK as ‘one line of code’. Another common trick is describing the features or capabilities that are possible if a developer implements the SDK, without actually describing “HOW” (as if the features magically appeared in your mobile app without anyone doing any work). There’s a reason for that…..It’s because with any mobile SDK, YOU (meaning the customer or the mobile developer) need to do all the work in order to make the feature or capability become a reality inside a mobile application. And it’s usually a lot of work.
Another crucial element is in how development and operations teams get work done as part of an agile delivery process. Automation is a fundamental part of the tools, methods and processes in how they build, test, deliver, integrate, and release mobile applications. Mobile Security that relies on SDKs is 100% manual. Bottom line is that in order to deliver security features with a DevSecOps paradigm requires the implementation of the security solution to be automated (ie: no coding whatsoever). Another critical characteristic is that the security solution needs to cover all development frameworks out of the box – again with no manual coding. SDKs, by their very nature, do not and cannot meet those requirements.
Key Questions to Ask Yourself *Before* Considering Using Mobile SDKs to Secure Apps
Here are some important questions to ask yourself (and the SDK provider) before embarking on a plan to use SDKs or other DIY approaches (such as 3rd party libraries) to deliver in-app mobile app security:
- Do you have the developers on staff to implement multiple security SDKs? To achieve a multi-layered defense, the bare minimum security best practices you’ll typically need to implement are app shielding, anti-tampering, anti-reversing, code obfuscation, data encryption, jailbreak/rooting prevention, and MitM prevention (such as certificate pinning or certificate validation). Each feature might be an independent development and require at least 2 or more SDKs to implement (for iOS and Android).
- Does the SDK support the framework or programming language that your app is built-in? If not, does the vendor have plugins? And how much extra work is it to implement the plugin to reach a specific framework.
- How does the SDK handle non-native code, frameworks and libraries? If your solution relies on source code changes to implement security, you may not even have access to the source code. What do you do then?
- What about apps built with multiple programming languages. For example, an Android app written in Java or Kotlin where native libraries are imported in either C or C++? Do you need separate SDKs to implement security? Or are there incompatibilities that prevent you from implementing encryption, obfuscation, anti-tampering in multiple coding languages?
- Even if it’s possible, do you have the resources and skills on your team to do this work manually?
- Do you have the development staff to stay allocated to the project for things like maintenance, support, integrations?
- What happens when something breaks? Who fixes it? (Answer: not the SDK provider. They simply can’t).
- Does your team have all the required skills in the specific functional area of security?
- Do you have developers that are encryption experts? What about malware prevention? Preventing MitM attacks? Preventing overlay attacks, Code Obfuscation?
- Do they know when it’s better to implement encryption vs obfuscation for any given data type or workflow?
- Does the SDK have coverage to encrypt all the data stored in the sandbox, strings, app preferences, resources, memory?
- How deep are the security protections? Do the protections use multiple detection mechanisms scattered throughout the app, or triggered at different times? Does the protection cover multiple API or code layers? For example, to offer effective protection against malicious debugging, the solution needs to protect against JDWP-based debuggers at the Java level, and against ptrace-based debuggers at the native C or C++ layer.
- Do the security protections complement and reinforce each other? For example, if you implement root/jailbreak prevention or anti-tampering via an SDK or library, but you don’t sufficiently obfuscate the source code and logic, then attackers or can simply reverse engineer the app to locate the code that provides the protection and either disable, bypass or change the code to circumvent the protection.
- How well does your team understand authentication? Can they implement the SDK securely, so that the APIs cannot be reverse engineered? How do you ensure the SDK is also obfuscated so that a hacker can’t simply reverse engineer the code, find the security SDK, and disable it?
- Does the SDK support the frameworks and specific programming languages that your apps are written in? Most SDKs are written for native apps only. Multiple plugins might be required to reach different frameworks, and in some cases and the SDK vendor may not have the specific plugins to reach YOUR app. If they don’t have it, your project is either delayed or even halted while you wait for them to build it (which may require an engineering effort on their part, followed by more manual coding for the developer).
Hidden Costs of Mobile SDKs
The diagram below illustrates the hidden costs of using SDKs to implement mobile app security. Most of the work, cost and effort are hidden below the surface. And don’t rely on the SDK provider to tell you this.
Now if you’re like most app makers, you probably don’t have an answer for most of these questions. And neither does your SDK provider. Why? Because as I said before, with an SDK-based approach, all the hard work is left to the mobile app developers. YOU deliver the outcome. With SDKs, the unfortunate reality is that mobile developers usually don’t have enough time to implement even a fraction of the capabilities advertised by most mobile SDKs. The result: the app is usually left unprotected.
SDKs Don’t Provide Security Solutions
This is what I mean when I say that an SDK is not an outcome and an SDK is not a solution. And it’s even far more complicated in practice than it sounds. In an upcoming blog post, I’ll go through the specific steps of what it takes to implement an SDK – for a single security feature in a single app (hint, it’s a lot of work). And that will provide an even deeper understanding of the complexities and sheer amount of work that is truly required to deliver mobile security features into mobile apps.
So let me ask you how manual SDK implementations can ever fit into a development methodology that is agile and automated at every level from design thru to delivery and everything in between? Simply put, they can’t.
In order to deliver security as an integral part of DevSecOps, organizations need to apply ‘developer best practices’ to the process of releasing security features to their mobile apps. In essence, they need Security Release Management. This is how some of the biggest banks in the world are delivering a comprehensive set of security features into mobile apps continuously, as part of an agile workflow where everything is automated from the design to development to production deployment and delivery. I will cover Security Release Management in detail in an upcoming blog post.
Recommendation to Mobile Developers
Trying to achieve a security outcome using SDKs is hard, time-consuming and devoid of a guaranteed outcome. If you are looking for a rapid mobile app security solution, then you owe it to yourself to consider Appdome’s Security Release Management. Automating mobile app security is the path to achieving the promise of DevSecOps. SDKs are not DevSecOps.
For a live demonstration of anything discussed in this blog post, request a demo today!
To open an account or start a trial, please use the button below.
