sandworm-hq / sandworm-audit Goto Github PK

Sandworm version
1.27.0

Describe the bug
I'm receiving the following error on the first try of any project on any node version (12, 14, 18).

TypeError: Cannot convert undefined or null to object
    at Function.entries (<anonymous>)
    at generateNpmGraph (/home/ktorok/.nvm/versions/node/v14.21.3/lib/node_modules/@sandworm/audit/src/graph/generateNpmGraph.js:14:10)
    at generateGraphPromise (/home/ktorok/.nvm/versions/node/v14.21.3/lib/node_modules/@sandworm/audit/src/graph/index.js:17:19)
    at async getReport (/home/ktorok/.nvm/versions/node/v14.21.3/lib/node_modules/@sandworm/audit/src/index.js:41:25)
    at async Object.handler (/home/ktorok/.nvm/versions/node/v14.21.3/lib/node_modules/@sandworm/audit/src/cli/index.js:36:7)

To Reproduce
Run sandworm-audit

Expected behavior
Give me any output without error.

Node (please complete the following information):

• Version 12, 14, 18
• OS: Garuda Linux

I tried to run it on my production project, but sandworm just stuck on Getting vulnerability report from pnpm stage for some reason 🤔

Originally posted by @acherkashin in #101 (reply in thread)

Sandworm version
1.26.0

Describe the bug

<--- Last few GCs --->

[52485:0x130008000]   348912 ms: Mark-Compact 8016.7 (8230.0) -> 8003.9 (8233.0) MB, 7949.1 / 0.0 ms  (average mu = 0.104, current mu = 0.012) allocation failure; scavenge might not succeed
[52485:0x130008000]   357184 ms: Mark-Compact 8019.8 (8233.0) -> 8007.1 (8236.5) MB, 8194.0 / 0.0 ms  (average mu = 0.057, current mu = 0.009) allocation failure; scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

To Reproduce
package.json

{
    "dependencies": {
        "@juggle/resize-observer": "^3.4.0",
        "@svgr/webpack": "^6.5.1",
        "axios": "^0.27.2",
        "axios-hooks": "^3.1.5",
        "dotenv": "^16.0.2",
        "formik": "^2.2.9",
        "gatsby": "^4.24.0-next.3",
        "gatsby-plugin-feed": "^4.23.0",
        "gatsby-plugin-gdpr-cookies": "^2.0.9",
        "gatsby-plugin-google-tagmanager": "^4.23.0",
        "gatsby-plugin-manifest": "^4.23.0",
        "gatsby-plugin-robots-txt": "^1.7.1",
        "gatsby-plugin-sass": "^5.23.0",
        "gatsby-plugin-schema-snapshot": "^4.6.0",
        "gatsby-plugin-sitemap": "^5.23.0",
        "gatsby-plugin-svgr": "^3.0.0-beta.0",
        "gatsby-plugin-use-query-params": "^1.0.1",
        "gatsby-source-strapi": "^2.0.0",
        "i18next": "^22.4.10",
        "i18next-http-backend": "^2.1.1",
        "jwt-decode": "^3.1.2",
        "qs": "^6.11.0",
        "react": "^18.2.0",
        "react-cookie-consent": "^8.0.1",
        "react-countup": "^6.3.1",
        "react-dom": "^18.2.0",
        "react-helmet": "^6.1.0",
        "react-i18next": "^12.1.4",
        "react-markdown": "^8.0.3",
        "react-redux": "^8.0.2",
        "react-responsive": "^9.0.0-beta.10",
        "react-scroll": "^1.8.7",
        "react-select": "^5.4.0",
        "react-slick": "^0.29.0",
        "react-syntax-highlighter": "^15.5.0",
        "react-tabs": "^5.1.0",
        "react-toastify": "^9.1.1",
        "react-visibility-sensor": "^5.1.1",
        "redux": "^4.2.0",
        "rehype-raw": "^6.1.1",
        "slick-carousel": "^1.8.1",
        "spinners-react": "^1.0.7",
        "use-query-params": "^1.2.3",
        "yup": "^0.32.11"
    },
    "devDependencies": {
        "@types/fs-extra": "^11.0.1",
        "@types/lodash.debounce": "^4.0.7",
        "@types/qs": "^6.9.7",
        "@types/react": "^18.0.20",
        "@types/react-dom": "^18.0.6",
        "@types/react-helmet": "^6.1.5",
        "@types/react-redux": "^7.1.24",
        "@types/react-scroll": "^1.8.4",
        "@types/react-slick": "^0.23.10",
        "@types/react-syntax-highlighter": "^15.5.6",
        "@typescript-eslint/eslint-plugin": "^5.50.0",
        "@typescript-eslint/parser": "^5.50.0",
        "eslint": "^8.33.0",
        "eslint-config-prettier": "^8.6.0",
        "eslint-plugin-prettier": "^4.2.1",
        "eslint-plugin-react": "^7.32.2",
        "eslint-plugin-simple-import-sort": "^10.0.0",
        "prettier": "^2.8.3",
        "typescript": "^4.9.5"
    }
}

