Small tool to inform you about potential risks in your project dependencies list:
-
Lock file is not safe (
lockfile-is-not-safe). During the development process a malicious actor could replace URLs in a lock file to package with malicious code (it is especially dangerous because it is hard to catch in PR review) -
The newest package version is too new (
package-is-too-new). A new version of a package could be vulnerable. It might be safer to wait X days before upgrading to the new version and let community test it -
Installation Script (
install-scripts). An attacker can use installation scripts to run commands that perform malicious acts through the package installation step -
Obfuscated code (
obfuscated-code). A package contains obfuscated code which may point to attempt of hiding potentially malicious code -
A package has OS scripts (
has-os-scripts). An attacker can use .bat/.sh scripts to execute malicious actions (downloading and launching mining apps, etc) -
A package script has shell commands (
dangerous-shell-commands). Package script could have potentially dangerous commands to perform malicious actions (curl, wget, chmod, cacls, etc) -
The newest package version is released after a long period of inactivity (
released-after-long-period-of-inactivity). There is a possibility that an attacker could hijack an account and publish malicious code -
Unmaintained Package (
unmaintained-package). A package has no updates for at least one year -
Too many decision makers (
too-many-decision-makers). A package with too many maintainers/publishers will provide an attacker many targets to exploit account takeover and social engineering attacks -
No source code repository (
no-source-code). When a package has no source code repository/homepage the access to review source code is restricted, forcing users to trust a package blindly
Add new npm command to script section in your package.json
"scripts": {
"sdc-check": "sdc-check -d .",
}Add new step to your pipeline
# Github Actions example:
- name: Check dependencies with sdc-check
run: yarn sdc-checkAdd new "sdc-check" section in your package.json to change defaults
- options define metrics behaviour
- errors define set of metrics when audit should fail if those metrics won't pass
"sdc-check": {
"options": {
"limitOfDecisionMakers": 7,
"daysBeforeUpgradeToNewVersion": 5,
"monthsOfInactivityAllowed": 10
},
"errors": [
"package-is-too-new",
"lockfile-is-not-safe",
"has-os-scripts",
"dangerous-shell-commands"
]
}Add .sdccheckignore to your project root directory
# Ignore errors caused by unmaintained-package metric for [email protected]
[email protected] | unmaintained-package
# Ignore all errors for [email protected]
[email protected]
# Ignore errors caused by unmaintained-package and
# released-after-long-period-of-inactivity metrics for sdc-check
sdc-check | unmaintained-package, released-after-long-period-of-inactivity
# Ignore all errors for sdc-check
sdc-checkFind out more about a package before adding it to your dependencies list
npx sdc-check -p ua-parser-js -v 1.0.2Use npm diff command to find out
npm diff [email protected] [email protected]-
Malicious code injection: During the development process an attacker could add malicious code to a package codebase (it is dangerous because it may be hard to catch in PR review).
-
Malicious package release: An attacker may publish malicious packages and hence trick other users into installing or depending on such packages.
-
Social Engineering: An attacker may manipulate a maintainer to hand over sensitive information.
-
Account Takeover: An attacker may compromise the credentials of a maintainer to inject malicious code under the maintainer’s name.
-
Ownership transfer: An attacker can show enthusiasm to maintain popular abandoned packages and transfer the ownership of a package.
-
Remote execution: An attacker may target a package by compromising the third-party services used by that package.
npm i -D sdc-checkor
yarn add -D sdc-checkMIT