Left-shifting enterprise appsec: what we can learn from mobile app developers

The many benefits offered individually by containers, the cloud, microservices-based architectures, and devops increase by orders of magnitude when they are used together.  Cloud-native application development, the model that delivers these exponential gains, also introduces a once-in-an-era opportunity to achieve a dramatic improvement in application security – one that puts an end to the endless (and futile) chase after threats and vulnerabilities, while struggling with an ever-increasing information security skill shortage. The key to this improvement is “left shifting” security

With Gartner predicting that by 2020 more than 50% of global enterprises will be running cloud-native, containerized applications in production, devops and devsecops teams need to act quickly if they are to integrate and automate security into cloud native build processes as they are being implemented.  While cloud native enterprise apps operate at a much larger scale and are way complex than mobile apps, the mobile app development world has to a certain degree, already left shifted security.  It’s worth a closer look to see what can be applied in enterprise settings. 

Containers and mobile apps have similar attributes

Mobile apps and containers share some key attributes: millions of mobile apps sit on billions of devices – the same can be said of containers (at least as adoption increases). They both are immutable by nature, frequently updated, and are consumed based on a self-service model.  In the mobile app dev world, the cultural momentum for left shifting security was set by Apple, which required iOS app developers to validate the security and integrity of their code prior to allowing the app onto the app store.

The way mobile apps are delivered today – at least via the Apple Store, is that the developer goes through a security check list, checking the capabilities they require (e.g. accessing the camera, accessing location services).  Next, they’ll send it to (for the sake of this example) the Apple app store.

Apple has automated scans that look for vulnerabilities, malware, and also examine iOS app behavior against the capabilities it claims to need. Once security checklist items are tested and and verified, they approve it and it’s on the store. Additionally, on the phone itself, the apps are also monitored with data sent back to Apple (if the user agreed to share – which most people do, it’s the default in their EULA, the one that people rarely read before they click to ‘agree’ to all the terms of use).

There are two critical elements to the success of this model: The requirement from the developer to declare their app’s security needs, and the automation of tests that run before the application ever touches an end-user. Both implement the principle of least privilege – if a developer tries to arbitrarily ask for unneeded privileges, the sandbox testing will reveal that, and the application will be rejected.

Enterprise applications are not like mobile apps, the attentive reader will no doubt point out at this stage. They are much bigger, more complex beasts, developed by many developers and not so easy to reduce to a checklist of privileges. And those readers would be right – but this is where microservices architectures completely change the game.

Microservices pave the way for appsec innovation

Microservices they break up enterprise applications into small, simple, and predictable components. In microservices architectures, each microservice IS like a mobile app in that you have the ability to make changes to one small piece of functionality without having to take the full app out of commission (which is the case with monolithic apps). 

While scale and complexity differences make comparing cloud native to mobile app dev an apples-to-oranges comparison, at the end of the day, their security goals are the same – to left shift the declarative security parameters so that security  gets implemented by developers, who, wherever possible, automate testing, and enforce what is essentially a strict and supervised regime of least privileges and least capabilities. All this happens well before the application hits production.

There is no shortage of security resources available to IoS and mobile developers. From detailed guides from Apple to OWASP to extremely useful tips and best practices from a variety vendors, and vendors within the devops and devsecops community have taken the initiative to create detailed knowledge stores (as an example, my company, Aqua Security, curates and hosts a vendor neutral container wiki).

With a chronic shortage in skilled security staff, this model is not just better in terms of security, it’s significantly more efficient than having developers (who vastly outnumber security staff) throw their code over the proverbial fence and let security handle whatever may come once the application is running.

By the time business leaders got the memo that cyber security need to be a business imperative, there was only so much that could be done to bolt security onto large, monolithic applications.  Thankfully, the rise of cloud-native app dev changes all that, but…there’s a limited window of opportunity to left shift enterprise application security.  If we don’t do it as next-gen development processes are being built and automated, we risk a repeat of “AppSec 1.0.” 

So, let’s do it. The mobile world made significant strides in left shifting security.  It’s time for the enterprise world to follow suit – it might be awhile before we get another chance.