Vulnerability Management In Your GitFlow

As most organizations are trying to bake security into their SDLC and with the wide adoption of git-flow, security concerns are also taking shape accordingly.

While git-flow was originally designed to make branch management easier for development teams, it also offers tremendous opportunities to develop software in a secure manner.

As seen in the graph above, each merge point across branches is a wonderful spot to function as a security gateway before vulnerabilities are carried over between different branches.

As an example we can run SAST, SCA or IaC scans in a PR event just before the feature branch is merged to the develop branch to prevent vulnerabilities from advancing to the following branches. Needless to say, the earlier we discover vulnerabilities in the SDLC the less costly it is to fix them.

However, we need to find a way so that the actions we take on a vulnerability in one branch are also reflected on the other after the merge event so that we do not deal with the same vulnerabilities over and over again.

So in this blog post, we will explain;

1) How can we make sure that vulnerabilities marked as a false positive or won’t fix in the target branch are not populated as new vulnerabilities when the feature branch is scanned in a PR event?

The goal here is not to waste time on the same vulnerabilities already eliminated in the target branch and to focus on the new ones introduced to the source code in the feature branch.

2) How can we make sure that the vulnerabilities marked as a false positive or won’t fix in the feature branch are not populated as new vulnerabilities in the target branch after the merge event?

To address the first question, when a scan is triggered with a PR event, Kondukto first checks the vulnerabilities in the target branch and creates a baseline against which the vulnerabilities discovered in the feature branch are compared.

This way Kondukto can automatically pinpoint the new vulnerabilities that have been recently introduced to the source code in the feature branch and ignore the ones that are recurrent or marked as won’t fix or false positive previously in the target branch.

To visualize it better, in the example below it is easy to follow how Kondukto matches vulnerabilities between branches so that security teams can easily put a spotlight on brand new vulnerabilities created in the feature branch.

The approach we take for the second question is a little bit different. When a new vulnerability discovered in the feature branch is marked as a false positive (or won’t fix), Kondukto clones this vulnerability into the target branch and it stays there in a passive mode without having an impact on the total number of vulnerabilities.

This cloning job occurs for any action taken on the vulnerability such as changing its severity or CVSS score, assigning an issue on the issue tracker or adding a screenshot so that all of these actions are also carried over to the cloned vulnerability in the target branch.

As the vulnerability is marked as a false positive, the feature branch will most likely be merged to the develop branch without taking any action on the vulnerability.

In the next scan run on the target branch after the merge event, when the same FP vulnerability is discovered, it is transitioned from passive to active mode and is treated as a regular false positive (or won’t fix) which means that the action previously taken on the vulnerability back in the feature branch does not need to be taken again in the target branch.

What if the vulnerability discovered in the feature branch already exists in the target branch? As we mentioned before in this case the vulnerability is classified as recurrent automatically by Kondukto as soon as the scan is completed.

Subsequently, all actions taken on these recurrent vulnerabilities such as marking as false positive or won’t fix, adding a screenshot, changing its severity are automatically reflected on the original vulnerabilities in the target branch as well.

Even though we focused on the PR check examples in this blog post, the same logic can be applied in all scans that are run on/through Kondukto. The default branch of projects can be used as a baseline branch in all scans so that the actions taken on the vulnerabilities in one branch are also applied to the other.

Automated processes like these help us optimize the vulnerability management process and avoid spending time on the management of the same vulnerabilities popping up in different branches.

In our next blog, we will explain how we can automatically prevent security vulnerabilities from being carried over from the feature to target branches which has also been a common concern lately.