How Will you Manage the New Addition of A9 to the OWASP Top 10 List?

June 18, 2013 By Jessica Dodson

It’s fair to say we were excited back in May when the OWASP community proposed A9 “ Using Components with Known Vulnerabilities” as a top 10 open source security risk – so now it’s official, component vulnerabilities are considered a critical web security flaw. But why has this addition warranted its own category, formerly classified under ‘Security Misconfiguration’? Has the problem truly compounded that much in the last 3 years that now, component vulnerabilities need to be on a watch list? Well simply put, YES. According to the largest open source component repository, The Central Repository, component downloads have grown from 1.5 billion requests in 2008 to over 8 billion requests in 2012. Now that’s a quite growth pattern.

Today the use of 3rd party frameworks and libraries in application development is an everyday practice, but unfortunately proper security policies aren’t. So how do you know what security risks really exist? As OWASP points out, this isn’t an easy question to answer “most development teams don’t focus on ensuring their components/libraries are up to date. In many cases, the developers don’t even know all the components they are using, never mind their versions. Component dependencies make things even worse.”

So how do you manage this problem effectively? Well our CEO says, securing the software lifecycle requires both humans and machines. Humans define the security and license policies, machines automate these policies and humans manage the expectations. With these policies and enforcement in place (right in the developer environment) the possible vulnerabilities are detected earlier in the software development lifecycle and developers have the option to remediate these risks and use other components that meet their organization’s security policies.

A perfect use case for remediating possible security threats during the development lifecycle happens after the build promotion and staging. You can define policies based on security, licensing  and quality standards. If the build doesn’t meet the set policies, the build can be stopped and the developer can be notified before the release workflow is allowed to continue. You can see this example in action in an upcoming webinar, ‘Nexus Pro: Fully Automate Your Build Promotion’ as a way to start thinking about the value of managing components against your open source security policies.

For those concerned about the recent OWASP A9 announcement (which should be all of you), watching this webinar is a great entry point into defining a larger vision for lifecycle component management. Don’t wait to your CISO comes to you with a question about where and how you’re using 3rd party components with known vulnerabilities, start incorporating policy enforcement during the development lifecycle now.