How to respond to growing supply chain security risks?
Tags: javascript, webdev, opensource, security
Published: 2022-04-03 10:07:33

---
title: How to respond to growing supply chain security risks?
published: true
description: Each month since October 2021 we have a new security incident in the npm supply chain. How we are going to react to it?
tags: js, webdev, opensource, security
//cover_image: https://direct_url_to_image.jpg
---

Each month since October 2021 we have a new security incident in the npm supply chain.

-   October 2021 ([ua-parser-js](https://blog.sonatype.com/npm-project-used-by-millions-hijacked-in-supply-chain-attack))
-   November 2021 ([coa](https://www.esentire.com/security-advisories/coa-npm-supply-chain-attack), [rc](https://www.esentire.com/security-advisories/rc-npm-supply-chain-attack)) 
-   December 2021 ([qr.js](https://blog.sonatype.com/researcher-takes-over-qr.js-via-repo-hijacking.-is-the-npm-package-safe), [discord-lofy + discord-selfbot-v14](https://jfrog.com/blog/malicious-npm-packages-are-after-your-discord-tokens-17-new-packages-disclosed/))  
-   January 2022 ([colors + faker.js](https://snyk.io/blog/open-source-npm-packages-colors-faker/)) 
-   February 2022 ([25 malicious packages](https://thehackernews.com/2022/02/25-malicious-javascript-libraries.html)) 
-   March 2022 ([azure-sdk-v4 + azureazure](https://medium.com/checkmarx-security/webhook-party-malicious-packages-caught-exfiltrating-data-via-legit-webhook-services-6e046b07d191))  
-   March bonus: [Protestware](https://medium.com/checkmarx-security/protestware-politics-and-open-source-software-a29e2b4423fa) 
-   March bonus: [The Factory](https://medium.com/checkmarx-security/a-beautiful-factory-for-malicious-packages-8937bb57e524)

My point is: **that we all have to review and adapt how we work with dependencies taking into account supply chain security risks**. 

At this point, it's unsafe to ignore supply chain risks and there is nowhere to hide from them in the future.

I started following this problem from [the discussion at npm about making install scripts opt-in](https://github.com/npm/rfcs/pull/488). But install scripts are not the only threat, there are more ways for malicious actors:
1.  **Malicious code injection**: During the development process an attacker could replace URLs in a lock file or add malicious code (it is dangerous because it may be hard to catch in PR review).
2.  **Malicious package release**: An attacker may publish malicious packages and hence trick other users into installing or depending on such packages.
3.  **Social Engineering**: An attacker may manipulate a maintainer to hand over sensitive information.
4.  **Account Takeover**: An attacker may compromise the credentials of a maintainer to inject malicious code under the maintainer’s name.
5.  **Ownership transfer**: An attacker can show enthusiasm to maintain popular abandoned packages and transfer the ownership of a package.
6.  **Remote execution**: An attacker may target a package by compromising the third-party services used by that package.

There are a lot of [papers](https://arxiv.org/search/advanced?advanced=&terms-0-operator=AND&terms-0-term=supply+chain+security&terms-0-field=all&classification-computer_science=y&classification-physics_archives=all&classification-include_cross_list=include&date-filter_by=all_dates&date-year=&date-from_date=&date-to_date=&date-date_type=submitted_date&abstracts=show&size=100&order=-announced_date_first) about detecting and mitigating those risks. 

One specific paper ([What are Weak Links in the npm Supply Chain](https://arxiv.org/abs/2112.10165v2)) inspired me to create [sdc-check](https://github.com/mbalabash/sdc-check). 

As a big believer in the power of people collaboration, I am sure that the open-source community is our key to mitigating those supply chain risks and threats.

And it is happening right now. Github is opening the [GitHub Advisory Database](https://docs.github.com/en/code-security/supply-chain-security/managing-vulnerabilities-in-your-projects-dependencies/browsing-security-vulnerabilities-in-the-github-advisory-database) to community submissions. Awesome community [NodeSecure](https://github.com/NodeSecure) builds cool things like [scanner](https://github.com/NodeSecure/scanner) and [js-x-ray](https://github.com/NodeSecure/js-x-ray). There are also [lockfile-lint](https://github.com/lirantal/lockfile-lint), [LavaMoat](https://github.com/LavaMoat/LavaMoat), [Jfrog-npm-tools](https://portswigger.net/daily-swig/tool-trio-released-to-protect-javascript-applications-from-malicious-npm-packages) (and I am sure there is more).

**As an open-source maintainer**, you could take action:
-   make sure you are following [security best practices](https://sethmlarson.dev/blog/security-for-package-maintainers)

**As an open-source consumer**, you have to think about:
- what "extra" you could get with the next dependencies upgrade

Also, try to add additional safety step using a tool like [sdc-check](https://github.com/mbalabash/sdc-check) / [lockfile-lint](https://github.com/lirantal/lockfile-lint) / [scanner](https://github.com/NodeSecure/scanner) / etc.

>_thank you for attention 🙌_