Security Risk of Open-Source Dependencies

Home / Genel / Security Risk of Open-Source Dependencies

Security Risk of Open-Source Dependencies

Security Risk of Open-Source Dependencies

What is OWASP

The Open Web Application Security Project (OWASP) is an online, open source, and non-profit organization that specializes in creating tools, methodologies, articles, and documentation about web application security. All of this information is freely available and the information is renowned to be practical and unbiased in nature. It also assists firms in developing, maintaining, and buying web applications based on the application’s level of trustworthiness. The OWASP is comprised of a pool of experts in various fields related to web application security across the globe.


The Top 10 is a document that represents a broad or universal consensus on critical security flaws in web applications. The Top 10 consists of errors that are common occurrences and are quite easy to exploit. They can often lead to malicious elements, stealing vital information, or damaging security systems due to minor flaws in a system.

In the simplest form, OWASP Top 10 contains most dangerous risks for application security.

I do not explain entrys at great length. If someone is worried about this, can access the list from here(OWASP Top 10 Release Candidate – PDF).
If you ask my opinion : worry about it.

For secure your application , avoid these vulnerabilities firstly. When some malicious user try to attack your application , they try attack via already founded vulnerabilities firstly.

OWASP Dependency-Check

OWASP dependency-check is an open source solution the OWASP Top 10 2013 entry: A9 – Using Components with Known Vulnerabilities. Dependency-check can currently be used to scan Java and .NET applications to identify the use of known vulnerable components. Experimental analyzers for Python, Ruby, PHP (composer), C/C++ and Node.js applications.

I’d tested OWASP dependency-check tool for sampling, you will see later in the article.

The main problem with using known vulnerable components was covered in a paper by Jeff Williams and Arshan Dabirsiaghi titled, “The Unfortunate Reality of Insecure Libraries” (registration required). The gist of the paper is that we as a development community include third party libraries in our applications that contain well known published vulnerabilities (such as those at the National Vulnerability Database).

Security Vulnerabilities in Open Source

With all the benefits of open source, improper management of its use may result in substantial legal, business, and technical risks. Most research and design managers know that they have to manage open source licenses, but not many are monitoring for security vulnerabilities and other bugs in open source libraries they use.

Do you know the importance of monitoring open source for vulnerabilities before, during, and after using it?

Open source is code like any other, and according to a study by Coverity likely contains defects at a rate similar to other software (~1 defect per 1000 lines of code). According to the Veracode’s State of Software Security report, 70% of applications fail to comply with basic enterprise security policies, such as OWASP Top 10 and CWE/SANS Top 25. However, while software developers test their own code regularly and rigorously, and would immediately tend to fix security vulnerabilities, most are paying little attention to the open source libraries that ship with their products.

OWASP Dependency Check to Jenkins

Let’s get to work : I’ve tested some applications for sampling but i have selected jenkins to post this article. Why? An application as big as jenkins could have so many vulnerabilities? I wanted to show you this.

I checked jenkins and found 23 vulneraible dependencies with 785 vulnearbilities. Some of them have fairly high CVSS(Common Vulnerability Scoring System) score which is critical for security.

Well, what does that mean? This means that third-party dependencies are should be checked for updates. During the software development process : you integrate last version of third-party dependencies. So what happens to after that, you will not update any third-party dependencies most probably. Even you will not know updates. (According to White Source research, 85% of software projects use outdated libraries.)
I seem to hear you say “Will i check all dependencies updates everyday?”
Of course not, you can automate if you want.

How We Are Protected for Dependency Vulnerabilities

Different open-source and commercial tools have emerged over the years to tackle this problem. Each tool/service tackles the problem a bit differently.
Dependency-check is an open-source command line tool from OWASP that is very well maintained. I use this tool for illustration in article.It can be used in a stand-alone mode as well as in build tools. Dependency-check supports Java, .NET, JavaScript, and Ruby. The tool retrieves its vulnerability information strictly from the NIST NVD.
You can use OWASP dependency-check for stay safe and up to date but you may not want to waste time to check updates manually. If you want to automate this job you can use some services(like WhiteSource,BlackDuck,Veracode etc.)

I recommend WhiteSource for some reasons;
This is an cloud based service which is ligtweight service. It’s showing licences, issues, risks, versions etc. Unlike OWASP dependency-check, whitesource works for this issue.I’d recommend whitesource for this vulnerability issue.