OWASP A9 and Why You Can’t Ignore It

March 2, 2016 Rami Sass

Open source software has revolutionized the modern tech industry, and nowhere is that more evident than the realm of web application development. Thanks to open source languages, frameworks and development tools, developers are able to create rich and complex web applications, usually at a fraction of the cost— in both time and money—compared to years past.

To help companies use open source software responsibly, the Open Web Application Security Project (OWASP) was founded with the goal of establishing common guidelines for companies concerned with web application security. The OWASP creates and distributes documentation, articles, tools and technologies to assist such companies.

One such piece of documentation is OWASP’s Top Ten list of application security risks, which lists the most common errors that occur frequently and may be easily exploited. Whereas previous versions of the list had cited “Insufficient Transport Layer Protection” as the ninth item, beginning with the 2013 revision, OWASP A9 is now “Using Components with Known Vulnerabilities.” Subsequently, the spotlight is on open source security like never before. 

Why was A9 updated to cover vulnerable components and, most importantly, how does this impact your organization?

Why the OWASP Top Ten List Was Updated with A9?

It’s estimated that well over 80% of all software includes, at least, some open source components. As a result, because of their widespread use, third-party components make a tempting target for potential hackers.

When the above factors are considered, it's easy to understand why OWASP updated their Top Ten list to include “a9: Using Components with Known Vulnerabilities.” While OWASP acknowledges that the simplest way to avoid known security risks is to avoid using components that were not written in-house, they further emphasize that this is an unrealistic option. Such a course of action would deprive a company of invaluable resources and significantly increase the cost and timeframe of any development projects.

In view of this, what steps should a company take to address A9 concerns, avoiding known vulnerabilities and continuing to reap the benefits of open source components?

We help you secure your open source components – download this guide to see how

Establish an Internal Security Policy

One of the biggest mistakes many companies make is not establishing clear guidelines to govern their software development, specifically as it pertains to what open source components are deemed acceptable. This is especially important since not all vulnerabilities are equally dangerous.

The National Vulnerability Database (NVD) is “the U.S. government repository of standards based vulnerability management data.” Using the Common Vulnerabilities and Exposure (CVE) system, vulnerabilities are published to the NVD, providing a centralized place to track security-related software flaws. In addition, the NVD provides a scoring system for vulnerabilities, so they can be scored based on the severity of the risk involved.

Because many open source projects do not always release security patches for older versions of software—instead, simply addressing the issue in future releases—disabling any third-party component that has a vulnerability is not always practical. This is where the CVE scoring system can be of immense help. If a vulnerability’s CVE score is low enough, there may be no practical reason to stop using the affected component while waiting for a new version.

This is why establishing a company-wide policy can be a big help to your company’s development team, not to mention the bottom line. What score will be considered the threshold where a component’s use is suspended? What kind of vulnerabilities will be tolerated? Making sure all of your developers are on the same page—whether it be for open source components or proprietary code—will help ensure a consistent and secure approach.

Identifying Affected Components

Having a policy in place is one thing—following through on it can be quite another. A contributing factor to this challenge is the interdependent nature of open source software.

According to WhiteSource’s research, “91% of software projects contain indirect open source dependencies. The average project relies on no less than 64 different libraries with 8 different licenses.” In addition, “in 65% of the cases, open source components bring with them additional dependencies that are subject to a different license.”

With so many interdependencies, license variations, and individual libraries, manually finding all pertinent CVEs can be a daunting task, made all the more difficult by the fact that sometimes the relationship between a CVE and the affected software is not always readily evident.

This is why an open source management solution is so important for the modern company. WhiteSource has automated this process by analyzing your projects, determining what open source components are in use and cross-referencing the pertinent CVEs to help you find out what, if any, components are vulnerable. Just as important, WhiteSource's management system continuously monitors your software to ensure you are notified as soon as possible when vulnerabilities arise.

By taking advantage of the NVD, understanding CVE scores, establishing a company-wide development policy and using an automated open source management application, you can make sure your company avoids the risks outlined in OWASP A9.


Previous Article
Opening Pandora’s Box – Overcoming Software Supply Chain Risk
Opening Pandora’s Box – Overcoming Software Supply Chain Risk

Few can deny that the software supply chain has become more complex compared to ten years ago. Whereas b...

Next Article
When to Consider a NoSQL vs Relational Database
When to Consider a NoSQL vs Relational Database

Relational databases have been a staple of modern computing since their conception in 1970. Oracle, MySQL, ...