Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
In the mobile app development world, security often takes a backseat to developing features and delivering the app. In fact, the 2021 Verizon Mobile Security Index found that 45% of organizations sacrificed mobile security in order to “get the job done.”
It really shouldn’t come as a surprise. Certainly, it seems counterintuitive that mobile app development organizations would spend so much time and money to create an exceptional Android or iOS app and then fail to protect it against rooting, jailbreaking, reversing, hacking and other kinds of malicious manipulation. But the average mobile developer releases 12 apps each year; a frenetic pace that requires development to take place in parallel, without ceasing. Schedules and budgets are tight, and competition is fierce. Coding security into an app is both expensive and time-consuming, increasing the risk of a delayed release or budget overages.
In many organizations, if security is implemented into a mobile app at all, the process takes place during penetration testing. That’s too late, and it’s extremely inefficient. Waiting to implement security after development and delivery are essentially finished will anger developers because now, they have to dive back into their code to make complex changes to work they thought was finished. The code is no longer fresh, so it’s going to take more time than it would have if security implementation had taken place during the development process itself.
But integrating security into the development process is no simple task either. Imagine two friends are spinning a couple of jump ropes. Jumping in the middle without stepping or tripping on either of the ropes while they are moving is difficult. Each time a security feature is introduced into a mobile app’s software development life cycle (SDLC), the person building the security could step on the rope. Building security features takes time, and they are hard to build and maintain.
Our Oversimplified Model of DevSecOps
To solve this problem, DevSecOps was introduced to resolve this conflict and overcome the challenge of integrating security into the mobile SDLC. The idea is that organizations can develop features and incorporate security simultaneously. So far, much of the emphasis in DevSecOps has been focused on the processes development, security and operations that teams use to build, protect and release apps. People have done heroic work creating cultures of security and secure coding practices, which has moved the industry forward toward more secure mobile apps for everyone.
Let’s take the jump rope analogy a bit further. One friend holding the ropes is the development and engineering team, while the other is the ops/release team. The ropes each represent an iOS and an Android app. In most organizations, the ropes are moving at blazing speeds, as apps are churned out one after the other. Meanwhile, on the sidelines, there’s the security team, whose job is to make sure the ropes meet security objectives, jumping in where needed, all without stopping the ropes from spinning.
The trouble is that each group has different skills and objectives. Developers aren’t typically security engineers, and security teams don’t typically have developers. Neither group has the resources or skills to meet the needs of the other, and whenever they try, one of them trips on the rope.
Mobile DevSecOps, Meet Continuous Security
The only way to keep the current breakneck pace of app releases going while simultaneously providing security is to introduce as much automation as possible. AI systems can fuse security to an app more cost-effectively and consistently, complete with validation that the features required have been implemented. It’s different from code scanning, which occurs after the app is built and leaves remediation to the dev team. I’m proposing that the implementation of security itself be automated.
The growing threats to mobile apps are too significant for development teams to ignore, but so are the market pressures that force such short delivery timescales. The only way out of this dilemma is extensive automation. Otherwise, the dev and sec teams will keep continuously tripping on each other’s ropes.
