When developing enterprise class software applications, 3rd party libraries have to be used whenever necessary. It can be either to reduce development costs, meet deadlines or simply because of the the existing libraries already provide the functionality that you are looking for. Even though the software developed in-house of your organization are developed following best practices adhering to the security standards, you cannot be certain that your external dependencies meet the same standard. If the security of the dependencies are not evaluated, they may even introduce serious vulnerabilities to the systems you develop. Thus it has been identified by OWASP as one of the top 10 vulnerabilities [1]. In this article, I will discuss how to manage security of your project dependencies and how to develop a company policy for using 3rd party libraries. I will also discuss and demonstrate how this can be automated as a process in the software development life cycle.
Before moving ahead with the topic, we need to be familiar with the technical jargon. Go through the following content to get some idea on them.
What is a 3rd Party Library ?
A reusable software component developed to be either freely distributed or sold by an entity other than the original vendor of the development platform.
The third-party software component market thrives because many programmers believe that component-oriented development improves the efficiency and the quality of developing custom applications. Common third-party software includes macros, bots, and software/scripts to be run as add-ons for popular developing software. [2]
Using 3rd Party Components in Software Development
If you have developed software using any 3rd party library (here I have considered C# and Java as an example), following should be familiar to you where you have injected your external dependencies to your project in the IDE.
|
|
|
3rd party dependencies of a C# project in Microsoft Visual Studio
|
3rd party dependencies of a Maven based Java project in IntelliJ IDEA
|
Direct 3rd Party Dependencies
The external software components (developed by some other organization/s) that your project depends on are called as direct 3rd party dependencies. In the following example, the project com.tharindue.calc-1.0 (developed by myself) depends on several other libraries which are not developed by me, but by some other organizations.
Direct 3rd Party Dependencies with Known Vulnerabilities
The external software components (developed by some other organization/s) with known vulnerabilities that your project depends on are direct 3rd party dependencies. In this example, the project that I work on depends on commons-httpclient-3.1 component which has several known vulnerabilities [3].
Transitive 3rd Party Dependencies
The software components that your external dependencies depend on are called as transitive 3rd party dependencies. The project I work on, depends on com.noticfication.email component and com.data.analyzer component which are the direct 3rd party dependencies. These libraries have their own dependencies as shown below. Since my project indirectly depend on those libraries, they are called as transitive 3rd party dependencies.
Transitive 3rd Party Dependencies with Known Vulnerabilities
The software components with known vulnerabilities that your external dependencies depend on belong to this category. Here my project has the transitive 3rd party dependency of mysql-connector-5.1.6 library whereas it has several known vulnerabilities.
What is a Known Vulnerability
When we use 3rd party libraries which are publicly available to be used (or even proprietary), we may find a weakness in that library in terms of security that can also be exploited. In such case we can report the issue to the development organization of that component so that they would fix it and release as a higher version of the same component. Then they will publicly announce (Through a CWE or a CVE discussed later) the issue they fixed so that the developers of other projects that are using the vulnerable component get to know the issue and apply safety precautions to their systems.
Common Weakness Enumeration (CWE)
A formal list or dictionary of common software weaknesses that can occur in software's architecture, design, code or implementation that can lead to exploitable security vulnerabilities. CWE was created to serve as a common language for describing software security weaknesses; serve as a standard measuring stick for software security tools targeting these weaknesses; and to provide a common baseline standard for weakness identification, mitigation, and prevention efforts. [4]
Common Vulnerabilities and Exposures (CVE)
CVE is a list of information security vulnerabilities and exposures that aims to provide common names for publicly known cyber security issues. The goal of CVE is to make it easier to share data across separate vulnerability capabilities (tools, repositories, and services) with this "common enumeration." [5]
CVE Example
ID : CVE-2015-5262
Overview :
http/conn/ssl/SSLConnectionSocketFactory.java in Apache HttpComponents HttpClient before 4.3.6 ignores the http.socket.timeout configuration setting during an SSL handshake, which allows remote attackers to cause a denial of service (HTTPS call hang) via unspecified vectors.
Severity: Medium
CVSS Score: 4.3
|
CVE vs. CWE
Software weaknesses are errors that can lead to software vulnerabilities. A software vulnerability, such as those enumerated on the Common Vulnerabilities and Exposures (CVE®) List, is a mistake in software that can be directly used by a hacker to gain access to a system or network [6].
Common Vulnerability Scoring System (CVSS)
CVSS provides a way to capture the principal characteristics of a vulnerability, and produce a numerical score reflecting its severity, as well as a textual representation of that score. The numerical score can then be translated into a qualitative representation (such as low, medium, high, and critical) to help organizations properly assess and prioritize their vulnerability management processes [7].
National Vulnerability Database (NVD)
NVD is the U.S. government repository of standards based vulnerability management data represented using the Security Content Automation Protocol (SCAP). This data enables automation of vulnerability management, security measurement, and compliance. NVD includes databases of security checklists, security related software flaws, misconfigurations, product names, and impact metrics.
Using 3rd Party Dependencies Securely - The Big Picture
All the 3rd party dependencies (including 3rd party transitive dependencies) should be checked in NVD for detecting known security vulnerabilities.
When developing software, we need to use external dependencies to achieve the required functionality. Before using a 3rd party software component, it is recommended to search in the National Vulnerability Database and verify that there are no known vulnerabilities existing in those 3rd party components. If there are known vulnerabilities, we have to check the possibility of using alternatives or mitigate the vulnerability in the component before using it.
We can manually check NVD to find out if the external libraries we use have known vulnerabilities. However, when the project size grows where we have to use many external libraries, we cannot do this manually. For that, we can use tools and given below are some examples.
Veracode : Software Composition Analysis (SCA)
This is a web based tool (not free !) where you can upload your software project and it will analyze the dependencies and give you a vulnerability analysis report.
Source Clear (SRC:CLR)
This provides tools for analyzing known vulnerabilities in the external dependencies you use. The core functionality is available in the free version of this software.
OWASP Dependency Check
Dependency-Check is free and it is a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities. Currently Java, .NET, Ruby, Node.js, and Python projects are supported; additionally, limited support for C/C++ projects is available for projects using CMake or autoconf. This tool can be part of a solution to the OWASP Top 10 2013 A9 - Using Components with Known Vulnerabilities.
Following are some very good resources to know more about OWASP Dependency Check tool.
Official Website
Vulnerability Detection
Command Line Tool (CLI)
|
Continuous Vulnerability Management in a Corporate Environment
When developing enterprise level software in an organization, the developers cannot just use any 3rd party dependency that does provides the required functionality. They should request approval from engineering management to use any 3rd party software component. Normally the engineering management would check for the license compatibility in this approval process. However it is important to make sure that the 3rd party dependency has no known security risks for using it. In order to achieve this, they can search the National Vulnerability Database to check if known issues are there. If no known security risks are associated with that, the engineering management can approve using the dependency. This happens in the initial phase of using 3rd party dependencies.
During the development phase, the developers themselves can check if the 3rd party dependencies have any known vulnerabilities reported. They can use IDE plugins that automatically detect the project dependencies, query the NVD and give the vulnerability analysis report.
During the testing phase, the quality assurance team also can perform a vulnerability analysis and certify that the software product does not use external dependencies with known security vulnerabilities.
Assume that a particular 3rd party software component does not have any known security vulnerabilities reported at the moment. Then we pack it in our software and now our customers are using the software. Let’s say after 2 months of the software release, a serious security vulnerability is reported against that 3rd party component which makes our software also vulnerable to an attack. How to handle a scenario like this ? For this, in the build process of the software development organization, we can configure a timely build job (using a build server like Jenkins, we can schedule a weekly/monthly build for the source code of the released product). We can integrate plugins to Jenkins to query NVD and detect vulnerabilities of the software. In this case, we can retrieve a vulnerability analysis report and that would contain the reported vulnerability. So we can create a patch and release to customers to make our software safer to use. You can read more on this in [8].
Above we talked about handling security of 3rd party software components in a continuous manner. We can call it as continuous vulnerability management.
Getting Rid of Vulnerable Dependencies
Upgrade direct 3rd party dependencies to a higher version. (For example, if you use Apache httpclient 3.1, it has several known vulnerabilities. However if you use the latest version like 4.5.2, it does not have reported vulnerabilities)
For transitive dependencies, check if the directly dependent component has a higher version that depends on a safer version of the transitive dependency.
Contact the developers of the component and get the issue fixed.
Challenges : Handling False Positives
Even though the vulnerability analysis tools report that there are vulnerabilities in a 3rd party dependency, there can be cases where those are not applicable to your product because of the way you have used that software component.
Challenges : Handling False Negatives
Even though the vulnerability analysis tools report that your external dependencies are safe to use, still there can be unknown vulnerabilities.
Summary
Identify the external dependencies of your projects
Identify the vulnerabilities in the dependency software components.
Analyze the impact
Remove false positives
Prioritize the vulnerabilities based on the severity
Get rid of vulnerabilities (upgrade versions, use alternatives)
Provide patches to your products
Notes :
This is the summary of the teck-talk I did on Jun 15th, 2016 at the Colombo Security Meetup on the topic ‘Secure Software Development with 3rd Party Dependencies’.
|
References
Tharindu Edirisinghe (a.k.a thariyarox)
Independent Security Researcher
