The other day I read this article by Alex Birsan about how Apple, Microsoft and many other companies have been hacked using supply chain attacks.

When downloading and using a package from any of these sources, you are essentially trusting its publisher to run code on your machine.

So can this blind trust be exploited by malicious actors?
Spoiler: Yes, quite easily if you are not careful.

The article is a really great read that I recommend everyone to read.

Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies | by Alex Birsan | Medium

Alex Birsan ・ Feb 9, 2021 ・

Medium

Anyway, I discussed the article with a friend who is an experienced developer. His comment:

The sad truth is that many who work with dependency management are at least partly aware of these risks, but for some reason choose to ignore them.

Unfortunately, this is far too common within so many companies and also one of the reasons we have developed the service Bytesafe which adds security and control to the npm ecosystem.

This post is about creating awareness and giving a few good links to posts with the most important preventative actions you can take right now. I will not cover the more advanced topics such as using signed code, sandboxing etc.

Let's start with why npm is so great and popular?

With 1.5 million available packages there are so many great components to use in your amazing apps. We are humans who all want to do things efficiently and with as little effort as possible. So with the ease of npm, it is quite common that modern applications can use up to 1000 dependencies.

If you visit npm you are greeted by "Build amazing things". Npm is absolutely right, but please take actions to do it securely!

Would you build a house of cards?

If you were to build yourself a new house. Would you pick any parts from any random manufacturer or would you make sure that the selected components make up a solid house with the confidence that there is someone to help if something goes wrong? The same thing applies when developing applications with external dependencies to open source npm packages.

In order to say that you code securely you might have to take a few precautions, such as adding a private registry that acts as a npm proxy and only contains packages that comply with your companies policies. Setting up internal routines will always be important, but having a tool or service that helps is worth a lot, especially if you want to avoid a "house of cards".

npm states that as much as 97% of the JavaScript code you deploy is developed by others.

Below is a visualization of the close to 1600(!) dependencies when setting up a new React app using the instructions on React’s official site. Keeping track manually is impossible!

A simple execution of

npx create-react-app my-app

...results in LOTS of dependencies:

Make sure to add a layer of security using npm security best practices

Do you have insight into what open source components your team is using? Do you feel in control of the dependencies? Continuously scan for security or license issues? If not, the post below is recommended to add a layer of security.

There is a long list of things you should consider to be on the safe side. A while ago I wrote this blog post with 10 npm best practices related to security and license compliance. It's a great start on how to avoid using the public npm registries and how to work securely.

Top 10 Npm Security Best Practices

Daniel Parmenvik ・ Feb 2 ・ 7 min read

#security #npm #node #webdev

Avoid typosquatting

Every day there are developers that slip on the keyboard or are misled to believing they are installing official packages. The practice of intentionally trying to trick developers into installing malicious unofficial packages is called typosquatting.

These types of typosquatting attacks happen all the time, and Twilio will act as an example here.

A lot of people are using Twilio for sending messages. Before it was taken down, developers recently downloaded the twilio-npm package from npm. They missed that the official package is actually twilio. The twilio-npm contained malicious code and has now been removed.

Another safe example is the package reavt which we created two years ago. As you know v is next to c on the keyboard...
The stats show the fact that reavt is almost downloaded on a weekly basis, where most likely the intention was to download react.

Thanks for reading! Comment below if you have any questions or want to share your thoughts. Keep spreading the knowledge how to work securely with npm packages!