In a previous blog, we had discussed how we were able to build an event-driven AppSec Service for one of our major financial clients and the related challenges and details on the design and implementation of such a solution. This blog primarily focuses on the outcome of building such a service and how this impacted the overall implementation of DevSecOps within the organization. To really understand the impact, we will compare side by side, how things were working before and how they improved after we had a solution in place.
Before building the AppSec Service
The overall flow for detecting vulnerabilities and running AppSec Scans before building a dedicated service was as follows:
- App Teams had no specified schedule on running the AppSec Scans. Scans were run on an “as-needed” basis, and it was not uncommon to run the scans after the production release.
- Some of the technologies were not being scanned due to a lack of knowledge. In addition to this, some of the scans when done manually were also done incorrectly.
- Once the vulnerabilities were detected, tickets got created in Jira for the App Teams to address them.
- Since the overall process of detecting vulnerabilities was not streamlined, App Teams were under constant pressure to fix the vulnerabilities in addition to working on their already existing app-specific laundry list of features, improvements, and bug fixes. AppSec team on the other hand was under pressure too, owing to make constant follow-ups, guiding and sending reminders to a large number of App Teams to fix their vulnerabilities in time!
After building the AppSec Service
As seen in the previous section, things were very much chaotic before building a dedicated AppSec service. Let us now see how the situation changed once the AppSec Service was put in place:
- To begin with, the AppSec Service was integrated with the GitLab pipeline itself. This meant that the security scans would be initiated whenever the pipeline runs – this can happen during pre-release, for example, while committing to a branch, creating pull requests, merging the code, etc. The integration with the GitLab pipeline was asynchronous – meaning once initiated, the AppSec Service would be running parallel while the other stages of the pipeline to continue running without getting impacted in any way.
- Since the process of initiating scans was now automated by the service, it was now possible to integrate the technologies that weren’t scanned previously into the service.
- Automation also enabled improving the quality of the security scans.
- The overall setup of integrating the AppSec Service within an App Team’s GitLab pipeline was seamless and one-time with minimal user input.
- The AppSec Service also included a customized dashboard that enabled the App Teams to check the status of their scans as well as get a high-level summary of the vulnerabilities detected during the scan. This also serves as the means to indicate how “secure” their App is, based on the standardized metrics.
- Since the security scans get initiated early in the release cycle, this gives the App Teams ample time to fix the detected vulnerabilities as a part of their development process itself, thus making application security a part of the solution.
- Once the App Teams fix the vulnerabilities in the development phase itself, the chances of any vulnerabilities going to production are reduced significantly.
- AppSec team is also relieved of constant follow-ups since the overall process of automation empowers the developers to fix any security issues in their Apps way much earlier in the SDLC process. Hence the term “Shift Left”!
Implementing DevSecOps best practices can be a daunting task but following an iterative approach based on end-user and stakeholder feedback can be the best approach. It is possible to design app sec automation optimized for developer productivity by providing feedback as early as possible. Addteq can be your trusted partner for adopting DevSecOps in your organization by enabling you to follow the framework that we described above.