What is SAST/Code Scanning?
Published on: 2019-10-15
If you're new to security scans, you may be unsure about what a Static Application Security Test tool (also known as "code" or "white-box" scanning) does or how it works. Here is my attempt to explain what it is and dispel some myths about it.
How SAST scanners work
While there are a few SAST scanners that look for vulnerabilities in compiled code, the vast majority of scanners look for vulnerabilities by examining your source code and looking for known issues. These scanners usually look for issues by looking for known bad code rather than by attacking your site. This approach is more effective at finding issues that are only seen in source code, however these scanners can be confused by badly-written code, unusual frameworks, or overly "clever" code.
Unfortunately, SAST scanners are very language-dependent, which can be a challenge for companies that use a wide variety of languages (or you"re a vendor looking to provide code scanning functionality).
What you should expect scanners to find
What scanners are able to find will vary widely based on the language you use. For instance, in ASP.NET MVC (both Framework and Core), since authorization and CSRF tokens are managed via attributes, it is relatively easy to scan for these. On the other hand, since there is no equivalent in ASP.NET WebForms, scanning for these can be much harder. So, coming up with a comprehensive list of items that SAST scanners can effectively find is difficult. However, here is a quick list of things that should be reasonable to find in most language.
- (Some) SQL Injection vulnerabilities
- Hard-coded cryptography keys and passwords
- Weak cryptography algorithm usage
- Unsafe file path handling
(Again, this is not a comprehensive list of possible vulnerabilities, just a list of vulnerabilities that scanners seem to find most consistently.)
It is important to note that scanners that are meant to be a part of your build process or IDE are usually going to err on minimizing false positives, i.e. reducing "noise" by failing to report borderline or questionable issues. In my experience, minimizing false positives pretty much guarantees significantly increasing false negatives (i.e. missing valid security issues). It is ok scanning with these permissive scanners as long as you follow up with other types of assessments, such as DAST/Active scans and manual penetration tests. But, if you want the best results, it's best to invest in a scanner that will look at your entire solution and give results, not one that will give results real-time in Visual Studio (or whatever IDE you use).
Things to Watch For When Evaluating SAST Tools
Finally, I'd like to throw in a couple of observations I have about SAST scanners in case you're looking to purchase one:
First, unlike DAST and SCA scanners, which have low-cost scanners that work well, you generally have to pony up some serious cash if you want a good SAST scanner. There are free and open source scanners available, but quite frankly, these aren't very good.
Second, watch out for scanners that claim to do more than just vulnerability scans. I've tried scanners that will scan your source code for code "smells" along with security issues, and in my experience, these perform an unquestionably inferior job in finding security issues than dedicated security scanners. For security scanning, stick with dedicated security scanners to get the best results.