Expected behavior
I think this library should never take so much ram. Of course, after the transition from 8gb to 16gb, the build went through, but I imagine that with a larger package.json the problem will be much bigger.

export NODE_OPTIONS="--max-old-space-size=16384"

Node (please complete the following information):

• Version 18.12.1 and 19.7.0
• OS: macOS Ventura 13.2.1

Red is currently used to highlight packages with vulnerabilities of any severity.
Let's switch to using a palette with shades for various severities (low, moderate, high, critical).
This will make charts easier to grok.

Hi, sandworm-audit looks really good audit tool for javascript project!
I have a question about license policy.
How can you categorize the license type(https://github.com/sandworm-hq/sandworm-audit/blob/main/src/issues/licenses.json)?
Is it classified by Sandworm? Or did you refer to other documents?

Sandworm version
Can't get, running sandworm-audit -v starts building dependency graph again. Just installed it today.

Describe the bug
Building dependency graph... never finishes, even after 10-15 minutes. No excessive CPU/RAM usage. Tried running with --from disk same.

I'm running it in an environment with proxy and we use a custom npm registry mirror to not get blacklisted by npm for excessive amount of requests. All the settings are in the npm config.

To Reproduce
Just installed it and ran sandworm-audit

Expected behavior
A message of why it's taking so long would be nice, or a check for a race condition if it's a network call that is never resolved or something like that.

System (please complete the following information):

• Node Version v18.13.0
• Package Manager npm
• Package Manager Version 9.2.0
• OS: Windows 10

Additional context
Add any other context about the problem here.

Implementing the new Sandworm chart API in v1.2.0 also added a regression with representing dev dependencies. To replicate, try using the --dev option.

Other dependency types (optional, peer, and bundled) are also available in the graph output but aren't currently displayed in charts.

Add license information, when available, to the package tooltip.

Sandworm version
latest (ran as 'npx' command)

Describe the bug
When running npx @sandworm/audit I receive the following error

Error: Cannot find module '@pnpm/crypto.base32-hash'
Require stack:

• /my/user/.npm/_npx/51438d1c8ff7d360/node_modules/dependency-path/lib/index.js
• /my/user/.npm/_npx/51438d1c8ff7d360/node_modules/@sandworm/utils/node_modules/@pnpm/lockfile-file/lib/write.js
• /my/user/.npm/_npx/51438d1c8ff7d360/node_modules/@sandworm/utils/node_modules/@pnpm/lockfile-file/lib/index.js
• /my/user/.npm/_npx/51438d1c8ff7d360/node_modules/@sandworm/utils/src/files/lockfiles.js
• /my/user/.npm/_npx/51438d1c8ff7d360/node_modules/@sandworm/utils/src/files/index.js
• /my/user/.npm/_npx/51438d1c8ff7d360/node_modules/@sandworm/utils/src/index.js
• /my/user/.npm/_npx/51438d1c8ff7d360/node_modules/@sandworm/audit/src/cli/index.js
  at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
  at Function.Module._load (node:internal/modules/cjs/loader:778:27)
  at Module.require (node:internal/modules/cjs/loader:1005:19)
  at require (node:internal/modules/cjs/helpers:102:18)
  at Object. (/my/user/.npm/_npx/51438d1c8ff7d360/node_modules/dependency-path/lib/index.js:7:30)
  at Module._compile (node:internal/modules/cjs/loader:1105:14)
  at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
  at Module.load (node:internal/modules/cjs/loader:981:32)
  at Function.Module._load (node:internal/modules/cjs/loader:822:12)
  at Module.require (node:internal/modules/cjs/loader:1005:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
  '/my/user/.npm/_npx/51438d1c8ff7d360/node_modules/dependency-path/lib/index.js',
  '/my/user/.npm/_npx/51438d1c8ff7d360/node_modules/@sandworm/utils/node_modules/@pnpm/lockfile-file/lib/write.js',
  '/my/user/.npm/_npx/51438d1c8ff7d360/node_modules/@sandworm/utils/node_modules/@pnpm/lockfile-file/lib/index.js',
  '/my/user/.npm/_npx/51438d1c8ff7d360/node_modules/@sandworm/utils/src/files/lockfiles.js',
  '/my/user/.npm/_npx/51438d1c8ff7d360/node_modules/@sandworm/utils/src/files/index.js',
  '/my/user/.npm/_npx/51438d1c8ff7d360/node_modules/@sandworm/utils/src/index.js',
  '/my/user/.npm/_npx/51438d1c8ff7d360/node_modules/@sandworm/audit/src/cli/index.js'
  ]
  }

