How to make mobile app security testing automation a DevOps reality

Source:- nowsecure.com

Eighty-one percent of enterprises and 70 percent of small-to-medium businesses have adopted DevOps according to the RightScale 2016 State of the Cloud Report.¹ In comparison, only 29 percent of mobile apps, on average, undergo vulnerability testing according to the 2017 Study on Mobile IoT Application Security conducted by Ponemon Institute.² I think the gap between these two statistics can be reduced with some minor effort. The purpose of this article is to explain how to make mobile app security testing automation a DevOps reality by leveraging existing DevOps efforts to incorporate automated security testing with continuous integration (CI), continuous delivery (CD), and continuous deployment (CD) tools for mobile app development.

What is mobile app security testing automation?

Mobile app security testing automation is automating static and dynamic analysis of mobile apps prior to deployment. Security testing identifies vulnerabilities arising from an apps’ permissions, network connections, source code, and other aspects of the mobile attack surface. As part of a DevOps initiative, enterprises can easily add automated security tests to existing automated functional testing. Mobile app security test automation  performs automatic security assessments as part of existing continuous integration (CI), continuous delivery (CD), and continuous deployment (CD)  practices. By putting the “Sec” in “DevSecOps,”  security testing takes place earlier in the SDLC (when flaws are easier and less expensive to fix) and becomes another continuous part of the process.

Why should I automate mobile app security testing?

Traditionally, mobile app security testing has been a manual process. A typical, manual approach might consist of the following:

• Clicking through an app’s user interface (UI)
• Observing the app’s behavior across various aspects of the mobile attack surface as it’s poked and prodded, for example:
  • Connected to a network setup that mimics a man-in-the-middle (MITM) attack
  • Installed on a jail-broken or rooted device
• Collecting output generated by various testing tools to assess the security of an app from build to build

A security analyst performing a proper penetration test of a mobile app, using the proper tools, is still the best way to ensure comprehensive security coverage. However, penetration testing takes a significant amount of time. With the rapid increase in mobile app development velocity,  manually checking for every issue in every build becomes infeasible. As security teams try to keep up, manual testing begins to focus solely on added code or code that has changed, and ignores presumably unrelated functionality.

Many aspects of manual testing are repetitive tasks, which make them prime candidates for automation. These repeatable tests ensure that regression has not taken hold, or check for simple items, such as whether the developer disabled the debug flag on a production build. Repeatable tasks/checks should be automated as much as possible to increase productivity, and free humans up to apply their ingenuity on more in-depth penetration testing.

Benefits of mobile app security testing automation

Automation, when done right, gives you the opportunity to parallelize security testing along with your other testing procedures. Cloud services empower you to run all of your testing simultaneously and at scale. This approach makes security testing just another layer in the testing stack performed as frequently as unit, integration, compatibility, and performance testing. Leveraging a previously configured CI/CD setup, and integrating additional tools, allows you to institute security testing earlier in the SDLC, which reduces the cost per bug fix.

Mobile app security testing automation also leaves security analysts more time for exploratory testing that identifies bugs at a deeper level — bugs that might go unnoticed if an analyst spends their entire day performing  high-frequency repetitive testing. By integrating automated security testing into DevOps practices (i.e., DevSecOps), developers, QA staff and security teams enable a “set it and forget it” development and deployment model. In addition, many security test automation scripts can repurpose scripts that development and QA teams have already created for other forms of testing.

Overcoming mobile app security testing automation challenges

Occasionally, developers associate negative feelings with the security testing of their code. It’s important to help them understand that just like other automated tests, security testing automation results in higher quality code and the identification of defects earlier in the SDLC, when it’s easier and less expensive to address them.  Lastly, security adoption within development teams can sometimes still carry a negative association around “doing it because we have to” and unless presented in an approachable way, could slow the integration process down. Below are a few challenges you may need to address to make integrating automated mobile app security testing into your SDLC easier.

Coverage challenges

One hurdle organizations encounter as they attempt to automate mobile app security testing is coverage. Automating the analysis of source code is significantly easier than automating dynamic analysis. Static analysis tools with access to source code really only provide a nominal amount of coverage in terms of a security assessment. Dynamic analysis, combined with static analysis, provides much more thorough coverage, but automating it is significantly more complex.

Automated dynamic analysis requires automating user inputs into the UI, and ideally using a physical device rather than an emulator, to generate outputs that can be evaluated for security flaws. Although automating dynamic analysis is a heavier lift, existing test automation scripts that many enterprises have already created as part of their DevOps practices can be used. Security testing is simply another layer in the testing stack.

False positives and negatives

A static-analysis-only approach to mobile app security testing can result in a high rate of false positives. Having to wade through a high volume of erroneous findings desensitizes developers (i.e., leads to “alert fatigue”), causing them to ignore serious defects that then go unfixed, and might affect the security team’s credibility among developers.

Reporting challenges

The reporting provided by an automated solution needs to go beyond a binary “pass/fail” finding. Developers need to understand why something poses a security risk. To maximize efficiency, requirements for reporting should include proper descriptions, remediation techniques, and context/proof that the issue exists.

Who is responsible for mobile app security testing automation?

Typically, the security team should own tool implementation because they are the experts in the space, can provide the proper feedback on findings, and can manually verify findings where necessary. Writing security test automation scripts, however, can straddle multiple teams/positions. Other functional testing areas already leverage scripting that automates the manipulation of a mobile app’s UI, which is a crucial aspect of security testing. The parties responsible for that automation scripting can relatively easily include security testing using scripts they’ve already developed. Many times development or QA teams take responsibility for this testing automation, and security testing creates little to no additional overhead in terms of what they’re already using today for scripting (e.g., XCTest, XCode UI Automation, and Appium).

Ideally, security testing will occur as frequently as other automated UI testing. The mobile app security testing automation framework is simply another testing layer leveraging the same scripts. As other UI automation scripts are modified to account for and test new app functionality changes, security testing occurs concurrently without the need for any additional work.

Where does mobile app security testing automation sit in the DevOps toolchain?

To minimize the impact on the efficiency of developers’ existing workflows, but still provide information about security defects so that they can be fixed earlier in the SDLC, mobile app security test automation should be inserted at the build level. This might consist of taking a compiled build from the CI server (e.g., Jenkins) and passing it into the mobile app security testing framework. From there, issue-tracking software (e.g., JIRA) can consume security testing findings/results and insert remediation tasks into developers’ work queues.

Mobile app security testing automation in practice

The video below shows how easy it can be to integrate mobile app security automation into existing, automated build-and-deploy processes. In this example, mobile app code is merged via GitHub, built via Buddybuild, and assessed via NowSecure Lab Automated. Findings from the assessment also automatically populate a JIRA instance.

Summing up

Mobile app security testing automation is possible, and enterprises can get started using existing automation frameworks and scripts they’ve already implemented as part of their DevOps workflows. If it’s true that a majority of enterprises have adopted DevOps, but less than a third of mobile apps undergo vulnerability testing; I think that’s a major gap that needs addressing. I wrote this article to explain how you can integrate automated security assessments into your existing SDLC, and provide an example of automated mobile app security testing integrated with existing DevOps practices.