From 0797ffb21f31cc178575ad8700b2bbd631487c23 Mon Sep 17 00:00:00 2001 From: Maxi Ferreira Date: Sat, 11 Oct 2025 10:13:01 -0700 Subject: [PATCH 1/5] Add Trusted publishing section --- cheatsheets/NPM_Security_Cheat_Sheet.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/cheatsheets/NPM_Security_Cheat_Sheet.md b/cheatsheets/NPM_Security_Cheat_Sheet.md index de4e1d6881..03929375cc 100644 --- a/cheatsheets/NPM_Security_Cheat_Sheet.md +++ b/cheatsheets/NPM_Security_Cheat_Sheet.md @@ -162,3 +162,19 @@ Closing our list of ten npm security best practices are the following tips to re - Be extra-careful when copy-pasting package installation instructions into the terminal. Make sure to verify in the source code repository as well as on the npm registry that this is indeed the package you are intending to install. You might verify the metadata of the package with `npm info` to fetch more information about contributors and latest versions. - Default to having an npm logged-out user in your daily work routines so your credentials won’t be the weak spot that would lead to easily compromising your account. - When installing packages, append the `--ignore-scripts` to reduce the risk of arbitrary command execution. For example: `npm install my-malicious-package --ignore-scripts` + +## 11) Use trusted publishers for secure package publishing + +Traditional npm publishing relies on long-lived tokens that can be compromised or accidentally exposed. Trusted publishing with OpenID Connect (OIDC) provides a more secure alternative by using short-lived, workflow-specific credentials that are automatically generated during CI/CD processes. Trusted publishing currently supports GitHub Actions and GitLab CI/CD Pipelines. + +### How trusted publishing works + +Trusted publishing creates a trust relationship between npm and your CI/CD provider using OIDC. When you configure a trusted publisher for your package, npm will accept publishes from the specific workflow you've authorized, in addition to traditional authentication methods like npm tokens and manual publishes. The npm CLI automatically detects OIDC environments and uses them for authentication before falling back to traditional tokens. + +This approach eliminates the security risks associated with long-lived write tokens, which can be compromised, accidentally exposed in logs, or require manual rotation. Instead, each publish uses short-lived, cryptographically-signed tokens that are specific to your workflow and cannot be extracted or reused. + +### Automatic provenance generation + +When publishing via trusted publishing, npm automatically generates provenance attestations that provide cryptographic proof of package authenticity. This helps users verify that packages come from legitimate sources and haven't been tampered with. + +For more information, see the [npm trusted publishing documentation](https://docs.npmjs.com/trusted-publishers). From 456af3341946bc2e76cb010e193eecd158d21b70 Mon Sep 17 00:00:00 2001 From: Maxi Ferreira Date: Sat, 11 Oct 2025 10:26:59 -0700 Subject: [PATCH 2/5] Typosquatting + slopsquatting --- cheatsheets/NPM_Security_Cheat_Sheet.md | 38 ++++++++++++++----------- 1 file changed, 22 insertions(+), 16 deletions(-) diff --git a/cheatsheets/NPM_Security_Cheat_Sheet.md b/cheatsheets/NPM_Security_Cheat_Sheet.md index 03929375cc..82e0642cfe 100644 --- a/cheatsheets/NPM_Security_Cheat_Sheet.md +++ b/cheatsheets/NPM_Security_Cheat_Sheet.md @@ -139,29 +139,27 @@ To verify which tokens are created for your user or to revoke tokens in cases of Ensure you are following this npm security best practice by protecting and minimizing the exposure of your npm tokens. -## 10) Understand module naming conventions and typosquatting attacks +## 10) Understanding typosquatting and slopsquatting attacks -Naming a module is the first thing you might do when creating a package, but before defining a final name, npm defines some rules that a package name must follow: +### Typosquatting attacks -- It is limited to 214 characters -- No uppercase letters in the name -- No trailing spaces -- Some special characters are not allowed: “~\’!()*” -- Can’t start with . or _ -- Can’t use node_modules or favicon.ico in the name -- Even if you follow these rules, be aware that npm uses a spam detection mechanism when publishing new packages, based on score and whether a package name violates the terms of the service. If conditions are violated, the registry might deny the request. +Typosquatting is an attack that relies on mistakes made by users, such as typos. With typosquatting, bad actors publish malicious modules to the npm registry with names that look much like existing popular modules. These malicious packages exploit common typing errors or visual similarities to trick developers into installing them instead of the legitimate packages they intended to use. -Typosquatting is an attack that relies on mistakes made by users, such as typos. With typosquatting, bad actors could publish malicious modules to the npm registry with names that look much like existing popular modules. +We have been tracking tens of malicious packages in the npm ecosystem; similar attacks have been seen on the PyPi Python registry as well. Some of the most notable incidents include [cross-env](https://snyk.io/vuln/npm:crossenv:20170802), [event-stream](https://snyk.io/vuln/SNYK-JS-EVENTSTREAM-72638), and [eslint-scope](https://snyk.io/vuln/npm:eslint-scope:20180712). -We have been tracking tens of malicious packages in the npm ecosystem; they have been seen on the PyPi Python registry as well. Perhaps some of the most popular incidents have been for [cross-env](https://snyk.io/vuln/npm:crossenv:20170802), [event-stream](https://snyk.io/vuln/SNYK-JS-EVENTSTREAM-72638), and [eslint-scope](https://snyk.io/vuln/npm:eslint-scope:20180712). +One of the main targets for typosquatting attacks are user credentials, since any package has access to environment variables via the global variable `process.env`. Other examples include the event-stream case, where attackers targeted developers in the hopes of [injecting malicious code](https://snyk.io/blog/a-post-mortem-of-the-malicious-event-stream-backdoor) into an application's source code. -One of the main targets for typosquatting attacks are the user credentials, since any package has access to environment variables via the global variable process.env. Other examples we’ve seen in the past include the case with event-stream, where the attack targeted developers in the hopes of [injecting malicious code](https://snyk.io/blog/a-post-mortem-of-the-malicious-event-stream-backdoor) into an application’s source code. +### Slopsquatting attacks -Closing our list of ten npm security best practices are the following tips to reduce the risk of such attacks: +Slopsquatting is a newer attack vector that exploits AI-powered coding assistants and Large Language Models (LLMs). When developers use AI tools to generate code or package recommendations, these models may occasionally "hallucinate" package names that don't actually exist. Attackers monitor these hallucinations and create malicious packages with those exact names, knowing that developers may blindly trust and install packages suggested by their AI assistants. -- Be extra-careful when copy-pasting package installation instructions into the terminal. Make sure to verify in the source code repository as well as on the npm registry that this is indeed the package you are intending to install. You might verify the metadata of the package with `npm info` to fetch more information about contributors and latest versions. -- Default to having an npm logged-out user in your daily work routines so your credentials won’t be the weak spot that would lead to easily compromising your account. -- When installing packages, append the `--ignore-scripts` to reduce the risk of arbitrary command execution. For example: `npm install my-malicious-package --ignore-scripts` +To protect against slopsquatting: + +- Always verify that packages suggested by AI tools actually exist and are legitimate +- Check the package's repository, download statistics, and maintainer information +- Cross-reference AI suggestions with official documentation +- Be skeptical of packages with very low download counts or recent creation dates +- Review the package source code before installing, especially for AI-suggested packages ## 11) Use trusted publishers for secure package publishing @@ -178,3 +176,11 @@ This approach eliminates the security risks associated with long-lived write tok When publishing via trusted publishing, npm automatically generates provenance attestations that provide cryptographic proof of package authenticity. This helps users verify that packages come from legitimate sources and haven't been tampered with. For more information, see the [npm trusted publishing documentation](https://docs.npmjs.com/trusted-publishers). + +## Final Recommendations + +Closing our list of npm security best practices are the following tips to reduce the risk of such attacks: + +- Be extra-careful when copy-pasting package installation instructions into the terminal. Make sure to verify in the source code repository as well as on the npm registry that this is indeed the package you are intending to install. You might verify the metadata of the package with `npm info` to fetch more information about contributors and latest versions. +- Default to having an npm logged-out user in your daily work routines so your credentials won’t be the weak spot that would lead to easily compromising your account. +- When installing packages, append the `--ignore-scripts` to reduce the risk of arbitrary command execution. For example: `npm install my-malicious-package --ignore-scripts` From be347c205a08c56a71ada1281ae87ca9afd58fa9 Mon Sep 17 00:00:00 2001 From: Maxi Ferreira Date: Tue, 14 Oct 2025 06:54:31 -0700 Subject: [PATCH 3/5] Add allowlist documentation --- cheatsheets/NPM_Security_Cheat_Sheet.md | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/cheatsheets/NPM_Security_Cheat_Sheet.md b/cheatsheets/NPM_Security_Cheat_Sheet.md index 82e0642cfe..35b7c7c9df 100644 --- a/cheatsheets/NPM_Security_Cheat_Sheet.md +++ b/cheatsheets/NPM_Security_Cheat_Sheet.md @@ -1,6 +1,6 @@ # NPM Security best practices -In the following npm cheatsheet, we’re going to focus on [10 npm security best practices](https://snyk.io/blog/ten-npm-security-best-practices) and productivity tips, useful for JavaScript and Node.js developers. +The following cheatsheet covers several NPM security best practices and productivity tips, useful for JavaScript and Node.js developers. This list was originally based on the [10 npm security best practices](https://snyk.io/blog/ten-npm-security-best-practices) from the Snyk blog. ## 1) Avoid publishing secrets to the npm registry @@ -46,6 +46,22 @@ Apply these npm security best practices in order to minimize the malicious modul - When installing packages make sure to add the `--ignore-scripts` suffix to disable the execution of any scripts by third-party packages. - Consider adding `ignore-scripts` to your `.npmrc` project file, or to your global npm configuration. +### Using an allowlist for lifecycle scripts + +Disabling lifecycle scripts by default by adding `ignore-script` to your `.npmrc` file is the safest option. If you use packages that rely on lifecycle scripts for legitimate reasons, you can use a plugin like [`@lavamoat/allow-scripts`](https://github.com/LavaMoat/LavaMoat/tree/main/packages/allow-scripts) to create an _allowlist_ of packages authorized to run lifecylce scripts. + +Here's how the allowlist would look like in the `package.json` file on a project using the popular image processing package [sharp](https://www.npmjs.com/package/sharp): + +```json +{ + "lavamoat": { + "allowScripts": { + "sharp": true + } + } +} +``` + ## 4) Assess npm project health ### npm outdated command @@ -70,7 +86,7 @@ Call the doctor! The npm CLI incorporates a health assessment tool to diagnose y The npm ecosystem is the single largest repository of application libraries amongst all the other language ecosystems. The registry and the libraries in it are at the core for JavaScript developers as they are able to leverage work that others have already built and incorporate it into their codebase. With that said, the increasing adoption of open source libraries in applications brings with it an increased risk of introducing security vulnerabilities. -Many popular npm packages have been found to be vulnerable and may carry a significant risk without proper security auditing of your project’s dependencies. Some examples are npm [request](https://snyk.io/vuln/npm:request:20160119), [superagent](https://snyk.io/vuln/search?q=superagent&type=npm), [mongoose](https://snyk.io/vuln/search?q=mongoose&type=npm), and even security-related packages like [jsonwebtoken](https://snyk.io/vuln/npm:jsonwebtoken:20150331), and [validator](https://snyk.io/vuln/search?q=validator&type=npm). +Many popular npm packages have been found to be vulnerable and may carry a significant risk without proper security auditing of your project’s dependencies. Some examples are npm [request](https://snyk.io/vuln/npm:request:20160119), [superagent](https://snyk.io/vuln/search?q=superagent&type=npm), [mongoose](https://snyk.io/vuln/search?q=mongoose&type=npm), and even security-related packages like [jsonwebtoken](https://snyk.io/vuln/npm:jsonwebtoken:20150331), and [validator](https://snyk.io/vuln/search?q=validator&type=npm). Security doesn’t end by just scanning for security vulnerabilities when installing a package but should also be streamlined with developer workflows to be effectively adopted throughout the entire lifecycle of software development, and monitored continuously when code is deployed: @@ -129,7 +145,7 @@ Follow the command-line instructions to enable 2FA, and to save emergency authen Every time you log in with the npm CLI, a token is generated for your user and authenticates you to the npm registry. Tokens make it easy to perform npm registry-related actions during CI and automated procedures, such as accessing private modules on the registry or publishing new versions from a build step. -Tokens can be managed through the npm registry website, as well as using the npm command-line client. An example of using the CLI to create a read-only token that is restricted to a specific IPv4 address range is as follows: +Tokens can be managed through the npm registry website, as well as using the npm command-line client. An example of using the CLI to create a read-only token that is restricted to a specific IPv4 address range is as follows: ```sh npm token create --read-only --cidr=192.0.2.0/24 From 4e870c6a624a7093097ef40745ebc3d24d1a2b7a Mon Sep 17 00:00:00 2001 From: Maxi Ferreira Date: Fri, 17 Oct 2025 06:40:43 -0700 Subject: [PATCH 4/5] Update case --- cheatsheets/NPM_Security_Cheat_Sheet.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cheatsheets/NPM_Security_Cheat_Sheet.md b/cheatsheets/NPM_Security_Cheat_Sheet.md index 35b7c7c9df..8fc5bf3609 100644 --- a/cheatsheets/NPM_Security_Cheat_Sheet.md +++ b/cheatsheets/NPM_Security_Cheat_Sheet.md @@ -1,6 +1,6 @@ # NPM Security best practices -The following cheatsheet covers several NPM security best practices and productivity tips, useful for JavaScript and Node.js developers. This list was originally based on the [10 npm security best practices](https://snyk.io/blog/ten-npm-security-best-practices) from the Snyk blog. +The following cheatsheet covers several npm security best practices and productivity tips, useful for JavaScript and Node.js developers. This list was originally based on the [10 npm security best practices](https://snyk.io/blog/ten-npm-security-best-practices) from the Snyk blog. ## 1) Avoid publishing secrets to the npm registry From 8019b1f4f71e3b7197f5c0d0b6dd655217dd4206 Mon Sep 17 00:00:00 2001 From: Maxi Ferreira Date: Mon, 20 Oct 2025 15:21:55 -0700 Subject: [PATCH 5/5] Update paragraph to the third-person --- cheatsheets/NPM_Security_Cheat_Sheet.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cheatsheets/NPM_Security_Cheat_Sheet.md b/cheatsheets/NPM_Security_Cheat_Sheet.md index 8fc5bf3609..bb02585125 100644 --- a/cheatsheets/NPM_Security_Cheat_Sheet.md +++ b/cheatsheets/NPM_Security_Cheat_Sheet.md @@ -161,7 +161,7 @@ Ensure you are following this npm security best practice by protecting and minim Typosquatting is an attack that relies on mistakes made by users, such as typos. With typosquatting, bad actors publish malicious modules to the npm registry with names that look much like existing popular modules. These malicious packages exploit common typing errors or visual similarities to trick developers into installing them instead of the legitimate packages they intended to use. -We have been tracking tens of malicious packages in the npm ecosystem; similar attacks have been seen on the PyPi Python registry as well. Some of the most notable incidents include [cross-env](https://snyk.io/vuln/npm:crossenv:20170802), [event-stream](https://snyk.io/vuln/SNYK-JS-EVENTSTREAM-72638), and [eslint-scope](https://snyk.io/vuln/npm:eslint-scope:20180712). +The Snyk security team has tracked tens of malicious packages in the npm ecosystem that used typosquatting to trick users into installing them; similar attacks have been observed on the PyPi Python registry as well. Some of the most notable incidents include [cross-env](https://snyk.io/vuln/npm:crossenv:20170802), [event-stream](https://snyk.io/vuln/SNYK-JS-EVENTSTREAM-72638), and [eslint-scope](https://snyk.io/vuln/npm:eslint-scope:20180712). One of the main targets for typosquatting attacks are user credentials, since any package has access to environment variables via the global variable `process.env`. Other examples include the event-stream case, where attackers targeted developers in the hopes of [injecting malicious code](https://snyk.io/blog/a-post-mortem-of-the-malicious-event-stream-backdoor) into an application's source code.