RedHat defines DevSecOps as an approach to culture, automation, and platform design that integrates security as a shared responsibility throughout the entire IT lifecycle. Unfortunately, Mobile DevSecOps today is more an aspiration to this definition than a reality.
Mobile DevSecOps 1.0
The Sec in Mobile DevSecOps today is mostly about code scanning and blocking releases. While Mobile DevOps uses CI/CD tools to automate the building of mobile apps and deploy these apps into production, security is mostly a manual step. In fact, most customers I meet with today describe their mobile DevSecOps workflows as follows:
Security teams today suggest and recommend that mobile apps are released with certain security features. They document these features as requirements and then ask the mobile app developers to add these requirements to the roadmap. The developers will consider these requirements when planning their next sprints. But since manually coding security to mobile apps is a time consuming and resource intensive process that requires a high degree of technical skill, most security requirements never make it in the planned releases.
The reality in mobile DevSecOps today is that security teams are fully dependent on the developers to implement the recommended security features. And as a result, during the release meeting, the security team can only ask the developers “Did you add the company-approved security features to the app”, “Can you prove that the approved security features are in the app”, “Can you guarantee that the app is secure”. I discussed this tension between DevOps and security in a previous blog.
In order to get the answers to these questions, the only tool that Security has, is a manual code scan (a.k.a. pen test or vulnerability scan). This effort takes time (read: delay the release) and inevitably will show vulnerabilities. The problem is that once the vulnerabilities are known, the security team will either send the release back to the development team to be fixed or will need to approve releasing an app to production with known vulnerabilities. Obviously, neither option is a good option.
Mobile DevSecOps 2.0
With Appdome’s Mobile DevSecOps workflow, organizations can rapidly deliver mobile security features in their mobile apps. And they can do this in the same consistent way that developers deliver product features to these apps, all without coding.
Appdome allows organizations to fully integrate Sec into their existing DevOps processes and workflows, without the need to make any changes to that workflow. As I discussed in my previous blog, this gives security a prominent seat at the app development table. Dev and Sec can use Appdome’s CI/CD integration to build the security features, defined by the Sec team, into the mobile apps, at any point in the release cycle. And during the release team meeting, all the above-mentioned questions can be easily answered with Appdome Certified Secure, a service which guarantees that the approved security features were added to the version of the app that is targeted for release.
In Mobile DevSecOps 2.0, the security team is in complete control over the security features that get added to any mobile app the organization builds. Using the Appdome REST APIs, the team can integrate Appdome into its CI/CD pipeline and thus follow developer best practices to the process of adding the security features to their apps. Certified Secure provides all the documentation needed to validate that the right secure features are added to the release. This completely replaces the need for any manual code scanning or pen testing. Appdome’s APIs also integrate with Fastlane (and other Dev tools) to streamline the release of secured apps to the public app stores.
Best Practices for Mobile DevSecOps
Here are the best practices Appdome customers follow when implementing Mobile DevSecOps 2.0.
- Take time to build the right security template to achieve your security outcome. In Appdome speak this is called: building a Fusion Set.
- Test and validate that this security outcome does indeed provide the protection you are looking for. This is the one step where you would still use a pen test.
- After validating that your Fusion Set indeed delivers your desired security outcome, freeze (lock) the Fusion Set. Only people with the right entitlements can unlock the Fusion Set. Best practice is to limit these entitlements to only members of the Sec team.
- Use Appdome Sec-Release to share your frozen Fusion Set with members of the Dev team.
- During the release meeting, Certified Secure will show which Fusion Set was used. Verify that the correct frozen security template was used and since you already validated that this template is secure, you now have a guarantee that the apps presented for release are indeed secure and can immediately be approved for release to the public app stores.
Get started with Mobile DevSecOps 2.0 today.
