Uses debug, reflection and dynamic code execution features.

Removing the use of debug will reduce the risk of any reflection and dynamic code execution.

Dynamic require can indicate the package is performing dangerous or unsafe dynamic code execution.

Packages should avoid dynamic imports when possible. Audit the use of dynamic require to ensure it is not executing malicious or vulnerable code.

Package accesses environment variables, which may be a sign of credential stuffing or data theft.

Packages should be clear about which environment variables they access, and care should be taken to ensure they only access environment variables they claim to.

Contains high entropy strings. This could be a sign of encrypted data, leaked secrets or obfuscated code.

Please inspect these strings to check if these strings are benign. Maintainers should clarify the purpose and existence of high entropy strings if there is a legitimate purpose.

Accesses the file system, and could potentially read sensitive data.

If a package must read the file system, clarify what it will read and ensure it reads only what it claims to. If appropriate, packages can leave file system access to consumers and operate on data passed to it instead.

(Experimental) Package contains a modified version of an SPDX license. Please read carefully before using this code.

Packages should avoid making modifications to standard licenses.

(Experimental) Package has a non-OSI-approved license.

Consider the terms of the license for your given use case.

Package has recently undergone a major refactor. It may be unstable or indicate significant internal changes. Use caution when updating to versions that include significant changes.

Consider waiting before upgrading to see if any issues are discovered, or be prepared to scrutinize any bugs or subtle changes the major refactor may bring. Publishers my consider publishing beta versions of major refactors to limit disruption to parties interested in the new changes.

(Experimental) Package contains multiple licenses.

A new version of the package should be published that includes a single license. Consumers may seek clarification from the package author. Ensure that the license details are consistent across the LICENSE file, package.json license field and license details mentioned in the README.

Package is not semver >=1. This means it is not stable and does not support ^ ranges.

If the package sees any general use, it should begin releasing at version 1.0.0 or later to benefit from semver.

Package has not been updated in more than a year and may be unmaintained. Problems with the package may go unaddressed.

Package should publish periodic maintenance releases if they are maintained, or deprecate if they have no intention in further maintenance.

A new npm collaborator published a version of the package for the first time. New collaborators are usually benign additions to a project, but do indicate a change to the security surface area of a package.

Scrutinize new collaborator additions to packages because they now have the ability to publish code into your dependency tree. Packages should avoid frequent or unnecessary additions or changes to publishing rights.

A new collaborator has begun publishing package versions. Package stability and security risk may be elevated.

Try to reduce the amount of authors you depend on to reduce the risk to malicious actors gaining access to your supply chain. Packages should remove inactive collaborators with publishing rights from packages on npm.

This module accesses the system shell. Accessing the system shell increases the risk of executing arbitrary code.

Packages should avoid accessing the shell which can reduce portability, and make it easier for malicious shell access to be introduced.

Package version was not found on the registry. It may exist on a different registry and need to be configured to pull from that registry.

Packages can be removed from the registry by manually un-publishing, a security issue removal, or may simply never have been published to the registry. Reliance on these packages will cause problem when they are not found.

Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev.

If you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency.

To ignore an alert, reply with a comment starting with @SocketSecurity ignore followed by a space separated list of package-name@version specifiers. e.g. @SocketSecurity ignore foo@1.0.0 bar@* or ignore all packages with @SocketSecurity ignore-all

• @SocketSecurity ignore @pkgjs/parseargs@0.11.0
• @SocketSecurity ignore eastasianwidth@0.2.0
• @SocketSecurity ignore meow@13.0.0
• @SocketSecurity ignore rimraf@5.0.5
• @SocketSecurity ignore minimatch@9.0.3
• @SocketSecurity ignore jackspeak@2.3.6
• @SocketSecurity ignore write-file-atomic@5.0.1
• @SocketSecurity ignore @csstools/selector-specificity@3.0.1
• @SocketSecurity ignore css-tree@2.3.1
• @SocketSecurity ignore foreground-child@3.1.1
• @SocketSecurity ignore lru-cache@10.1.0
• @SocketSecurity ignore @csstools/css-parser-algorithms@2.4.0
• @SocketSecurity ignore minipass@7.0.4
• @SocketSecurity ignore @csstools/css-tokenizer@2.2.2
• @SocketSecurity ignore @csstools/media-query-list-parser@2.1.6
• @SocketSecurity ignore path-scurry@1.10.1
• @SocketSecurity ignore stylelint@16.1.0