Frameworks and libraries form a significant part of every IT solution nowadays, spanning from simple web applications through enterprise systems to dedicated industrial installations. Their use is a trade-off between ease and speed against code bloat and decreased control. In this post I would like to turn your attention to another factor: dependency security vulnerabilities exposure.
Discovered and ignored
The biggest problem, in my opinion, isn’t with the 0-day vulnerabilities waiting there, hidden in the libraries used by applications we develop. What terrifies me is the fact that so many libraries containing discovered and well documented vulnerabilities are continuously used to devise new software.
Black Duck report, which unfortunately targets only open-source frameworks, states that:
- 67% of tested applications contained open source vulnerabilities
- Average age of open source vulnerability identified: 1,894 days
As an example, I would like to mention a very popular blogging platform WordPress, which can be easily enriched by open-source and commercial plugins. Those plugins are like libraries – pieces of external code solving some particular problem. 47959 of the plugins available to download from the official WordPress site were verified using static code analyzer. This method of verifying security is slick and automatic, but not very sophisticated.
The study showed that almost 3000 of the plugins contained high severity security issues, SQL injection being the second most common. This issue is nothing new. IT security practitioners raised it to nr 9 on the OWASP top 10 list under the name of A9 – Using components with known vulnerabilities. Nevertheless, keeping track of libraries being used in a project is hard enough.
Putting efforts into verifying their security requires even more discipline and is therefore vastly underestimated, not to say ignored.
One of the examples for a solution to this problem is OWASP Dependency-Check. This is an open source tool aiming to identity security vulnerabilities in Java and .Net (Python, Ruby, PHP, Node.js and C/C++ in development) application components. Dependency-check has a command line interface, a Maven plugin, an Ant task, and a Jenkins plugin. All ready to use in your project!
How does it work?
OWASP Dependency-Check consists of a set of analysers that browse through the project dependencies (libraries). They collect basic information about libraries, the evidence. This evidence is then used to identify the dependency in a dictionary provided and maintained by NIST – Common Platform Enumeration (CPE). If a CPE is identified what is left to do is to get all the known vulnerabilities. For this, a Common Vulnerability and Exposure (CVE) lists are used.
You can find many examples of such lists, maintained by different organizations, like NIST’s National Vulnerability Database.
As you probably noticed – there is one caveat. Correctly identifying the libraries requires attention and review during the initial setup of any new dependency.
Will it help me?
Dependency-Check helps automatically assess security exposure of your applications. It is supported and easy to deploy in most popular continues deployment set-ups. The verification is done based on updated and maintained register of known vulnerabilities.
Trying it won’t do any harm and can significantly raise the security of your solutions. In my opinion it is definitely worth giving a try!
Never miss an update by following us and subscribing to our monthly newsletter!
Latest posts by Marcin Lewak (see all)
- From Library to Vulnerability: Dependency Security Vulnerabilities Exposure - March 22, 2017
- The importance of Security Awareness - January 30, 2017
- Extending Support Capabilities with NetIQ IDM Workflows Dashboard - December 21, 2016