To Reproduce
Run npx @sandworm/audit against a local repository

Expected behavior
To receive the expected output

Node (please complete the following information):

• Version [e.g. 14.17.3]: 16.16.0
• OS: Mac OS Monterey 12.6.3

Browser (please complete the following information):

• Device: MacBook Pro
• OS: Mac OS Monterey 12.6.3
• Browser: Chrome(?)
• Version: 110.0.5481.177 (Official Build) (x86_64)

Notice the fracture in the vulnerability path below:

• @pnpm/lockfile-file has a dependency on @zkochan/js-yaml, so the latest version (0.0.6) is installed. This dependency is aliased as js-yaml.
• When running yarn audit the alias is ignored by Yarn, and we get back vulnerabilites for [email protected] instead. That specific package version is not actually installed.
• We do, however, have [email protected] installed as a dependency for @yarnpkg/parsers. That node gets wrongly labeled as a vulnerability, and looks disconnected from his path.
• Reproduce by running yarn audit in this repo's root.

Dependency graph generation can take a while for many dependencies, as we pull data on each dependency from the registry. We should display some progress indicator.

See #89

Sandworm version
1.53.1

Describe the bug

sandworm audit
Sandworm 🪱
Security and License Compliance Audit
- Building dependency graph...Exception in PromiseRejectCallback:
c:\AppData\Roaming\npm\node_modules\@sandworm\audit\src\files\workspace.js:61
  return null;

RangeError: Maximum call stack size exceeded


❌ Failed: Maximum call stack size exceeded
RangeError: Maximum call stack size exceeded
    at Object.existsSync (node:fs:303:20)
    at loadWorkspace (c:\AppData\Roaming\npm\node_modules\@sandworm\audit\src\files\workspace.js:14:10)
    at loadWorkspace (c:\AppData\Roaming\npm\node_modules\@sandworm\audit\src\files\workspace.js:58:12)
    at loadWorkspace (c:\AppData\Roaming\npm\node_modules\@sandworm\audit\src\files\workspace.js:58:12)
    at loadWorkspace (c:\AppData\Roaming\npm\node_modules\@sandworm\audit\src\files\workspace.js:58:12)
    at loadWorkspace (c:\AppData\Roaming\npm\node_modules\@sandworm\audit\src\files\workspace.js:58:12)
    at loadWorkspace (c:\AppData\Roaming\npm\node_modules\@sandworm\audit\src\files\workspace.js:58:12)
    at loadWorkspace (c:\AppData\Roaming\npm\node_modules\@sandworm\audit\src\files\workspace.js:58:12)
    at loadWorkspace (c:\AppData\Roaming\npm\node_modules\@sandworm\audit\src\files\workspace.js:58:12)
    at loadWorkspace (c:\AppData\Roaming\npm\node_modules\@sandworm\audit\src\files\workspace.js:58:12)

? Send crash report to Sandworm? » - Use arrow-keys. Return to submit.
>   Send with dependency info
    Send without dependency info
    Don't send
| Building dependency graph...

Manifest files
Whenever possible, please provide your package.json manifest file content (or at least a list of all the dependencies within), as well as your lockfile.

To Reproduce
Steps to reproduce the behavior.

Expected behavior
A clear and concise description of what you expected to happen.

System (please complete the following information):
npm --version
10.1.0

node --version
v18.17.1

Windows

• Node Version [e.g. 14.17.3]
• Package Manager [e.g. npm]
• Package Manager Version [e.g. 8.5.5]
• OS: [e.g. Ubuntu 22.04]

Additional context
Add any other context about the problem here.

Sandworm version
1.38.1

Describe the bug
Can't disable license checking, I need only check for vulnerabilities.

To Reproduce
Just run the CLI command with the defaults parameters

