Testing with App Shielding and Secure SDKs for your Mobile DevSecOps Pipeline

Mobile DevSecOps emphasizes the importance of collaboration, automation, and continuous monitoring to create a proactive security culture. By incorporating security measures from the very beginning and fostering a sense of shared responsibility among developers, security professionals, and operations teams, organizations can accelerate development cycles while reducing vulnerabilities and maintaining a high standard of application quality.

Mobile app shielding enables you to use proactive security measures for your production application. I recommend checking the OWASP Foundations Mobile App Top 10 list for security insights and recommendations for software security. 

App shielding for iOS and Android applications gives you protection against the most common threats.

To mitigate this, you need to obfuscate your code, to make it harder for threat actors to reverse engineer your application, by preventing unauthorized access to proprietary algorithms, business logic, and sensitive data.

An attacker might inject unwanted malicious code or services into your application to distribute it to your users to steal data. For them to inject code, they need to repackage the application to be able to start distributing it. Anti-tampering and repackaging can detect such attempts and will fail or block your app from starting.

Mobile app shielding can help encrypt this data both in transit and at rest, reducing the risk of data breaches and unauthorized access.

Swizzling/hooking attacks manipulate an app's behavior during execution. Shielding can provide runtime protection, monitoring app behavior and preventing unauthorized code execution or manipulation.

Organizations operating in highly regulated industries, such as finance or healthcare, need to comply with strict security standards, such as GDPR, HIPAA, PCI DSS, PSD2, FFIEC, and various other regulations for compliance.

There are several additional components that Shielding and SecureSDKs detect, which keep the application from launching. These include:

Additionally, you do get other benefits from using app shielding, including:

By obscuring the app's code and making it harder for attackers to decipher your code or the services communicating with your app, app shielding protects your IP, business logic or trade secrets. 

By providing comprehensive security measures to protect sensitive data and maintain app integrity, mobile app shielding can contribute to a higher level of user trust and confidence in the application.

The open source OWASP Mobile App Security community provides detailed guidelines and testing strategies that would help to mitigate security issues. 

These providers have been in the market for a long time, and they test their SDK/Shielding process extensively to ensure your application is not crashing.

DevSecOps - Agile Mobile App Defense! No code, No SDKs, and No servers required.

Developer friendly app shielding!

The full spectrum of protection for iOS apps! 

Shrink your Java and Android code shrinker for Java bytecode, to enhance and optimize mobile app code.

Helps prevent sensitive data loss and infrastructure exposure, resulting in fraud, reputational damage, and regulatory penalties

Helps keep code clean with accurate, fast mobile application security testing integrated into your dev tools of choice. Automatically analyze binaries in your pipelines and repos for security and privacy flaws in minutes. 

The first recommendation is that you should not use a version of the app that has been downloaded from the App Store or Play Store. Most of the cloud providers have to use certain tampering and repackaging methods to run your application at scale. 

If you’re testing a debug version of your app, make sure to remove app shielding or at least lower the protection levels to a point where tests can run. 

This is possible by creating different build targets and build variants for your application.  

It is usually recommended to run your automated pipelines with the debug version of the app, to iterate fast and get feedback back faster for your application.

The checks that need to be disabled (or lowered) are:

If you’re using a third-party SDK for a particular function like biometrics instead of using Apple’s or Google’s native biometrics APIs, it means that while you may have removed or lowered the protection levels in your app, this won’t affect the third-party SDK. Third-party SDKs also implement app shielding techniques and you’ll need to work with your third-party SDK vendor.

Don’t be fooled by the error messages thrown by the application, since the SDKs and mobile app developers do not tend to handle this advanced level of app security and tampering that we do. You might get an error message as a result. 

The main category of errors you might encounter is if the application is not able to launch or it crashes. In this case, you might get: 

However, these error messages could be incorrect or misleading, and you’ll need to ask the shielding/SecureSDK provider or developer how they do code injection, repackaging, re-signing, or tampering with app detection.

Appdome’s comprehensive guide offers explicit advice on how to run these applications at scale. 

The second category of error is if the app fails to serve any network request. In this case you might see: 

Finally, during sign in or sign up, the application or the network request could fail, while the backend server is checking the originality of the application. Your application could send up traces of tampered data, where your backend server will reject any request coming from the application. This can happen while using any login-related authentication, like biometric authentication, or SSO login.

When you’re integrating these solutions and SDKs into your application, make sure your mobile architecture enables you to easily switch between these SDKs, to reduce the switching cost when there is a more reliable platform on the market, or if your current provider goes through a security breach. You always need to be prepared to switch to the most secure and advanced technology. 

Increased dependency will result in slower security threat mitigation, reduced negotiation power, and could stifle your innovation. Slower response to emerging new mobile threats is one of the biggest challenges your business can face. Vendor lock-in can lead to an overreliance on one provider for your mobile application security needs, increasing the risk to your business if that vendor's solution becomes obsolete or is compromised.

Testing protected apps does create some advantages, and usually it is advised to test it once SecurSDK/shielding is letting your application launch or initialize successfully. You should validate it once every major release. 

There are a few scenarios in which you might run into issues. When using a production version of your app that has been downloaded from the App Store or Play Store; when using a staging version of your app created with obfuscation or shielding enabled; or when using a debug version of the app that has app shielding implemented.

This isn’t a bad thing though! The reason these tests are failing is because the app shielding is doing its job. So it isn’t necessarily a failed test, as you have validated that app shielding is working on these cloud providers, and tampering has been blocked!

Integrating app shielding and secure SDKs into your mobile DevSecOps pipeline is essential for ensuring the security and integrity of your mobile applications. However, when testing shielded applications on cloud providers, it is crucial to be aware of the challenges and potential issues that may arise, and how to mitigate them.

As a key takeaway for mobile app developers and testers, it is important to be prepared for potential issues and to adopt a flexible approach when testing shielded applications on Sauce Labs or with other cloud providers. 

This includes creating different build targets and build flavors, working with third-party SDK vendors, and understanding the error messages that may arise during testing.

By staying informed and prepared, developers can ensure the highest level of security for their applications while maintaining an efficient and reliable testing process, ultimately enhancing user trust and satisfaction.