Static Analysis

SAST Checklist for .NET and Agile Teams

For the last few years, the security industry has been wrestling with Agile development vis-a-vis security – specifically how Agile development can be used to help developers push more secure code, faster. More and more companies that we speak with have at least one team that is using Agile methodologies in-house. With these teams continually pushing code, it’s clear now more than ever that there’s a need for Static Application Security Testing (SAST) solutions that can continually scan applications and keep them secure.

During this same time, we have also been working on building .NET support into Sentinel Source, thanks to the extra-ordinary skill and perseverance of Eric Sheridan, Harry Papaxenopoulos, Michael Right, the entire SAST team, the exceptional rulepack researchers, and many others who know who they are! Personally, .NET and I go back quite a while. I co-authored one of the first C# database programming books to hit the market back in 2001, and I’ve been working with the platform ever since.

Support for the .NET framework in Sentinel Source is now going “GA”. While support for the .NET platform is not by itself necessarily earth-shattering news worthy of a blog post, thinking about these two topics has brought to mind what I think are several important points that developers should consider when looking at a static code analysis solution, particularly if they are working on an Agile project.

Specifically, I think it’s important for development and security teams to consider whether or not the SAST tool you’re considering meets the following criteria:

1. Does it work with the same source code you do and understand that source code? This helps you quickly fix vulnerabilities by suggesting actionable remediation. For .NET, that meant in addition to supporting ASP.NET Web Forms, ASP.NET MVC, etc., we needed to develop the ability to follow C# language semantics such as object indices, class properties, dynamic types, delegates, event handlers and lambda expressions. This level of affinity for the source code is not something that is very common, but it can be essential to quickly identifying vulnerabilities in C# code.

2. Does it integrate with your workflow? Does it get the source directly from source code repositories (Team Foundation Server, Subversion, GIT, etc.) out of the box? Conversely, does it make you build and upload, fire up a slow desktop tool and go through the painstaking process of working through a buggy thick client?

3. Does it find vulnerabilities in the source early in the process and can you perform scans at your convenience? If you’re trying to deliver code continuously or even quickly, you need a tool that performs scans quickly and continuously. If developers are notified as soon as possible that a security issue has been identified, less time and money is spent refactoring code. Being able to scan code at any stage in the development process, not just compiled applications, is a necessity for any Agile team.

4. Does it introduce false positives? If you’re trying to reduce wasted effort and time spent refactoring code, then you need to know how often your SAST solution will be introducing its own errors into the process. The only way I know of to reliably eliminate false positives is via a model such as the one adopted by WhiteHat with our Threat Research Center, where the source is scanned locally in your environment and snippets of code are sent out for verification (similar to they way consultants include snippets of code in their reports).

5. Is there something else about your SAST solution that will scare your boss? There are lots of gotchas out there. Some solutions send your company’s intellectual property offsite (compiled or not) to be scanned. Some solutions have hidden fees, limited users or limited use of reports.

Our latest Website Security and Statistics Report showed that shows that in two-thirds of organizations surveyed, developers are in some way considered a responsible party when it comes to website/application security, but they don’t have much control over fixing vulnerabilities. Our survey found that which vulnerabilities developers fix is often dictated by their managers or delayed by a pre-determined release schedule. Hopefully, the right tools for fixing applications early and often, coupled with Agile methods, will lead to more secure applications and more developers that are able to take control of the security of their own applications.