Safe Dependencies

  • 5 minutes

A large percentage of code present in modern applications is made up of the libraries and dependencies that you, the developer, choose. This is a common practice that saves time and money. However, the downside is that you're now responsible for this code—even though others wrote it—because you used it in your project. If a researcher (or worse, a hacker) discovers a vulnerability in one of these third-party libraries, the same flaw is likely also present in your app.

Using components with known vulnerabilities is a huge problem in our industry. It's so problematic that it's made the OWASP top 10 list of worst web application vulnerabilities for several years.

Track known security vulnerabilities

The problem we have is knowing when an issue is discovered. Keeping our libraries and dependencies updated (#4 in our list!) will of course help, but it's a good idea to keep track of identified vulnerabilities that might impact your application.

Important

When a system has a known vulnerability, it's much more likely also to have exploits available; code that people can use to attack those systems. If an exploit is made public, it's crucial that any affected systems are updated immediately.

Mitre is a non-profit organization that maintains the Common Vulnerabilities and Exposures list. This list is a publicly searchable set of known cybersecurity vulnerabilities in apps, libraries, and frameworks. If you find a library or component in the CVE database, it has known vulnerabilities.

The security community submits issues when a security flaw is found in a product or component. Each published issue is assigned an ID and contains the date discovered, a description of the vulnerability, and references to published workarounds or vendor statements about the issue.

How to verify if you have known vulnerabilities in your third-party components

You could put a daily task into your phone to check this list, but luckily for us, many tools exist that allow us to verify if our dependencies are vulnerable. You can run these tools against your codebase, or better yet, add them to your CI/CD pipeline to automatically check for issues as part of the development process.

You can use some tools made specifically for static code analysis for this, as well.

For more information on the risks involved in using vulnerable components, visit the OWASP page dedicated to this topic.

Summary

When you use libraries or other third-party components as part of your application, you're also taking on any risks they might have. The best way to reduce this risk is to ensure that you're only using components that have no known vulnerabilities associated with them.