On February 29, Veracode released its second service update of 2012. Our 2012.2 release has a bunch of features aimed at simplifying a variety of parts of rolling out and engaging users in an application security program, including provisioning users, working with flaws on the desktop, and getting developers engaged in the process of fixing security issues.
Today I'll talk about getting developers engaged in fixing security issues, because it's one of the hardest and most challenging problems with rolling out an application security program. As Chris Eng pointed out in his earlier blog post, developers can get very defensive--if that's not polite a way to describe it-- when confronted with their first application security test. And that defensive reaction, if it's repeated enough times, can cause a program rollout to slow to a crawl or even halt. You can make an application as easy to scan as you can--and we are laser focused on that--but getting developers to engage and to stay engaged, and to repeat the scan, is key to the success of the program.
But why do developers get so angry about getting their applications graded? Partly, I think there is a legacy perception of security scanning as producing high noise, low-actionable findings. I think Veracode has industry leadership in reversing this trend, though keeping the noise down is something that we always focus on.
But the bigger factor is psychology. Historically, every static scanning tool is used to "scan and scold." Developers may be doing a good job in some areas of application security, but typically scanners are only focused on the presence or absence of flaws, and not whether there are active defenses in place against attacks. But paradoxically, it's the presence of those active defenses that are the most direct measure of the efforts developers make to secure the applications.
Enter Veracode's new Best Practices reporting, affectionately nicknamed "Project Greenlight." In Greenlight we've turned static scanning on its head by looking for cases where developers are using security features like cryptography correctly, and where developers are actively and successfully defending against specific types of attacks. For instance, a flaw with two possible exploitable paths, where both paths are guarded by a recognized cleansing function, earns the developer a point that's specifically called out in the report. If a developer has successfully defended all possible attack points in an application, they earn a green light in the report. If they're still in progress and there are still flaws found for that category, they get partial credit, a yellow light. And the great thing about it is that it doesn't impact our rapid turnaround times at all--it's a byproduct of the thorough modeling and scanning that we do for all applications.
We think Greenlight has the potential to make the conversation with developers much less one-sided, and to give them data that illustrates the progress they are making in securing their apps. And that translates directly to faster implementations and better remediation.
If you like defending your software against attackers, try defending against attacking robot ninjas in Veracode Defender!