Expected behavior
Something like this:
sandworm --license-policy '{"enable": false}'

System (please complete the following information):

• Node Version v18.15.0
• Package Manager npm
• Package Manager Version 9.5.0
• OS: Fedora 38

Additional context
For my use case, I only need to check for vulnerabilities and need a clean log, without license info.
This is my configuration file:

{
  "audit": {
    "includeDev": true,
    "showVersions": true,
    "maxDepth": 10,
    "minDisplayedSeverity": "moderate",
    "licensePolicy": {
      "categories": [
        {
          "name": "Permissive",
          "licenses": ["*"]
        }
      ],
      "low": ["cat:Uncategorized", "cat:Weakly Protective", "cat:Network Protective", "cat:Strongly Protective"],
    },
    "loadDataFrom": "registry",
    "outputPath": "/tmp/sandworm",
    "skipAll": true,
    "failOn": ["*.critical", "*.high"]
  }
}

Thanks for any help you can provide!

local install into project appears to work

lsb_release -rd
	Description:    Fedora release 37 (Thirty Seven)
	Release:        37

yarn -v
	3.5.0
node -v
	v18.15.0
npm -v
	9.5.0
npx -v
	9.5.0

yarn global add @sandworm/audit
	Usage Error: The 'yarn global' commands have been removed in 2.x - consider using 'yarn dlx' or a third-party plugin instead
	$ yarn run [--inspect] [--inspect-brk] [-T,--top-level] [-B,--binaries-only] <scriptName> ...

yarn dlx @sandworm/audit@latest
	➤ YN0000: ┌ Resolution step
	➤ YN0061: │ w3c-hr-time@npm:1.0.2 is deprecated: Use your platform's native performance.now() and performance.timeOrigin.
	➤ YN0000: └ Completed in 3s 595ms
	➤ YN0000: ┌ Fetch step
	➤ YN0000: └ Completed
	➤ YN0000: ┌ Link step
	➤ YN0000: │ ESM support for PnP uses the experimental loader API and is therefore experimental
	➤ YN0000: └ Completed
	➤ YN0000: Done with warnings in 3s 806ms

	Internal Error: Binary not found (audit) for root-workspace-0b6124@workspace:.
	    at h7 (/var/lib/wwwrun/.cache/node/corepack/yarn/3.5.0/yarn.js:423:1806)
	    at Object.mRe (/var/lib/wwwrun/.cache/node/corepack/yarn/3.5.0/yarn.js:423:2322)
	    at /var/lib/wwwrun/.cache/node/corepack/yarn/3.5.0/yarn.js:601:297
	    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
	    at async $t.mktempPromise (/var/lib/wwwrun/.cache/node/corepack/yarn/3.5.0/yarn.js:314:69429)
	    at async Lu.execute (/var/lib/wwwrun/.cache/node/corepack/yarn/3.5.0/yarn.js:597:62990)
	    at async Lu.validateAndExecute (/var/lib/wwwrun/.cache/node/corepack/yarn/3.5.0/yarn.js:345:664)
	    at async Un.run (/var/lib/wwwrun/.cache/node/corepack/yarn/3.5.0/yarn.js:359:2057)
	    at async Un.runExit (/var/lib/wwwrun/.cache/node/corepack/yarn/3.5.0/yarn.js:359:2241)
	    at async i (/var/lib/wwwrun/.cache/node/corepack/yarn/3.5.0/yarn.js:446:12054)

yarn add @sandworm/audit@latest
	➤ YN0000: ┌ Resolution step
	➤ YN0000: │ Some peer dependencies are incorrectly met; run yarn explain peer-requirements <hash> for details, where <hash> is the six-letter p-prefixed code
	➤ YN0000: └ Completed in 3s 567ms
	➤ YN0000: ┌ Fetch step
	➤ YN0013: │ write-file-atomic@npm:4.0.2 can't be found in the cache and will be fetched from the remote regis
	➤ YN0013: │ xml-name-validator@npm:3.0.0 can't be found in the cache and will be fetched from the remote regi
	➤ YN0013: │ xmlchars@npm:2.2.0 can't be found in the cache and will be fetched from the remote registry
	➤ YN0013: │ yargs-parser@npm:21.1.1 can't be found in the cache and will be fetched from the remote registry
	➤ YN0013: │ yargs@npm:17.6.0 can't be found in the cache and will be fetched from the remote registry
	➤ YN0000: └ Completed in 0s 430ms
	➤ YN0000: ┌ Link step
	➤ YN0000: │ ESM support for PnP uses the experimental loader API and is therefore experimental
	➤ YN0008: │ sharp@npm:0.32.0 must be rebuilt because its dependency tree changed
	➤ YN0000: └ Completed in 0s 744ms
	➤ YN0000: Done with warnings in 4s 886ms

