DEVOPSdigest

Shift-left has been an important DevOps concept in recent years, and shift-left security is rapidly becoming the next big "shift" for DevOps/Agile development. In this model, app developers build app security, fraud prevention and anti-malware features into software as early as possible in the development cycle, instead of trying to code security in after an app is built.

In a DevOps environment, shift-left security means that protections that would have previously been implemented after code was "final" will take place alongside development during sprints, often starting even before coding takes place during the planning and requirements phase. The advantage that vulnerabilities are caught early, when they are faster and cheaper to fix, and security features are built alongside the rest of the app, which makes integration much more seamless. Building security into an app after the fact increases complexity.

No one should doubt the need to integrate security earlier into the development cycle, especially when it comes to mobile applications, as they are notoriously insecure. Even mobile banking apps have serious vulnerabilities. A white hat hacker who examined 30 apps from a variety of large global financial institutions found that 29 of the 30 mobile apps that she reverse engineered contained hardcoded API keys and tokens. Tokens include usernames and passwords to third-party services, which could enable a hacker to take over accounts, steal funds, and even access back-end servers to launch even more devastating attacks. Transportation, travel, healthcare and mobile health apps are often even less secure.

The Problem Isn't Laziness

It's not that mobile app developers are lazy. The problem is a fundamental mismatch between the objectives of the developer and security teams. Developers are tightly focused on improving specific KPIs for the mobile apps they develop: the number of screens per visit, the number of active users, ARPU (average revenue per user), crash rates and COCA (completeness, operability, correctness, and appearance), to name a few. To accomplish these goals, developers must deliver a finished app within a tight timeframe, which is critical to successfully compete in a crowded market, so they only have time to focus on features.

Security teams, on the other hand, are focused on protecting the app from attack. They are constantly working to improve the security of the mobile app. The work is complex and specialized, especially in the mobile world where iOS and Android each require a different set of security skills. Development teams use many different frameworks to build apps. This can be a problem if a team is depending on software development kits (SDKs) to implement security and other features, because the SDK may support all the frameworks, libraries and non-native code, plus all the myriad dependencies that must be accounted for. It's also labor intensive, which can significantly slow down delivery and increase costs.

Unlike DevOps, where as much as possible of the work is automated, security is still largely a manual process. Without automation, it's extremely difficult to shift left. Developers are constantly checking in code, right up until the last minute, which makes security alignment extremely difficult.

The Mostly Manual Security Mess

The way the process works right now creates a great deal of tension between developer and security teams. Here's how: The development team sends a release candidate to a third-party for penetration testing (pen testing) or they use a scanning tool to find vulnerabilities. Once vulnerabilities are identified, the security team works to address them. Because security wasn't incorporated from the beginning, there's no way to know how long it will take to fix any errors found. And as noted earlier, often the process of implementing security is manual, which may make it impossible to both meet the release deadline and deliver a secure product.

Organizations should seek out tools that enable them to use developer best practices to incorporate security features into an app, ideally so that teams can build security into apps without disrupting way they already build them today. When teams shift-left security in an automated way that doesn't conflict with existing processes, development and security teams can work together release secure mobile apps in a DevOps environment.

No-code platforms now exist that can build security into a mobile binary, with developers simply needing to include calls for the specific security protections required. Then, when the code is compiled into a binary, security will be implemented in a consistent manner. This doesn't mean that pen testing isn't required. DevOps teams still put software through QA, after all, no matter how automated their processes may be. But when teams shift-left security through automation, the consistent implementation of protections vastly reduces the number of vulnerabilities that need to be fixed. As a result, developers are able to deliver a full-featured release on time, and the security team can rest easy knowing that the app is secure.