DevOps vs DevSecOps Differences

In our previous post, we have taken a look at the timing and frequency of different types of security scans in our SDLC. When security scans are successfully embedded in SDLC, there are still other processes to think about for a proper DevSecOps adoption.

Any solution that creates extra burden for software developers, security engineers or DevOps engineers is destined to encounter resistance and eventually to fail. In this post, we will cover two processes which could possibly get in the way of a successful DevSecOps transition if they are not designed well in the first place.

1) Issue criteria

In recent application security practices, it is no wonder issue opening process can be automated. Even though automation offers help in saving time, the question of which vulnerabilities should be sent out to the software developers for remediation still remains.

As we always say, speed (automation) is only good if you are going in the right direction. So how can we make sure we are going in the right direction while automating issue opening process ?

Severity categories or CVSS scores are just too broad to be relevant for all projects if not for all branches. As we do not have time to filter out all vulnerabilities manually to decide which ones to direct to software developers, we need a lighthouse that shows us the way.

The cornerstone of our approach is the project architecture. If we manually reviewed vulnerabilities and tried to decide accordingly, we would definitely heed characteristics of the project to understand if the vulnerability really poses a threat or not. Well, why not use threat modelling to automate this process?

If we know the ins and outs of a project then we also have an idea on the possible risk factors such as attach surfaces or vectors. If we know the risk factors associated with each vulnerability in a project, we can also filter the vulnerabilities that needs to be given priority in remediation.

Now that we have figured out how to treat vulnerabilities in different projects, we can move on and decide how to treat vulnerabilities discovered in different branches of a project ?

Results of two scans run on two different branches can be of a varying importance to your organization. Some organizations prefer giving a larger freedom to their software developers in development branches whereas they harden their policies as software reaches the testing and production branches. In cases like this, issue criteria also need to be redefined based on the branch the scan was run on.

For this purpose, we have redesigned our issue opening feature. We now offer increased flexibility while deciding on the vulnerabilities software developers really need to be bothered about.

As an example, if you have an internal project where information disclosure is not a risk factor, you can opt to assign issues to your developers only if the severity of vulnerability is high and STRIDE category is anything other than Information Disclosure. Going one step further, you can also introduce different rules for different branches depending on your branch strategy.

2) Security criteria

Security thresholds help automating the decision making process when trying to decide whether a project is secure by our standards or not.

Setting security thresholds based on numerical values is a far-sighted approach as it lacks understanding of the characteristics of the project.

Project architecture must be an integral part of decision making process when defining security thresholds. Let’s assume your SAST scanner discovered one critical vulnerability that can lead to elevation of privilege.

A human security engineer would not let the build process break for a vulnerability like this.

If we set a numerical threshold such as one critical vulnerability, then in this case we will say project does not meet the security criteria and automation will only be mis-guiding us and cause extra effort to understand why the build was broken.

Clearly, we need to handle each vulnerability by examining the risk factors associated with it before taking decisions in DevOps steps. That is why we now let our users enter conditional security thresholds for different branches and different scanner types used in different stages of the SDLC.

The risk perception of a SAST scan run on a development branch is not the same as a SAST scan run on a testing branch as the risk of a vulnerability making its way into the production increases as the project moves right between branches. This may mean zero tolerance to certain types of vulnerabilities in certain branches and a more relaxed approach in others.

Takeaway

Success of automation should not only be measured by the amount of time saved but also by the right decisions it allows us to take. Any automation approach that ignores project specific risks will be far from making our lives easier in the long run.