GitHub & npm Security

FAQs
1

Hi all,

You are hopefully aware of the recent dramatic increase in attacks on open source supply chains. Especially code on GitHub and npm.

I've been increasing security on my GitHub repositories over time and have re-checked things again over the last week or so.

If you are pushing code (or anything really) to public repository platforms like GitHub and npm, you really should be considering repository security very seriously. The recent compromises have been quite devastating to those people caught up in them. Thankfully, it looks like node-red has escaped this time around.

As is often the case when it comes to cyber security, the UK's National Cyber Security Centre (NCSC) who I've had dealings with over the years publish excellent guides for all sorts of things and they have guidance on securing repositories as well.

GitHub also have a good set of help documents covering all aspects of account and repository security.

So sharing here in the hopes that everyone does their bit to help all of us stay safe online.

1 Like
2

I did see that youtube clip about npm but wasn't sure it applied to NR also.

Thanks for sharing the information.

1 Like
3

Thankfully, though node-red does use some of the compromised packages, not the specific compromised versions.

However, the recent attack was merely the latest in a long and accelerating line of attacks sadly.

One of the things that I've been doing with UIBUILDER and my web components in particular is to reduce the number of external libraries I depend on. So, for example, in UIBUILDER, whereas I was making extensive use of the fs-extra library (which node-red also uses), I am actively eliminating that. Similarly for other libraries where I may be only using a small portion of their capabilities, like my former use of execa for running external apps, collapsing the necessary capabilities into my own code. Not only does this trim the fat off the installed size of my packages, it also removes a large portion of the supply-chain exposure.

Thankfully, there are now quite a few really useful tools available for free on GitHub that help review your own code as well as looking for supply-chain issues.

From now on, all my code contributions are cryptographically signed, the repo's are locked down and I use security tooling to carefully review all commits, pull requests, and external library updates.

4

No, I wasn't.

flows.nodered.org points to many different npm and github accounts.
Does that suggest we should regard all contrib nodes as possibly compromised - more so than in the past at least?
What are the possible implications of installing a compromised contrib node?

5

No, you should rely on authors to be checking their repositories for issues. :slight_smile: The main Node-RED repo is already using some tools for this, as is UIBUILDER. This is about making sure that other authors are aware and actively checking for issues.

There was a post about the specific issue not long back and someone posted a command-line that would let you check your installation for that specific issue.

Thankfully, only specific versions of libraries were compromised so for an environment like node-red, you were relatively unlikely to get compromised. Other packages were less fortunate.

Well, this partly comes back to things I've said in the past (that most people ignore). Installing Node-RED globally with access to everything you do (e.g. installing on your main PC and using your standard user), or worse still, installing globally on Linux without specifying a restricted user, will give Node-RED access to pretty much EVERYTHING on that device and possibly access to other devices depending on your setup.

So, yes, the consequences could be totally devastating.

However, the way that npm works does have its advantages as well. Compromised versions - as long as someone spots them - can quickly be removed so that installations and updates either don't install the bad version or replace them with a better version.

Also, the nature of node.js apps with their typically deeply nested libraries, while presenting a rather large attack surface, does mean that deployed libraries are not always updated very often and so compromises typically have to be in place for quite some time for them to spread.

Compromises of end-user machines are, thankfully still fairly rare. Some common-sense practices go a long way towards safety as well. For Node-RED, aim to keep it and its installed packages updated at least every few months, similarly for node.js itself. And install under a restricted user id to limit what it can do.

Thankfully, using Dave's Debian install script does things reasonably well (though it still installs node-red globally which isn't perfect). My own alternate installer shows you how to install locally and, in my view, has a number of advantages in terms not only of security but also backups and the ability to run multiple different versions of Node-RED in parallel.