Vulnerable Dependencies

What are Vulnerable Dependencies?

As applications have grown larger and more complex, the typical number of third-party dependencies has grown as well. This is helpful for developer productivity, since libraries and frameworks are now available to provide common functionality.

One issue with this trend, however, is that the application code base is no longer as opaque as it was when relying less on third-party code. When a security vulnerability is found in a third-party dependency, and a new version with a fix is released, it is the responsibility of the developer learn about this update and get the newly released version.

In addition to vulnerabilities occurring due to errors in the source code of third-party dependencies, there are cases of intentionally malicious packages being released on package management systems in order to exploit misspellings in the name or vacant names left by packages that are no longer maintained:

• Hunting Malicious npm Packages
• Ten Malicious Libraries Found on PyPI

An Example of a Vulnerability

One of the most famous examples is the Heartbleed bug, discovered in 2014. In this case, the OpenSSL library, which is the underlying cryptographic software that is used internally by thousands of other libraries and applications, was found to have a critical security vulnerability.

When announced, this vulnerability forced developers to determine which of their dependencies relied on OpenSSL, verify that they had been updated to use the fixed OpenSSL version and upgrade the dependencies.

How To Defend Against Vulnerable Dependencies

There are tools to help identify vulnerable dependencies, which can help reduce the time needed to keep track of dependency releases. This is a recommended measure, in combination with regular dependency reviews/upgrades.

These are some useful tools and vulnerability indexes:

• https://www.owasp.org/index.php/OWASP_Dependency_Check
• https://snyk.io/
• https://cve.mitre.org/