Third party software components

Many software projects depend on other software projects. Using other people’s code saves a lot of time and allows you to quickly build advanced software. However, the security of that software is usually unknown. You could review and test the component, but that may take time, which we were trying to save. However, it is relatively easy to check if the components contain known security vulnerabilities, especially if automated tools are available.

Checking for known vulnerabilities

You should regularly scan your components, as new vulnerabilities are discovered every day. For certain programming languages, Github automatically scans a project’s dependencies for known vulnerabilities [Github].

Be aware that such a scan can only find known vulnerabilities. The MITRE organization maintains the Common Vulnerabilities and Exposures (CVE), a list of vulnerabilities [CVE]. Every entry in the list has a so-called CVE number, such as CVE-2014-12345. This makes it easy to find information about a vulnerability.

Sometimes you will see a severy rating for a CVE. While MITRE does not assign these, other vulnerability databases, such as the National Vulnerability Database (NVD), assign a CVSS (Common Vulnerability Scoring System) score to vulnerabilities [CVSS]. Such a score can help, but be aware that the score may not apply to your specific situation.

The NVD entry may also list mitigations for the vulnerability. Before you apply a mitigation, it can be a good idea to see whether the vulnerability applies to your software. If nobody can exploit the vulnerability or if it has no negative impact, you may not need to mitigate it. It may take some time to analyse the exploitability and often it is simpler to apply the mitigation.

Not all third party code is under your control. Code that uses a dynamic library often does not build and ship that library. Therefore you cannot always know what version of that library the program will use. Although it is possible to put version checks and restrictions in the build process, in practice security is often not the reason to do this. Advising to use or not use a certain version of a software library is more common and less restrictive for people who, for some reason, have to or want to use the insecure library.

Tools for vulnerability checking

Many tools are available to check for known vulnerabilities in your dependencies. Some of these tools do much more than that. The following - incomplete - table shows some tools that may be interesting in particular for open source projects.

tool	platform	license or cost	URL
npm audit	JavaScript	open source/commercial	https://www.npmjs.com/
retirejs	JavaScript	open source	http://retirejs.github.io/retire.js/
audit.js	JavaScript	open source	https://www.npmjs.com/package/auditjs
Snyk	various	commercial, no cost for open source	https://snyk.io/
OSSIndex audit tools	various	open source	https://github.com/OSSIndex/
Bundler-audit	Ruby	open source	https://github.com/rubysec/bundler-audit
Hakiri	Ruby	commercial, no cost for open source	https://hakiri.io/
OWASP dependency check	various	open source	https://www.owasp.org/index.php/OWASP_Dependency_Check

If there is no vulnerability checker for your software environment, you may still be able to automatically generate a so-called ‘bill of materials’ (BOM): a list of all dependencies for your software. This is possible for example with Python’s pip or Go’s dep tools.

Summary

A large part of the software we write is third party software. A complete security check of this software is often not feasible, and the best we can do is to check for known vulnerabilities. Automated tools may be available to check for vulnerabilities or at least generate a bill of materials.