One key problem with security code audits is that they tend to cause more problems than they solve. "One size fits all" audit scans tend to overwhelm developers, ultimately leaving the team with a long list of known problems but little actual improvement. In fact, when an audit tool is used near the end of the software development life cycle (SDLC) and it produces a significant amount of potential issues, a project manager is put in the uncomfortable position of having to decide whether to delay the project in order to remediate that code or send it out into the market as is.
Worse yet, sending the product to market with known vulnerabilities exposes the organization to some fairly severe risk. If even a single vulnerability is exploited and there is credible evidence that this issue was previously detected yet not remedied, then the organization will likely face significant financial penalties — not to mention unrelenting questioning about management practices.
A centralized policy-based approach to security prevents security vulnerabilities by ensuring that code is built according to the organization's security expectations — rather than trying to add security on at the end of the process. By leveraging policy management, workflow management, and workflow optimization to drive an automated inline process, teams can make significant improvements to code security without impeding project progress or team productivity.
For example, using static analysis as an audit that occurs at later stages of the SDLC only exacerbates static analysis' tendency to drain development resources. 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 an inline process (which I define as ingraining security verification and remediation tasks as close to development activity as possible) makes the analysis more valuable and more effective. Applying static analysis in this mode promotes two distinct benefits:
- Developers adopt better programming habits, which 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 lies at the core of such an inline process. You should be able to easily configure policies for specific projects without compromising the integrity of the corporate objectives, easily deploy and update both project-specific and organization-wide policies, and automate their application for rapid scanning and reporting. A carefully defined and implemented set of policies establishes a knowledge base that allows developers to increase their relative security IQs.
With a policy established, putting it into practice involves workflow management: defining, automating, and monitoring a workflow that improves development productivity and forms the foundation for a sustainable process. Moreover, tasks to support quality policies must be optimized so they can feasibly become an integral part of the team's existing workflow, ensuring that the static analysis process is both sustainable and scalable. The lack of automation, repeatability, or consistency will degrade any quality initiative that the organization intends to deploy.
One way to optimize the workflow is by using security static analysis in concert with other analysis capabilities, such as metrics analysis and peer code review. This allows you to better optimize the developers' time by focusing their efforts on more severe or more complex scenarios first. For example, if you realize that a certain piece of code that has a high level of Cyclomatic Complexity as well as high severity security issues, you would ultimately want to point developers to that region first in order to tackle bigger more complex problems. In fact, this is a prime example of how code analysis can help you zero in on items that should be discussed during the peer code review.
Other ways to optimize the workflow include the following:
- Routing each reported issue directly to the responsible developer — as well as customizing issue prioritization to suit your policy priorities — ensures that your most critical issues are addressed in a timely manner.
- Centralized configuration management ensures that rule sets are applied consistently and can be updated effortlessly as priorities and processes evolve.
- Using automated refactoring whenever feasible helps the team correct rule violations as fast as possible.
About the author: Wayne Ariola, vice president of strategy at Parasoft, oversees the company's business development team as well as the SOA/Web solutions team. He has 15 years' strategic consulting experience in the high tech and software development industries. Prior to working at Parasoft, he was senior director of business development at Fasturn and a principle consultant for PricewaterhouseCoopers where he was recognized as leader in the strategic change practice. He has a BA from the University of California, Santa Barbara and an MBA from Indiana University.