Automating the Application Security Process

In this article, I have shared my experience with automating the manual security process that we follow periodically for our products during every half-year release and how this eventually helped us save cost and effort. This automation initiative also proved to be very efficient and aligned well with our organization's goal of automating some key steps/processes in the overall product development life cycle (PDLC).  

Application Security Framework

The Application Security process has a set of security activities that are followed during the product development lifecycle. I call it the "Application Security Framework" that is used on products during PDLC. The Application Security Framework has different phases, with activities under each phase as shown below: 

(NOTE: Since the goal of this article is not about covering the details of this framework, I have only briefed about the activities in short summary below in order to connect things. Watch out for a dedicated article about this framework that I will be putting up later.)

Training

We formally begin the security process by conducting an organization level application security training across the teams (including business, Dev, QA, and support).   

Requirements

A dedicated security team actually begins the security process from the requirement phase. Every time we receive business requirements from the business analysts, we scrutinize the requirements from a security perspective and share our review comments or raise security bugs in JIRA.

Design

We have adjusted our development process so that every design document is shared with the security team too - for their reviews and comments. The security team reviews and checks the design document against the baselined/approved thread modeling report to make sure there is no deviation present.

Coding/Implementation

In addition to scanning the code using SAST tools, it also gets reviewed from the security perspective as a part of the code review process. 

Testing/Verification

When the product is released to QA for testing, the security team begins manually testing the product in parallel. It also uses DAST tools to test the product in its own security environment. All the security bugs are raised in JIRA with severity levels that were initially agreed upon with the management and DEV teams.

Release

When it comes to the product release date, the security team reviews the outstanding bugs along with the product team and then decides to sign-off on the release from a security perspective.   

Manual Activities and Challenges

Out of the above processes, the most time-consuming ones are code scanning during the coding phase and security testing during the testing phase.  

The time taken to scan the code is directly proportional to the size of the product and the language in which it is written. Products that are written in a legacy language usually have a larger number of lines. We are not exceptional; our program units run into a few million lines of code. A few hundred lines are added almost every day during the coding phase. So it is important that we don't wait to scan all the program units until the end of product release cycle. This scanning exercise occurs once or twice every week.

Similarly, conducting the security tests towards the end of the release poses a risk as any critical findings towards the end could impact both the product delivery and the release timelines.

Another challenge is resource retention and team motivation. We didn't want to hire skilled people to work on boring and repetitious scanning and testing tasks. Being a product company specializing in niche domain, we would rather utilize our resources more effectively to work on automation activities.  

Automation as Part of DevOps

Static Code Analyser

The security code scanning process that is automated using Jenkins is depicted in the diagram below: 

The Jenkins server acts as a central triggering process that initiates the weekly scanning process. It first checks-out the latest committed source files from SVN and copies them into the scanner server. It then triggers the script that is already written and placed in the scanner server. This script is the one that scans the source code. Since this script is dependant on the vendor specific libraries (in our case: HP Fortify), it is advisable to place this script inside the server itself.

The security team verifies the scan status and results, checks false positives, and then shares the results with the dev team.

Dynamic Application Security Testing

Similar to the above, testing to check the runtime behavior of the web application has been automated using scripts. A diagram of the automation process has been depicted below:

We set up a dedicated security environment for DAST to run as it consumes a lot of power for processing. 

Functional Security Testing

There are some vulnerabilities in the application that are not technical. They are purely functional and could impact the regulations and country specific policies configured in the application. For example, scenarios like a negative value given to the "quantity field" on the screen along with a few other combinations of values can adversely affect the NAV price calculation of a mutual fund and needs to be tested. Since these are functional in nature, they have to be tested manually by logging into the application. But for a product with thousands of screens (like ours), it is a daunting task to test such things for every half-year release. You need to deploy a team of security testing experts to repeatedly test same the screens over and over again.

Instead of doing that, we decided to automate this process by recording different functional scenarios (like the one mentioned above) using open scripts. These scripts are then triggered from Jenkins periodically to check for functional vulnerabilities. The results are captured in DB tables. The result is later extracted and the report is prepared by the security team and sent to the dev teams. 

As seen above, all three types of testings are triggered by Jenkins, which acts as a controller in the overall DevOps activities at the organization level.  

End-to-End Automation

The earlier process of code scanning and manual testing used to occupy our security people almost full time for about 3 to 4 weeks every month. After automating code scanning, dynamic testing, and manual testing, we quickly saw huge savings in effort and time. Also, another advantage now is that developers who commit the code change in the source repository get faster feedback twice a week about the vulnerabilities in their code as Jenkins has been configured to trigger the scanning process that way. This helps them fix the code immediately rather than waiting until the end of the product release. 

The automation of manual and functional testing proved to be very efficient and gives consistent and reliable results in addition to saving on cost. Now, the security team focuses on designing and developing scripts of the new functionalities rather than working on the same scanning and testing activities over and over again for every release. 

Try this in your organization and let me know how it works!