Is it safe to combine CI/CD tools with external cloud mobile app protection solutions?

The modern mobile application market requires developers to move fast. It’s all about merging frequently, deploying on a weekly or bi-weekly cadence, incorporating feedback from users, and monitoring application behavior. 

But this is impossible without constantly merging developers' changes and deploying new versions of the app all the time, too. There’s no shortage of tools - called Continuous Integration / Continuous Deployment platforms - out there to help. Solutions like Bitrise.io, MS App Center, Github Actions, Circle CI, and others allow you to build and deploy mobile applications using their cloud solutions. 

In this article we’ll explore why so many developers are using cloud-based CI/CD platforms. And we’ll explain how you can combine them securely with app protection solutions.

Going from a bunch of source code files to a published app is quite the journey. After getting sources from code storage and compiling them, you need to run tests and other tools to assess the quality. Then you need to apply some protection measures, including signing. Only then can you send it for publication.

Imagine you started building a new mobile application from scratch with a couple of other developers: you have nothing to begin with aside from the idea of an app. 

To build a CI/CD pipeline - something you can’t proceed without - requires quite a lot of work. You need a repository to store the code in, for example. You also need a computer that’s different from the one you write code on in order to build the application - unless you want to be a bottleneck for the whole team. 

This computer will have to run some scenarios to build your app, like running Gradle or Xcode build. It will also need to get the source code from the repo, have signing certificates securely accessible, and make a connection to application stores to publish the app. 

As well as this, you’ll likely also need this computer to be manufactured by Apple, since there’s no other hardware you can build an iOS app on. Lastly, if you want to have several builds in parallel, you need to orchestrate the build process. You could install Jenkins and its agents to several machines and run the whole story, of course, but this would require a lot of time and effort. 

In the end, you’ll need to know via a mail notification either that the build has been completed successfully, or that it has failed. More efficient still would be a pipeline status on the code storage, which requires additional integration setup. Whichever way you look at it, it sounds like a lot of work.

This is where cloud CI/CD solutions come into play. 

Many cloud services have some of the typical mobile development steps already integrated: installing react-native dependencies, signing the app, running tests, publishing to MS App Center, sending notifications, or having integrations with code storage platforms. The cost of those services is low - particularly when compared to a developer’s hourly rate. This makes them a great tool for developers to focus on app development without worrying about the delivery pipeline itself when there’s no existing infrastructure in place.

Before we move on to explore the best ways of protecting your app as part of the wider CI/CD process, a quick reminder about why security is so important might be useful.

Distributing your application without any protection is extremely risky. You need to safeguard the app from illegal redistribution, protect the data it writes on the device, secure its business logic and intellectual property (like assets or ML models) and make sure the app doesn’t have pre-existing vulnerabilities. 

These are all tasks that can be completed using an app protection solution. It obfuscates the app’s logic, introduces integrity controls, and protects the file system APIs with the encryption-enabled versions.

CI/CD solutions should be reliable, high performing, secure, and cost-efficient: otherwise, there would be very few developers trusting them as the key part of the application delivery process. After all, reputation is a tough thing to build but can be ruined in a matter of hours. That’s why CI/CD vendors pay a lot of attention to making their infrastructure secure. 

One of the important aspects of the CI/CD pipeline is building reproducibility. As a developer, you expect that if you build the same code twice in a row, then you’re going to get the same binary twice in a row. To grant reproducibility vendors use modern virtualization technologies like virtual machines and containers. This also helps with security: nothing can influence your build except the code of your repository. 

A key step in the mobile application publication journey is signing. The private keys should be kept secure; this leads the CI/CD vendors to treat the application secrets carefully. Usually, this is achieved by encrypting those secrets and making the encryption keys accessible only by the building runtime. 

The last thing worth mentioning is protection from external threats. The CI/CD infrastructure should be guarded on the network level by allowing only necessary network ports, filtering traffic, introducing application level firewalls, encrypting traffic, and so on. 

Infrastructure should also be updated frequently as well to have any discovered vulnerabilities patched.

CI/CD vendors can properly secure their infrastructure as they own it and value their reputation. 

