You Can’t Ignore Using Components With Known Vulnerabilities

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. When the news of the Equifax breach broke in September 2017, it was that same OWASP Top Ten entry that might have prevented the breach had the company been more on top of their usage of components with known vulnerabilities. OWASP’s top 10 list was updated in November 2017, keeping the Known Vulnerabilities risk in the ninth location.

So what exactly is OWASP A9, why was it updated to cover vulnerable components and, most importantly, how does this impact your organization?

What is OWASP A9 “using components with known vulnerabilities”?

Known vulnerabilities are vulnerabilities that were discovered in open source components and published in the NVD, security advisories or issue trackers. From the moment of publication , a vulnerability can be exploited by hackers who find the documentation. According to OWASP, the problem of using components with known vulnerabilities is highly prevalent.  Moreover, use of open source components is so widespread that many development leaders don’t even know what they have. The possible impact of open source vulnerabilities ranges from minor to some of the largest breaches known. For example, The infamous  Equifax breach, was caused by using an Apache Struts version which had a known vulnerability since March 2017.

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?

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 Mend’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. Mend 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, Mend’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.

Manage open source application risk

Read more