If you’re in the mobile dev and/or application security space, you know what we know. You know that securing and protecting the mobile app, channel and use is critically important. You also know that security is not as important as getting the app out the door. Getting that Android or iOS app out the door is and forever will be the first, #1 priority. Securing the mobile app… well…in the best case, securing the mobile app will come in as a very close second. I say best case because too often, it’s not second, let alone a close second.
Mobile App Security in the SDLC
Where exactly does protecting a mobile app fall in the priority scheme of releasing an Android or iOS app? Well, “it depends.” If you ask yourself “why does it depend?”, the answer shouldn’t surprise you. On the one hand, it makes no sense that mobile developers would go to all the trouble, work, and effort to create awesome and amazing Android and iOS apps and yet, fail or forget to protect those same apps from hacking, reversing, malicious actions or uses. On the other hand, the average mobile developer releases Android and iOS apps 12x a year. So, as soon as the first app is published to the app store, the developers are off working on the next release. In fact, they never “stopped” because app projects are usually coded in parallel. Meeting the demands of consumer users of these mobile apps never abates. Developers quickly learn that to get, keep and increase use of each mobile app requires constant development.
So how do developer and security teams overcome this challenge? Imagine for a moment two friends are spinning a jump rope, or two jump ropes, and you have to jump in the middle, keep the ropes moving, all without stepping on the ropes or tripping. It’s not easy. It’s also not easy to bring security features into the release cycle of a mobile app. Why? Because building security features takes time. Security features are hard to build and maintain. Imagine you’re not the jumper in this example, but the two friends turning the rope. Every time security features are introduced to the mobile app SDLC, the person building the security steps on the ropes. Ouch.
Oversimplified Model of DevSecOps
DevSecOps was introduced as an attempt to resolve this conflict and overcome the challenge of integrating security into the mobile SDLC. DevSecOps says, that organizations can accomplish both priorities simultaneously, release mobile app features and mobile app protection in the same release. To date, much of the emphasis in DevSecOps has been focused on the processes development, security and operations teams use to build, protect and release apps. A ton of great work on creating cultures of security, secure coding practices, etc. have all emerged. This has all been for the better, improving the possibility of more secure mobile apps for everyone.
To illustrate the challenge of DevSecOps, lets go back to my example above – two friends spinning jumping ropes. We’ll call one friend your dev-engineering team. We’ll call the other friend your ops-release team. One rope is your android app, the other rope is your iOS app. The Android and iOS apps are released at whatever cadence your business releases apps. In some organizations, the ropes spin exceedingly fast. In some they spin at a more rational rate, say for example releasing Android and iOS apps about 12 per year. Siting on the outside of these ropes, you are the security team. Your job is to only allow the ropes to spin if certain security objectives are met, and jump at the rate of app releases, getting into the game without stopping the ropes.
The challenge is that dev and ops aren’t security and security isn’t dev or ops. Each has very different objectives, disciplines and resourcing. Developers aren’t typically security engineers. Security teams don’t typically have engineers. Neither group is resourced or trained to meet the needs of the other. Each time they try, someone steps on the rope.
DevSecOps, Meet Continuous Security Certification
Appdome introduced the first of its kind continuous security certification, called Certified Secure™, to provide fully integrated, automated, validation that the required security features are built inside each app. Continuous security certification offers mobile developers a critical upgrade in keeping secured Android and iOS app releases on track and on schedule. Done right, continuous security certification meets the needs of all groups – dev, ops and security – to provide the needed protections inside mobile apps and clear releases fast and on-time.
Certified Secure™ differs from app scanning and vulnerability assessment tools. Code scanning occurs after the app is built and provides no resolution or remediation for any vulnerabilities found in the scan. With app scans, remediation and resolution is left to the dev team. So, any findings revealed by a code scan put the release at risk. On the other hand, Certified Secure provides validation that the security and fraud prevention features required in Android and iOS apps are built into the app, build-by-build, so release teams can clear apps quickly. Each Certified Secure certificate also allows 100% visibility into each app, security features, team, templates and more in use inside each app. With Certified Secure, handoffs between groups are simple and easy to validate, so each stage of the release process can be audited and verified. Never before has it been so easy to achieve your DevSecOps goals.
I hope you give Appdome Certified Secure™ a try in your dev-process. To learn more, request a demo of Certified Secure™.
We’d love to help you secure your Android and iOS app, the DevSecOps way!
