Static analysis for security has been such a hot topic lately that it seems the industry is starting to think of it as a silver bullet. The quest for application security has breathed new life into static analysis technologies, which until quite recently were primarily perceived as either frivolous beautification tools or burdensome big brother monitoring systems. Surprisingly, the underlying technology was not substantially modified to accommodate the issue of security; rather, the changes were more like a face lift. As a result, organizations using static analysis technology still encounter the same fundamental challenges in making it sustainable over time.

The secret to making static analysis technologies a productive analysis solution is to use them in the proper context. The adoption of this technology should be driven by a policy-based approach. This means establishing a policy that defines requirements, then enforcing that policy consistently—not only with automation to ensure that the required practices are sustained, but also with workflow, task management, and metrics that enable you to measure how well the policy is being implemented. In the context of policy, static analysis is elevated from a “nice-to-have” checker to a critical tool for ensuring that code meets the organization’s expectations.

Context is King

The most likely culprit for static analysis’s reputation as a non-essential technology is its lack of context. Products provide “out-of-the box” support for hundreds of rules which could be important in many different contexts. However, most organizations don’t take the time to determine which rules are most important in the context of the organization, team, and project, then require compliance to those carefully-selected rules. As a result, rule violations are perceived as suggestions for general code improvements—not critical coding issues that need to be addressed immediately.

It’s not unlike how many of us treat violations from our word processor’s grammar check. If it reports that you should avoid using the passive voice (“John was kicked by Joe” as opposed to “Joe kicked John”), do you really worry about it? Nice to know… but in most contexts, it’s not a problem that you absolutely must fix, like a spelling error or subject-verb agreement error. Yet, if you know that your work won’t be approved if you write in the passive voice, then this grammar “violation” becomes important in your context…and you pay attention.

How Policy Helps

The key to providing the necessary context to static analysis is to take a policy-based approach: use static analysis to monitor a non-negotiable set of expectations around code security, reliability, performance, and maintainability. With this approach, a violation of a particular guideline is not just another suggestion for people building software in an ivory tower—it’s notification that the code failed to meet the organization’s expectations.

Effective policy management allows an organization to bridge the gap between management expectations and developer performance. Essentially, if a static analysis rule enforces something that is part of the policy, fixing a violation of that rule is non-negotiable. If a developer fails to satisfy the defined policy, he is not executing his job as expected by management.

Organizations committed to leveraging static analysis for the purpose of policy application and management have found that it helps them produce a solid foundation by exposing structural errors upon introduction and preventing entire classes of errors. The result is greater productivity and significantly fewer software defects.

What’s Needed to Make it Work

The rising risk and impact of application-level security attacks has brought static analysis and its challenges into new light. Static analysis has great potential for ensuring that code is written in ways that prevent security vulnerabilities. However, to ensure that static analysis delivers as promised here, it’s essential to address the challenges that have traditionally stymied its success. This is where considerations such as policy management, workflow management, and workflow optimization come into play.

Audits vs. An Integrated SDLC

Using static analysis as an audit that occurs at later stages of the SDLC only exacerbates static analysis’ tendency to drain development resource. The later in the cycle that static analysis is performed, the less likely it is that the responsible developer will remember the related code and be able to rapidly understand and remediate the problem.

Having security tightly integrated into the SDLC makes the analysis more valuable and more effective. Applying static analysis in this mode promotes two distinct benefits:

• Developers adopt better coding habits that help them write better code faster. The task created to remediate a potential security issue is better understood in the context of what the developer was trying to achieve. Therefore, it is more likely the developer will learn from his mistakes and eventually start writing compliant code as a matter of habit.
• Developers remediate problems faster and easier. If the code is still fresh in the developer’s mind when the problem is reported, the developer doesn’t need to waste time trying to remember what the code was supposed to do, why he wrote it the way he did, what impacts he needs to consider when modifying the code to meet security expectations, and so on. As you can imagine, learning about the same issue weeks or months later would require significantly more work to achieve the same outcome.

Policy Management

Policy management lies at the core of a process where security is integrated into the SDLC...

To read more, download the complete Success with Static Analysis for Security paper as a PDF.