Grumpy Security Guy

I’ve suffered the tortures of the damned

Grumpy Security Guy header image 2

Source Code Scanning is Dead

November 20th, 2007 ·

I sat through a demo of some source code scanning technology yesterday and about halfway through it hit me. Source code scanning is dead, but no one has realized it yet. Well maybe not dead, since dead would it imply it was alive one time, and that was never really proven to be the case.

Specifically I am talking about source code scanning for web applications, not your typical compiled desktop/server software. I readily admit I have not performed in depth reviews of every single offering out there but I have spoken to a number of people that review source for a living and I have gotten really good feedback and information from them. What are source code scanners good at finding?

1. SQL Injection
2. LDAP Injection
3. Bad habits (not sanitizing data)
4. Did I mention SQL Injection?
5. Overflows
6. Limited XSS

What do almost all modern frameworks prevent?

1. SQL Injection
2. LDAP Injection
3. Bad Habits
4. Did I mention SQL Injection
5. Overflows
6. Limited XSS (you could argue most)

First, I have to try REALLY hard to get a SQL Injection in my .NET app, my J2EE app, my Rails app or even my PHP app (if I use a decent PHP framework that is). Today’s frameworks are specifically designed to be resilient against the exact same things source code scanners are best at identifying. Given that J2EE and .NET have practically eliminated SQL Injection, XSS, and Buffer Overflows I have a hard time finding a value proposition in scanning source code of these applications in a stand-alone fashion.

What about the older web applications that are not written with these frameworks? I will save you the time and money and give you your report. You have loads of SQL Injection if you are using ASP classic and heaps of XSS. You can find these issues with any competent blackbox solution as well so why bother going to source. You can probably find more in source but you should no be fixing these issues one-by-one but solving the problem at the root. This will most likely mean, for ASP classic apps, moving to .NET which again unless you try really hard to make a vulnerable application SQLi and XSS are taken care of for you.

Let’s not forget that Web applications are written in all kinds of languages. For a source code scanner to scan source code, it must support the language. I have seen almost universal coverage of J2EE and .NET and some coverage of PHP, but Web applications are multi-language melting pots. Just scanning the source of the app only gives me limited coverage. Limited depends on the application of course but it is pretty rare these days to find an app that is only J2EE or PHP. You have JavaScript that is increasingly performing substantial pieces of functionality. The use of Flash and whatever Flash look alike MS comes up with will further obscure these boundaries. If you are not assessing the application in its entirety your value diminishes even further.

I predict source code scanning will go the way of the dodo and get replaced by similar functions in IDEs or simply replaced by stronger frameworks as we are already seeing today.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Tags: Security · Security Industry