Securing open source packages

Security basics when using open source packages.

Not to scare you too much, but did you know that according to scans done by the trusted Snyk, they found 77% of ~443K sites that they scanned contained at least one vulnerable NPM package?

Security should not be an afterthought, like it is for most people - including myself until recently when I started reading heavily on security.

NPM packages

Have you ever looked at how many NPM packages your project has? Thousands and thousands, even for a trivial setup. This is scary, seeing how all you need is one vulnerable package to get hacked.

Ruby Gems

Although the number of ruby gems are tiny compared to most Node projects, it's still a big deal, especially if you're using rails and have a lot of "magic" going on that you're unaware of.

What to do

Even without paying for a service like snyk, you can take advantage of a few free easy wins to step up your security:

Upgrade your Node and NPM version

This helped our team turn ~1000 vulnerabilities found by running yarn audit into 0. That's right, zero.

As a bonus, you'll get to start using the latest features and performance gains of the later versions.

Run NPM/Yarn's/Ruby built-in vulnerability scanner

I chose Hawkeye for my projects to run all the available scanners at the same time, in my case npm audit and bundle audit, but there are also packages for Python, passwords/secrets, etc.

Alternative: if you don't want to use Hawkeye, you can do each scan manually.
By simply running npm audit (or yarn audit if you're using yarn), you'll get a list of known vulnerabilities related to the packages that are installed in your project.
For Ruby, you'll need to install bundler audit to be get the same functionality for your ruby gems by running bundle audit.

Bonus: run the vulnerability scan before pushing your commits to Git for an even more automated workflow. Here's what my package.json config roughly looks like:

"scripts": { 
	"scan": "npx hawkeye scan", 
"husky": { 
	"pre-push": "scan"

Run a proprietary scanner periodically

Then to get any possible vulnerabilities that the built-in scanners didn't detect, you can use something like Snyk, which is free for open source projects, and built-in with Google Lighthouse and Webhint scanners for free, regardless of your project being open source.

You can also integrate it with GitHub on it's own with their paid service.

Since this requires you to either scan your live website or start your server in one terminal, open another and run the scan against your local repo, I only run this service once a week or so, when I review my bug reports, statistics, etc. so it's not so painful.

Only install packages that look trustworthy

Yes, it's tempting to install every cool new "bleeding edge" package out there and tinker with it. But as a rule of thumb, I recommend at least making sure that the author/contributors at least seem trustworthy.

Here's a checklist that I use to evaluate any new package that I'm considering:

  • Does the author have multiple packages that are used frequently and tested, or are they an established company? If not, the author could have easily made a fake account, added malicious code with a hot keyword and is just waiting to hack someone...
  • Are any other packages relying on them? You can check this is NPM under the "Dependents" tab. Good indicator that people are using the code in production.
  • Is there any recent activity on GitHub? Ideally, the author maintains the package well, keeping dependencies up to date and checking for malicious packages themselves.
  • Lastly, are there a good amount of stars on GitHub and downloads on NPM? Another indicator of how many people are using it. The more the better.


This is not an exhaustive list of everything you can possibly do to stay protected, but it's a great start and gets you in the mindset of security if you're not already there. Happy coding! SL

Subscribe to Sean W. Lawrence

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.