yarn info --name-only @sandworm/audit
	└─ @sandworm/audit@npm:1.35.0

yarn sandworm -d --sv
	Sandworm 🪱Security and License Compliance Audit
	√ Built dependency graph
	//
	// 💡 Save issue resolution info to your repo
	//    resolved-issues.json
	//    https://docs.sandworm.dev/audit/resolving-issues
	//
	√ Got vulnerabilities
	√ Scanned licenses
	√ Scanned issues
	√ Tree chart done
	√ Treemap chart done
	√ CSV done
	√ Report written to disk

	⚠ Identified 2 high severity, 1 low severity issues
	🟠 [email protected] Atypical license SWRM-104-caniuse-lite-1.0.30001431
	🟠 [email protected] Uses postinstall script SWRM-201-esbuild-0.15.14-postinstall
	⚪ [email protected] License not OSI approved SWRM-102-caniuse-lite-1.0.30001431

	✨ Done

Dev/peer/optional/bundled dependencies should be visually rendered differently, so they can be easily identified at a glance.

Currently, only the --version option of the cli displays the current Sandworm version. -v should do the same.

Add a configuration option to allow users to disable outputting report files. This is potentially useful when running in the CI.

Sandworm version

➜ sandworm-audit -v
1.36.0

Describe the bug

sandworm audit fails because of type error, but cannot find more information about it

➜ sandworm-audit
Sandworm 🪱
Security and License Compliance Audit
✔ Built dependency graph
✔ Got vulnerabilities
✔ Scanned licenses
✔ Scanned issues
✔ Tree chart done
✔ Treemap chart done
✔ CSV done
✔ Report written to disk

✅ Zero issues identified

✨ Done, but with errors:
❌ TypeError: Cannot read properties of undefined (reading 'includes')
❌ Failing because of errors

Manifest files

I don't feel comfortable sharing them here but happy to provide by email ?

To Reproduce
install sandworm, mac m1, ventura 13.2.1, we use yarn and node 16
run sandworm

Expected behavior

I expect it to work 🤔 ?

System (please complete the following information):

• Node Version [e.g. 14.17.3] 16.19.0
• Package Manager [e.g. npm] yarn 3.2.3
• Package Manager Version [e.g. 8.5.5]
• OS: [e.g. Ubuntu 22.04] mac os 13.2.1

Additional context

Sandworm version
v1.36.0

Describe the bug
Error report in terminal (git bash under Windows 10)

$ sandworm-audit
Sandworm 🪱
Security and License Compliance Audit
- Building dependency graph...

//
// 💡 Mark issues as resolved with Sandworm
//    sandworm resolve ISSUE-ID
//    https://docs.sandworm.dev/audit/resolving-issues
//
C:\Users\xxx\AppData\Roaming\nvm\v16.19.1\node_modules\@sandworm\audit\src\cli\progress.js:63
              process.stdout.moveCursor(0, -6);
                             ^

TypeError: process.stdout.moveCursor is not a function
    at Timeout._onTimeout (C:\Users\xxx\AppData\Roaming\nvm\v16.19.1\node_modules\@sandworm\audit\src\cli\progress.js:63:30)
    at listOnTimeout (node:internal/timers:559:17)
    at processTimers (node:internal/timers:502:7)

Manifest files
Whenever possible, please provide your package.json manifest file content (or at least a list of all the dependencies within), as well as your lockfile.

To Reproduce
In terminal (git bash under Windows 10):

1. Install sandworm with npm i -g @sandworm/audit
2. Navigate to arbitrary project that qualifies requirements
3. Run sandworm-audit

Expected behavior
Task completed without termination at building dependency graph phase.

System (please complete the following information):

• Node Version 16.19.1
• Package Manager npm
• Package Manager Version 8.19.3
• OS: Windows 10

Node and npm are under nvm management.

Additional context
This was the first run right after fresh installation of the package.

Let's generate a unique ID for every non-vulnerability issue Sandworm detects internally.
We can have it be a hash of:

• The issue category
• A unique numeric code we can assign to each issue type
• The affected package name and version

Create a configuration option that allows users to specify the type of issues that should cause the CLI to fail. This is useful when running in a CI or in a Git hook.

