Security concerns with using third-party dependencies

Outdated libraries and vulnerabilities

The first issue with third-party dependencies is that you must rely on their developers to keep the libraries up to date. Very often libraries will come from big open-source, well maintained projects. But there are also small projects, which are usually maintained by individual developers. So you rely on a person to have secure code. Individual coders don't have the resources to maintain consistent testing for every version, and they don't always fix bugs and vulnerabilities quickly. Even when the developer fixes vulnerabilities, your team must then take the time to update the library to the latest version and make sure it does not crash the application where it is used.

Developers of the libraries must always watch for the latest updates of their dependencies too. But it also takes time to ensure that the new version of a dependency is compatible with the local codebase. Some libraries introduce breaking changes with new versions , which means developers will need to update the codebase to avoid errors. Refactoring code to cater to library changes is always frustration, so developers hesitate to introduce updates frequently.

Abandoned projects

Importing libraries that developers abandoned is another security risk to consider with third-party dependencies. Most abandoned projects have vulnerabilities that are ignored and never fixed. Unless your developers are willing to refactor a third-party library, an abandoned dependency leaves your own application open to exploits.

In that case another option is to use a library which is an alternative to abandoned library. But then this means your codebase must be refactored to work with the new library's API.

In order to avoid sticking to abandoned projects, before deciding on using a library always research the developer and library activity to ensure that the codebase is frequently updated. Also, keep in mind that a project with big community of developers is always trustworthy. You can expect it to be maintained properly. Not to say evolve with new handy features.

Change of ownership is risky

Sometimes instead of abandoning projects, developers pass ownership to another person without a notification. The new owner can inject anything into the source code, including malicious scripts.

In 2018, the developer of a popular JavaScript library called Event-Stream turned over ownership to another developer. This new source code owner injected malware to steal Bitcoin from Bitpay and Copay wallets. Any developers who downloaded this dependency into their applications added threats to customer data. The third-party library had been downloaded by thousands of other developers, so the changes put potentially millions of people at risk.

Checking libraries for vulnerabilities

Most applications have at least one third-party dependency to save development time. Developers, and quality assurance people should frequently check currently used versions and compare them to the latest dependency release. Vulnerabilities are published publicly, so anyone in charge of checking library versions can perform a search for issues using the National Vulnerability Database . This database lists any reported issues found by cybersecurity researchers.

In JavaScript world NPM project does a great job of notifying developers about vulnerabilities. Whenever a new library is installed in a project, npm utility notifies developers about any security issues found in the library or in any of its dependencies.

Be wise and keep safe with third-parties

Third-party dependencies are a part of most applications, no one can avoid them. They just must be included with caution. Track security reports attentively, and always apply critical updates immediately after they get released.