NPM Anomalous Dependency
ID |
anomaly_npm |
Severity |
low |
Family |
Anomalous Dependency |
Description
A malicious dependency often shows certain patterns that could be used to heuristically warn of potential misbehaviour.
Project metadata, like lack of license or README data, author without a valid email, no project homepage, or no project repository, could raise suspicions on the intentions of the package.
Security
When some of these hints are found for a new package in the dependencies graph for your project, this could raise suspicions demanding a careful review of the target package.
Packages with installation scripts registered (for pre-install
, install
or post-install
events) may be malware trying to install a trojan, run crypto-miners, exfiltrate sensitive data, etc.
Examples
A package with not allowed installation scripts, with a source repository not containing the same software as the contents of the package in the NPM registry, and with not enough metadata giving information about the author of the package may suggest that the package cannot be trusted without further analysis.
Mitigation / Fix
Put packages reported by this rule in 'quarantine', and proceed to review them:
-
Are the installation scripts potentially malicious?
-
Is the author a well-known developer, with a good reputation in the industry?
-
Are there any related NPM security advisories?
Malicious packages are often quickly detected and removed from NPM, so suspicious packages could be quarantined for some days before considering the target package safe.
You may then 'mute' the misconfiguration so this rule will not report for the package in following analyses.