CyberSec Tales

So you have a SAST tool to review the security of the source code of the applications developed in your company. You have everything ready, and you are already performing SAST scans, the only problem is… it will take years to resolve those hundreds if not thousands of issues reported by the tool. Right? Well, not if you follow the right strategies. Let’s talk about it.

SAST or Static Application Security Testing are fantastic tools that help us identify vulnerabilities in source code. They are very useful, but still some people hate them.

This tools help you to scale so you don’t need to manually review by yourself those thousands of programs that can contain tens, hundreds, and sometimes thousands of lines of code. Yes, I have seen it. A SAST tool can do it for you automatically and way faster, but it comes with a cost. 

SAST tools are not perfect. They can’t identify all types of issues and still manage to report false positives all the time. But a good SAST tool is also gonna offer you features to tune the results you are gonna get. 

So you got your SAST tool ready, it is set and configured. Perhaps you also integrated it with your CICD pipeline in order to get your source code analyzed every time a build is created. Maybe you set up your source code repository to execute the static scans every time a change is committed to your testing or some other branch. But now the big question is how to resolve the hundreds or thousands of vulnerabilities reported by SAST in an efficient way and in a timely manner. I am pretty sure you don’t even have enough Software Developers for the task. If you do, tell me how to go to Mars, because here on Earth that’s not frequent at all. 

But don’t worry, let’s discuss strategies you can take to translate those massive reports into actionable results you don’t need years to resolve, and at the same time improve your secure coding standards and guidelines, those you are going to use later to train your developers on how to write secure software, your CISO is gonna love it :).

Think in Terms of Coding Practices instead of Vulnerabilities.

First of all, Think in terms of the security practices you are missing instead of thinking in terms of vulnerabilities. In other words, think in terms of solutions, not in terms of vulnerabilities. So, for example, if you have log injection issues, it means you are not analyzing any untrusted data being included in logs, and this issue is gonna be reported many times, but you need only one practice to resolve it. Another example, if you are using dynamic SQL queries in the wrong way, the tool may find hundreds of these vulnerabilities, but all you need is one solution. Thinking in this way you will be able to identify false positives as well. So thinking in terms of the solutions will give you a more manageable set of action items. 

Now let’s get hands-on with this approach. You might want to start by exporting the list of vulnerabilities into a spreadsheet or other resource that makes them easy to review as a group. Then, sort your list and order it by vulnerability. Then start analyzing the most critical issues one by one. Don’t worry, you are gonna find very quickly that many of those issues are exactly the same just in different places, and sometimes in the same place, I don’t know if I already talked about all those duplicated issues the tool will report, but as you define the solution for one vulnerability, you are gonna find the same solution applies to many of those other vulnerabilities, so you can exercise one of those skills you mastered since you were a student at a very young age, the old good copy-paste :). 

Now, as you analyze different instances of the same vulnerability you are gonna find different flavors, which are, different types of the same issue. And you may need to define different flavors of the solution as well, this is totally fine. 

You can use 2 columns, one for your standards and the other for your guidelines. The one for the standards will be more generic and from a requirement standpoint. The one for your guidelines will be more specific, from an implementation standpoint. And again, don’t worry, most of this work is just gonna be copy-paste, do it one time, and use it many times.

If you find false positives, and you will, mark them as such.

Keep in mind there’s no free lunch. The more vulnerabilities your tool is reporting the more time it could take you to create this consolidated list. In my experience, an experienced application  Security engineer may need a week to analyze and summarize a report with a couple of thousands of issues in this way, which is a big win as it will help you to better understand the vulnerabilities, the risk the application represents to the business, and will give you an actionable approach to resolve the real issues. 

Update the Secure Coding Standards and Guidelines.

Do you remember those 2 columns I recommended you to add to your spreadsheet? Well, the next step is to update your secure coding standards and secure coding guidelines with all those security patterns you identified, this is gonna help you to keep your standards and guidelines updated, useful, and actionable. At this point, this will be a simple copy-paste. 

Update the issue descriptions in your SAST tool.

Your SAST tool may have a feature you can use to update the information that is displayed when a vulnerability is reported, including the recommendations. And I am not talking about the vulnerability as in the list of thousands of vulnerabilities identified in your source code, I am talking about the rules and templates used by your SAST tool to generate the text that is displayed in the results. If your SAST tool offers you this feature, go ahead and update the information, you will need to do it only once and your Developers and your future self will appreciate it. This will also be a way to move your standards and guidelines to the place where you want them, which is closer to the developers. At this point, this step will also be a simple copy-paste.

Socialize your Secure Coding Standards and Guidelines.

The next steps will be to socialize your Secure Coding Standards and Guidelines. This can be done with a training session. Don’t rely solely on an email, remember emails can be very easy to ignore, and with the high quantity of emails we all receive every day, it may not sound as important or official, so you are gonna want to do more than that. Training and even a mandatory lunch and learn can have more impact.

Tune the rules on the SAST tool

As I mentioned before, there’s no free lunch. The more vulnerabilities your SAST tool reports, the more time it will take to review them. Some SAST tools have features you can use to tune the rules it uses to identify vulnerabilities, letting you disable rules, create your own, or modify them. If you decide to modify any rule, I will recommend creating a copy and making your changes in the copy, in this way, you can keep the original.

Finally…

Finally, keep in mind the following 2 points:

• First, it doesn’t matter how much you or your CISO like your documents, if your Software Developers don’t use them, then they are pointless.
• And second, remember all these materials you will be writing are for your Development teams to read, they are the people who introduced the vulnerabilities in the first place, but they are at the same time the people who are developing the software that offers those amazing features to the customers and makes money for the company, so be gentle with them :).