Vendoring and Dependency security 

In 2019 it has become standard practice to download dependencies straight off of the internet without verifying the code is secure and free of bugs. Software Engineers typically look up a dependency on github and follow the instructions to add it immediately to their project’s dependencies. More thorough engineers might take a few minutes to read through the code before adding it to their package.json file. 

This era of downloading dependencies off the internet without worrying about the security or integrity of the code has coincided with several notable hacks. The event-stream hack [1] which injected malicious bitcoin stealing code into a library used by thousands of NPM packages is only the latest in a series of hacks which take advantage of our loose standards for adding packages to our projects. 

Vendoring is the practice of embedding dependencies, binary or source code, into our codebases. The practice was popularized by the Go language, but had been used internally by Google and several other companies before that. Vendoring your dependencies adds an additional step, of committing new code to your repository, before new code can enter your software. And if you have all the source code for your dependencies vendor in your repository, you are at least able to verify all of the code in your system. 

Google stores all dependencies inside its custom version control system and has a process to vet new dependencies before they can be consumed by engineers. But most companies I have worked for had no restrictions on what dependencies could be added to a project whatsoever. 

The current status code of trusting without verifying code will continue to result in major hacks. The open-source ecosystem is too big to audit. And most companies do not even attempt to vet their dependencies. The many libraries created by independent developers which make open-source great are the least likely to be audited and most susceptible to custody hacks like what happened in the case of event-stream. 

 

[1] https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident

Leave a Reply

Your email address will not be published. Required fields are marked *