A Dynamic Approach to Static Analysis

The following is intended for people who want to do things differently, and see an improvement in the security of their web applications. If you are looking for an acronym and a quick fix to get insecure code fast-tracked into production so you get a bigger bonus, go here.

The problem with static analysis tools is not false positives. It's also not getting code to compile, or integrating source code scanning into the nightly/weekly/monthly build process. These are limited, one time challenges that can be overcome with a few days, sometimes just hours, of work by a capable individual.

In my opinion, the problems that hamper the success of static analysis tools are:

1. Management sees source code scanning as a panacea, and lacks an understanding of the business process changes needed to support static analysis in a large development organization.

2. Developers are often not trained to fully understand the findings the tools provide, and are not given the resources and education required to fix bugs or alter bad development practices.

Management likes to know about the badness in their apps, and the pretty graphs and reports that the tools can generate make them feel like they have a handle on things. Unfortunately, the 1500 cross site scripting vulnerabilities in the report won't disappear unless the developers have time to fix them.

Making the vuln's disappear from the chart might make management feel warm and fuzzy, but if they are merely obfuscated such that the tool doesn't see them, everyone is even worse off then before. That's why it's important that your developers know how to properly fix the problems. A black-listing routine may trick your static analysis tool, but it won't trick a pen-tester - or an adversary.

The first time you scan your code and find that you have a gazillion cross site scripting vulnerabilities, your first priority should not be to put the static analysis tool on everyones desktop, or to configure nightly automated scans. If you want to make some serious improvements to your code base, try following these three steps:

Step One - Get Help
Hire a security architect - or bring in a consultant - to help you understand how the security issue effects the application has a whole, as opposed to individual lines of code. When you realize that the application fails to properly sanitize input across the board, you can develop remediation plans that solve this problem across the board (like secure APIs).

Step Two - Get Resources
Make management aware of the problem and how it is costing them money. Exploit vulnerabilities in the application in front of them. Show them how YOU can hijack THEIR account. When you do this, you need to also describe your remediation plan, and let them know the resources you need to make things right. Show them how efficiently you can standardize input validation using a secure API. Your consultant or architect should be able to help you here. If not, get a new one!

Step Three - Get Results
Once management has eagerly met your demand for resources, train your developers. Exploit the same vulnerabilities in front of them that you showed management, but also show them where the problem exists in the source code. Show them how easy it is to fix each vulnerability with the secure API! Send them off to review and fix their own code. Follow up with a static analysis scan in a week or two.

After your first round of step three, you should see a sharp decline in the number of vulnerabilities. Let your developers know the good news, and keep repeating step three until input validation problems are a thing of the past!

After that, you can focus on things that static analysis tools are not good at finding - like access control issues in your business logic.