The recent industry shift towards DevOps makes it clear that organizations are adopting this development and operational model to facilitate the practice of automating software delivery and deployment. As a result, organizations are acknowledging that their traditional approaches to software security are having a difficult time adapting to this new model, since security is often viewed as an inhibitor to DevOps. In this blog, I’ll delve into two aspects that should help ensure the absolute best approach to embedding security into your DevOps initiatives. To learn more about several other aspects of embedding security in DevOps, please download our eBook here. When discussing security within DevOps, let’s first define what security is. In the world of software development, test, and operations, security can mean many different things. From defining security policies, automating security testing, and identifying vulnerabilities, to correlating results, remediating vulnerabilities, and finally, management and monitoring of security programs and developer’ KPIs, there are many stages of security in an organization. When discussing embedding security into DevOps, there are several activities that are directly related to the Application Security Testing (AST) solutions in use throughout your SDLC. For example, two key aspects of DevOps involves correlation of test results and remediation of discovered vulnerabilities. When both of these activities are being performed in the most automated and integrated fashion as possible, organizations can gain additional value from their AST solutions. Let’s explore the following topics in more detail.

Correlation of Test Results

The idea behind correlation is to increase the level of confidence and priority of the high-risk findings (vulnerabilities detected) as a result of the AST scans being performed—especially when you’re able to correlate the same findings from different scanning solutions. For example, if there was a SQL injection vulnerability discovered by SAST during static testing, and IAST confirms the same finding during interactive testing, if you can correlate both of those findings together from a single Software Security Platform, you can trust that the finding is highly likely to be a true positive. In this case, the likelihood of a finding being reproducible is extremely high. When this is so, the vulnerability needs to be fixed sooner, rather than later. When organizations have hundreds of applications, and their AST solutions are detecting thousands of potential vulnerabilities, the ability to scale starts here—when organizations are able to makes sense of the large amounts of data from their scan findings. Today, few organizations are doing manual correlation. Either they have tools to correlate, or simply put, they are not correlating their test results.

Remediation of Discovered Vulnerabilities

Remediation has two aspects. One is what should be fixed, and the other is how to fix it. When referring to what should be fixed, in the context of scale, no developer can handle thousands of vulnerability findings. You need to make sure that you have the ability to prioritize all those findings in a way that a developer can digest them. Developers need to be able to focus on what’s most important, and to work on fixing the vulnerabilities that would exponentially reduce the most risk. Having the ability to set an automated prioritization mechanism across the thousands of findings is of the upmost importance. Using a set of criteria, organizations can define what’s more important and what’s less important. For example, a newly discovered open source vulnerability may be more important than a vulnerability in custom code. Fixing a vulnerability that has been in place for more than 60 days may be more important than something newly discovered. There are lots of criteria that will enable you to control how the findings are eventually prioritized. When that is done in an automated manner, you can scale, and each developer receives their segment of code that they need to fix in an automated fashion. If an automated prioritization mechanism is also in place as part of your AST solutions, it should include machine learning algorithms that are designed to focus your developers and/or AppSec team’s attention on what are the true positives. Today’s machine learning algorithms have the ability of setting percentage weights to various findings. For example, machine learning algorithms can be taught to understand that one type of vulnerability has an extremely high percentage of being a true positive, while at the same time learning that another type of vulnerability has a very low percentage of being a true positive. This can tremendously improve confidence of a true positive vs. a false positive. This is where automation can be increasingly helpful. Once a team decides what needs to be remediated, often based on the agreed upon software security policy, the next decision is how to remediate the vulnerabilities. Here is where Secure Coding Education (SCE) like Checkmarx Codebashing can be of great assistance. Codebashing teaches developers how to fix a certain vulnerability with a customized lesson that is specific to that type of vulnerability, especially since Codebashing can be integrated directly into developers’ IDEs. If organizations are correlating their findings from the different AST solutions deployed, and remediating their vulnerabilities by way of delivering results to developers and AppSec teams in the most streamlined fashion as possible, allows organizations to reduce their security risks at scale. Therefore, look for a platform that can aggregate scan results from the different AST solutions you have deployed, and also automates the findings prioritization through the use of machine learning algorithms, correlations, policy tuning, and custom weights. To learn more about several other aspects of embedding security in DevOps, please download our eBook here.