The other day we talked about DAST and how useful it is to organizations and the fact that only 60% of organizations have any DAST solutions in place. We also talked about how DAST is generally the first piece that is implemented when working with application security. Now, let’s talk about the second piece: static application security testing, or SAST.
SAST is generally the second step in application security. As we mentioned before, DAST will allow you to point a tool to a website, web service, or web application and crawl out the site and scan for security vulnerabilities. This will uncover things such as sql injection, XSRF, and XSS, amongst many other vulnerabilities. So what exactly is SAST then? SAST lets you analyze static code that is not already out on a production web server. Basically, you feed the tool your raw source code, the SAST tool will run the code through a built in compiler, and it will then analyze the code for vulnerabilities.
One big advantage this gives you is that you can scan code that is not only for the web, you can also scan code from various programming languages; such as C#, Java, C++, C, PHP, Python, PHP, and many others. The HP Fortify solution can scan something like 22 different languages. Another advantage is that you can scan code earlier in the SDLC. I have a CSSLP study guide on my desk that quotes IBM as stating that software vulnerabilties are 300 times faster and easier to fix early in the SDLC than they are in the testing or production phase. This makes it really easy to see why static application testing is so important. It makes the changes easier and faster to make, thus saving the organization time and money.
There is a lot of overlap in what the tools are scanning, so if you already have DAST in place, you are not going to get 100% efficiency out of a DAST tool. It mostly enables you to catch the mistakes earlier. There are also some things that each tool catches that the other tool doesn’t. Think of it much like a compiled programming languages. When you test your application you could get compile-time or run-time errors. Some errors are caught by compiler and some can only be caught by running the application logic. DAST and SAST tools work much the same way, one is testing your actual source code and the other is running the application and finding errors by actually running it and simulating a user.
Based on the numbers from Gartner, at least half of organizations are running DAST but an overwhelmingly minority are running SAST. In my organization, we are not doing any sort of application security at all, which is where my job comes into place. The plan is to actually start by implementing both at the same time, scan all of our apps, and eventually get a process in place so that app scanning is a part of the SDLC and happens automatically. Some of the major players, such as HP’s Fortify, actually have IDE plugins where the developers can run static code analysis in their dev environment and get immediate feedback from the tool. As far as major players are concerned, it’s really the same as DAST: HP Fortify, IBM AppScan, and VeraCode.
I think this is all pretty cool stuff, but I still have a lot to learn. I’m hoping to have a solution purchased in the upcoming weeks. If you have any comments, thoughts, or suggestions, feel free to drop them below. I’d be interested in hearing what you have to say.
This image from Gartner should give you an idea of the major players, though it is old and the game has changed extensively. Ounce was picked up by IBM and Fortify is now part of HP.