Many businesses have already embraced DevOps methodology; development and operations teams work hand-in-hand to deliver quality and enable faster time to market. The other major advantage of DevOps is Continuous Integration and Continuous Development (CI/CD), wherein processes are more agile and deploy code more quickly. It further allows teams to have the latest update on the status of their development efforts and ensure they deliver value to customers. DevOps principles and practices ensure businesses continue to stay ahead of their competition by delivering new features faster than with any other software development methodology on the go.
The fundamental facet of DevOps revolves around CI/CD pipelines for software builds:
It ensures that development teams have effective feedback status from time to time on their development efforts and are well-aware when the build is ready to be pushed to production. This process of building CI/CD pipeline needs effective testing for quality, performance. By integrating security into CI/CD pipelines, the incoming security vulnerabilities could be found quickly and be easily reported to developers.
It is interesting to note that sometimes integrating application security into the CI/CD pipeline is challenging when a pipeline build fails due to unit tests or functional tests failing. In these situations, developers consult user stories or install other methods to overcome them. If developers lack a strong background in security code reviews, then any eventual security issues that drive in the mid-way during pipeline builds will cease and software testing cannot move further. There are certain application security tools like OWASP ZAP, which helps support the type of automation required for CI/CD integration.
Certain Challenges With Security Testing in the CI/CD Pipeline
There are certain security challenges in CI/CD workflows that might occur due to various reasons, such as with respect to tools selection, the approach followed for the process, speed variations, and occurrence of false positives. Also, at times, in certain situations, it might be due to developer resistance, or any intervening compliance issues, etc.
Lack of proper selection of security testing tools: It is interesting to note that every application security testing tool has a command-line interface that has to integrate with the CI/CD pipeline. While building a pipeline, there are defined checkpoints in the pipeline where these tools run. At times, if the security tool identifies certain critical issues, then the team should break the build and simultaneously update the defect tracking system and metrics dashboards.
There is a challenge involved, as every tool has its own dashboard and has a specific way of getting configured to break the build; it is important to select tools that can talk to a common dashboard. Otherwise, the coder has to explicitly write several plugins or custom code. Moreover, while writing custom code, developers should make sure to abstract as much as possible, such that if there are any further changes, there should be no implicit impact on the pipeline.
At times using different approaches: In the earlier days when virtual machines (VM) were used, there were several operating systems that were running on the same machine, and most application security tools were installed within the VM. Though the VMs took several minutes to bootstrap, they were immediately up and running, and thus there was no such problem. With the cloud and Container concepts making a shift, there are some issues for security tools not running properly.
Some of the reasons why these tools could not run effectively in Docker containers are variations in size, a small memory footprint, images are lightweight, etc. In order to overcome this hindrance, tools that seamlessly work in containers and easily deployed tools in the cloud should be identified and used.
Security testing acts as a hindrance for processes slow down: The security testing tools take some time to run the code base in order to identify vulnerabilities. Dynamic security tools and other tools like Service Component Architecture (SCA) tools take time to run through the entire code base, which takes different timelines. In order to overcome this problem, it is important to ensure that you configure tools properly and correctly use due diligence. It further depends on the usage of technology, language, and framework; the developer has to make sure the correct rules are configured and customized.
The predominance of False Positives: It is important to know that all tools suffer from these false positives and false negatives — more dangerous than the former. When a security tool is integrated into the CI/CD pipeline, it is important to have complete knowledge of application, language, and framework, such that false positives will not pose a major challenge. Before automating the tool into the pipeline, it is important to onboard the application, and at the same time, it is equally important to even understand the context of the application.
Developer acceptance or resistance issues: Basically not many developers are security experts, and therefore, it is necessary to remind them of the possibility of code vulnerability. Static application security testing is one of the many checks that can be followed to identify and mitigate security vulnerabilities in source code early in the software development lifecycle (SDLC) process.
Compliance issues: It is important to differentiate between the compliance rules that run in the application security tools inline within the pipeline and that are run out of the way or asynchronously, which are initiated by the pipeline. Ample care should be taken with respect to HIPAA and PCI compliance applications.
Last but not the least, it is important to note that application security tools selected should support the technologies that are being used in your organization and support the applications that are being built using the CI/CD pipeline. Proper knowledge about the security testing should be delivered to the developer, such that the build pipeline runs well and even a large organization fails the build if the security tests are not passed through. Hence, security testing, part of software testing, should be integrated within the SDLC and should be given the same importance as other business requirements.