But can they do the same with external vendors?

We talked earlier about reasons to repackage or protect your app. Third-party services claim to do the necessary work and protect your application from further attacks. But once you build the app on a single cloud service and then use another cloud-based one for the application protection, you increase the risks for the overall app delivery. Particularly when it comes to application integrity.

Any service outside the deployment environment is a risk from a security point of view. Not to mention in terms of availability and cost. 

First of all, you have to support a secure channel between the cloud environments: this includes at least a VPN network and proper authorization and authentication on behalf of the cloud service. The package itself should also be protected as there’s data in transfer and, we know that while encryption is easy, key management is hard. Aside from having the package encrypted, you should also ensure its integrity, preferably using not only a checksum but an encryption key.

The second consideration is that it should provide high availability. Let’s imagine you have a strict deadline for release due to either legislation or technical requirements. You rush the development process and finally submit your app for release. Your pipeline triggers the third-party protection tool and, instead of working for the bundle, it replies with a 502 error. You re-run the pipeline but the error is still there. You reach out to the support team at the cloud mobile app protection service, but they can’t provide you with any ETAs. This is a major risk from a supply chain point of view - not to mention for the reputation of your business.

The third consideration is exposing the unprotected application outside of the deployment pipeline. The threat model of almost any company has to include a malevolent employee; this is why we have a principle of least privilege in the first place. Let’s say there’s just one employee at the third-party company who has access to the app protection infrastructure. It would be easy for them to install a file system hook, which could dump all the unprotected APK files and upload them to a server outside the company - or even to a workstation where said employee could copy it to a flash drive. 

Then there’s the possibility of a network sniffer being installed on the service infrastructure. Internal documents can be of lesser interest to hackers than the applications which go through the service. 

These are just some examples of supply chain-related threats. We haven’t covered others like using the wrong dependencies on the build server, building from a different source code than intended, and so on. Each SaaS should carefully examine threats and provide proper protection. If there is a combination of those services, it becomes much harder.   

The last consideration is about the App Bundles format for Android applications. With the shift from APKs and the introduction of features like Code Transparency, a new set of issues arises from the cloud mobile app protection services perspective. 

First of all, if you leverage Code Transparency, which is an application signature for App Bundles, you need this third party service to manage your application signature, which is also risky. If you don’t do so, then you can’t leverage this tool as an integrity control. Again, not an ideal scenario by any means.  

Another problem will arise once you start using Runtime SDKs, which are required to properly manage the permissions of the third party libraries. There is zero understanding of how to manage signatures for them when using cloud mobile app protection services.

We can see that the application handover from a CI/CD pipeline breaks the internal (and well protected) perimeter and exposes an unprotected application to lots of risks. 

That’s why our recommendation is to manage app protection in the same environment you build and deploy the application. If you build it on-premise, use locally installed app protection solutions. If you go with the cloud solutions, stick to the tools and integrations supplied by the same vendor. 

For example, bitrise.io has a list of verified steps that you can leverage in the CI/CD pipeline. You can also ship the app protection tools alongside the application itself and run the app protection from there without breaking the CI/CD perimeter. If you’re using Github Actions, you can create a custom action running an arbitrary binary or even running a docker container. That way you leave all the sensitive transformations of the application in the same environment. 

Using an on-premise tool as part of the CI/CD pipeline mitigates a long list of risks connected to combining different execution environments. Many of which we’ve outlined in this article. Both of them combined should put significant effort into protecting the pipeline from internal and external threats, making sure they work with the actual source materials, providing mechanisms to detect tampering, and working with verified dependencies. The fact that on-premise tools completely alleviate those risks for the second platform makes them a much safer choice for application protection.

Having on-premise tools for application protection is our recommended solution for the reasons set out above. However, that isn’t to say that having all the tools in the same environment is a catch all. 

The best strategy to work with a highly-valuable application is embracing a holistic approach to mobile security. That means secure development and building infrastructure, secure SDLC, vulnerability management, and keeping all the valuable assets far away from potential attackers and third party services if they’re not robustly protected.