E.g.

{
   audit: {
      failOn: ['*.critical', 'license.high'],
   }
}

See #93

Currently, when retrieving info from the registry, packages get statically assigned to one of the 10 threads doing the work beforehand. This means that users always end up waiting for the slowest thread.

Sandworm version
1.29.1

Describe the bug
Does sandworm-audit supports pnpm monorepos?

In the root of my repository there are 2 files:

• pnpm-lock.yaml
• pnpm-workspace.yaml

There is no package.json in the same folder with pnpm-lock.yaml. At the same time, every package of monorepo has a package.json.

When I try to run sandworm-audit in the root of the repository, I get the following error.

TypeError: Cannot read properties of undefined (reading 'name')
    at generatePnpmGraph (/Users/cherkalexander/.nvm/versions/node/v16.15.1/lib/node_modules/@sandworm/audit/src/graph/generatePnpmGraph.js:15:20)
    at generateGraphPromise (/Users/cherkalexander/.nvm/versions/node/v16.15.1/lib/node_modules/@sandworm/audit/src/graph/index.js:37:19)
    at async getReport (/Users/cherkalexander/.nvm/versions/node/v16.15.1/lib/node_modules/@sandworm/audit/src/index.js:41:25)
    at async Object.handler (/Users/cherkalexander/.nvm/versions/node/v16.15.1/lib/node_modules/@sandworm/audit/src/cli/index.js:43:7)

System (please complete the following information):

• Node Version - 16.15.1
• Package Manager - PNPM
• Package Manager Version - 7.17.1
• OS: MacOs

Additional context
I tried to use sandworm in a project where yarn 1 is used, and it works great. Thank you for this cool project 👍

We should give users the option to report crashes.

@gabidobo FYI, still not working here. I've tried running from both the root with -p and from an app package subdirectory itself and it still doesn't seem to be finding the yarn.lock in the repo root:

monorepo on  develop [$⇡]
❯ sandworm-audit -p packages/apps/an-app
Sandworm 🪱
Security and License Compliance Audit
⠋ Building dependency graph...
❌ Failed: No lockfile found

monorepo on  develop [$⇡]
❯ cd packages/apps/an-app

packages/apps/an-app on  develop [$⇡]
❯ sandworm-audit
Sandworm 🪱
Security and License Compliance Audit
⠋ Building dependency graph...
❌ Failed: No lockfile found

packages/apps/an-app on  develop [$⇡]
❯ sandworm-audit -v
1.46.0

Originally posted by @liamjones in #101 (reply in thread)

Sandworm version
1.36.0

Describe the bug
When audit reads out the npm configuration, it fails if you have boolean properties in the .npmrc configuration:

❌ Failed: str.replace is not a function                                                                                          
TypeError: str.replace is not a function                                                                                         
    at replaceEnvVars (/home/user/.nvm/versions/node/v18.6.0/lib/node_modules/@sandworm/audit/src/registry.js:10:14)        
    at /home/user/.nvm/versions/node/v18.6.0/lib/node_modules/@sandworm/audit/src/registry.js:19:28                         
    at Array.forEach (<anonymous>)                                                                                               
    at getRegistriesInfo (/home/user/.nvm/versions/node/v18.6.0/lib/node_modules/@sandworm/audit/src/registry.js:18:27)     
    at loadRegistriesInfo (/home/user/.nvm/versions/node/v18.6.0/lib/node_modules/@sandworm/audit/src/registry.js:71:20)    
    at setupRegistries (/home/user/.nvm/versions/node/v18.6.0/lib/node_modules/@sandworm/audit/src/registry.js:75:3)        
    at getReport (/home/user/.nvm/versions/node/v18.6.0/lib/node_modules/@sandworm/audit/src/index.js:44:9)                 
    at exports.handler (/home/user/.nvm/versions/node/v18.6.0/lib/node_modules/@sandworm/audit/src/cli/cmds/audit.js:164:15)

Manifest files
Just add a boolean configuration property to your .npmrc file:

always-auth=false

To Reproduce
Just add a boolean configuration property to your .npmrc file:

always-auth=false

Expected behavior
Sandworm-audit should parse AND respect the available configuration settings from the different package managers. But at least from npm.

System (please complete the following information):

• Node Version [v18.6.0]
• Package Manager [npm]
• Package Manager Version [8.19.2]
• OS: [Ubuntu 22.04, WSL2]

Additional context
Add any other context about the problem here.