The npm package manager has a built-in flag called audit to scan for vulnerabilities in your project’s dependencies and the npm audit command is likely a common CI step for many. How to use npm audit, what are some power-user tips for it, what are the common issues with it and what do I recommend to adopt for a good security posture in your project? Let’s dive in.

The npm audit command was initially added with npm@6 and allowed developers to run a security scan of their direct and transitive dependencies for public and known vulnerabilities in the npm ecosystem. Back then, npm was self-directed and the audit command was a wrapper around npm’s own vulnerability database. With the GitHub acquisition, npm audit now uses the GitHub Advisory Database, which is a superset of the npm database and includes vulnerabilities from other ecosystems like RubyGems, PyPI, and others.

How to use npm audit

To run an audit, you can simply run npm audit in your project’s root directory. This will scan your project’s dependencies and print out a summary of the vulnerabilities found.

In fact, you’ve probably seen a summary of the npm audit command before when you installed packages in your npm project, like this:

$ npm install <package-name>
npm WARN <package-name> <version> requires a peer of <peer-dependency> but none is installed. You must install peer dependencies yourself.
+ <package-name>@<version>
25 vulnerabilities (2 moderate, 23 high)
To address issues that do not require attention, run:
  npm audit fix

What you see there is that the npm package manager is already running an explicit scan of the dependency tree after you’ve installed a new package. Of course, if a dependency is malicious, then this is already too-late in most cases because the package has probably already been installed, executed and done its harm, but we won’t get into that here if you are curious though, I highly recommend you take a look at my proactive security CLI tool npq which shows you security information BEFORE YOU INSTALL A PACKAGE. Genius, right? I know 😎.

So back to npm audit, the basic use in a given project is indeed as simple as running npm audit and you’ll get a summary of the vulnerabilities found in your project’s dependencies:

$ npm audit <package@version>
# npm audit report
braces  <3.0.3
Severity: high
Uncontrolled resource consumption in braces - https://github.com/advisories/GHSA-grv7-fg5c-xmjg
fix available via `npm audit fix`
node_modules/braces

If you want to see more details, you can run npm audit --json to get a JSON output of the vulnerabilities found (handy if you’re building some custom security report). If you want to see the vulnerabilities in a tree format, you can run npm audit --parseable to get a tree view of the vulnerabilities.

Downsides of npm audit and how to address them

Let’s see the full report of the above npm audit command:

$ npm audit <package@version>
# npm audit report
braces  <3.0.3
Severity: high
Uncontrolled resource consumption in braces - https://github.com/advisories/GHSA-grv7-fg5c-xmjg
fix available via `npm audit fix`
node_modules/braces
fast-xml-parser  <4.4.1
Severity: high
fast-xml-parser vulnerable to ReDOS at currency parsing - https://github.com/advisories/GHSA-mpg4-rc92-vx8v
fix available via `npm audit fix`
node_modules/fast-xml-parser
html-minifier  *
Severity: high
kangax html-minifier REDoS vulnerability - https://github.com/advisories/GHSA-pfq8-rq6v-vf5m
No fix available
node_modules/html-minifier
  assetgraph  >=1.10.0
  Depends on vulnerable versions of html-minifier
  Depends on vulnerable versions of workbox-build
  node_modules/assetgraph
    subfont  *
    Depends on vulnerable versions of assetgraph
    node_modules/subfont
lodash.template  *
Severity: high
Command Injection in lodash - https://github.com/advisories/GHSA-35jh-r3h4-6jhm
No fix available
node_modules/lodash.template
  workbox-build  <=5.1.4
  Depends on vulnerable versions of lodash.template
  node_modules/workbox-build

Is this output hard to parse? I think so too.

Can you easily make decisions on which vulnerabilities to address? I think not.

If you have nothing else, npm audit is better than nothing, but it’s not the best tool for the job. Where it falls short:

• npm audit by default will display development dependencies (devDependencies). This can be overwhelming and not useful for the developer who is trying to understand the security posture of their application because those dependencies are not part of the deployed production application. Hence, creating vulnerability noise.
• npm audit doesn’t monitor your dependencies in any way, so you have to remember to run it manually.
• npm audit doesn’t provide a way to ignore vulnerabilities, so you can’t easily suppress false positives or known issues that you wish to defer addressing.
• npm audit doesn’t provide a way to automatically fix vulnerabilities, so you have to manually update your dependencies (or fall back to npm audit fix which can be dangerous and can end up with a broken application).
• npm audit fix can be dangerous because it will update your dependencies to the latest major version (so introducing a breaking change) or it can completely downgrade a package to a version that is not compatible with your application.

There are other issues with npm audit but these are the main ones that I see developers struggle with.

A better way to audit your dependencies

If you take your application security seriously and your working on more than a hobby side project, then you should consider adopting a more robust application security platform that puts the focus on developers and provides them with the tools they need to secure their applications. Snyk is a great example of that.

Snyk is a developer-first security platform that first and foremost is designed around developer workflows and has a generous always-free tier.

Snyk helps you find, fix, and prevent vulnerabilities in your applications. It’s flexible and integrates with your CI/CD pipeline (for example, there’s a GitHub Actions workflow you can embed), your IDE (get the VS Code extension!), and your source control system to provide you with security information at the right time and in the right place.

If you’re on the CLI you can scan your project’s dependencies with snyk test (and install Snyk CLI with npm install -g snyk because the Snyk CLI is also available as an npm package):

$ snyk test
Tested 1098 dependencies for known issues, found 17 issues, 20 vulnerable paths.
Issues to fix by upgrading:
  Upgrade git-contributors@0.2.3 to git-contributors@0.2.5 to fix
  ✗ Regular Expression Denial of Service (ReDoS) [Medium Severity][https://security.snyk.io/vuln/SNYK-JS-LODASH-1018905] in lodash@3.9.3
    introduced by git-contributors@0.2.3 > lodash@3.9.3
  ✗ Regular Expression Denial of Service (ReDoS) [Medium Severity][https://security.snyk.io/vuln/SNYK-JS-LODASH-73639] in lodash@3.9.3
    introduced by git-contributors@0.2.3 > lodash@3.9.3
  ✗ Prototype Pollution [Medium Severity][https://security.snyk.io/vuln/npm:lodash:20180130] in lodash@3.9.3
    introduced by git-contributors@0.2.3 > lodash@3.9.3
  ✗ Code Injection [High Severity][https://security.snyk.io/vuln/SNYK-JS-LODASH-1040724] in lodash@3.9.3
    introduced by git-contributors@0.2.3 > lodash@3.9.3
  ✗ Prototype Pollution [High Severity][https://security.snyk.io/vuln/SNYK-JS-LODASH-450202] in lodash@3.9.3
  Upgrade git-tags-remote@1.0.2 to git-tags-remote@1.0.3 to fix
  ✗ Command Injection [High Severity][https://security.snyk.io/vuln/SNYK-JS-GITTAGSREMOTE-596503] in git-tags-remote@1.0.2
    introduced by git-tags-remote@1.0.2
  Upgrade nuxt@3.12.2 to nuxt@3.12.4 to fix
  ✗ Cross-site Scripting (XSS) [Medium Severity][https://security.snyk.io/vuln/SNYK-JS-NUXT-7640972] in nuxt@3.12.2
    introduced by nuxt@3.12.2
  ✗ Remote Code Execution (RCE) [High Severity][https://security.snyk.io/vuln/SNYK-JS-NUXT-7640974] in nuxt@3.12.2
    introduced by nuxt@3.12.2
Issues with no direct upgrade or patch:
  ✗ Missing Release of Resource after Effective Lifetime [Medium Severity][https://security.snyk.io/vuln/SNYK-JS-INFLIGHT-6095116] in inflight@1.0.6
    introduced by nuxt@3.12.2 > nitropack@2.9.7 > @vercel/nft@0.26.5 > glob@7.2.3 > inflight@1.0.6 and 3 other path(s)
  No upgrade or patch available
  ✗ Malicious Package [Critical Severity][https://security.snyk.io/vuln/SNYK-JS-LEGACYSWCHELPERS-7647380] in legacy-swc-helpers@0.4.14
    introduced by @nuxt/fonts@0.7.1 > fontaine@0.5.0 > @capsizecss/unpack@2.2.0 > fontkit@2.0.2 > @swc/helpers@0.4.36 > legacy-swc-helpers@0.4.14
  No upgrade or patch available

Much more readable, yes? I agree ;-)

Benefits of using Snyk in my opinion:

• Scanned your dependencies? great. Now run snyk monitor and your project will be monitored for new vulnerabilities and you’ll get an email notification if a new vulnerability is found in your project.
• Better than manually scanning and monitoring your dependencies, Snyk integrates with your CI/CD pipeline and your source control system and will automatically create a pull request to fix vulnerabilities in your project. how? connect Snyk to your GitHub repo and you’re set!
• Your on a polyglot team that manages code that is more than just JavaScript? Snyk supports multiple ecosystems like Java, Python, Ruby, Go, and many others.
• Your repository is a monorepo with different language ecosystems? Easy peasy. Run snyk test --all-projects in the root of your repository and Snyk will traverse through all supported ecosystem manifest files and scan/import them for you.
• Use the various Snyk CLI to filter for severity levels, ignore vulnerabilities based on CVE or a Snyk advisory id, and more.
• Security teams love their acronym. They’ll tell you npm audit is not enough and they want an SBOM output, a SAST scan, your container image scanned, your Terraform configuration scanned, and more. Snyk has you covered with all of that. Just fire off the adequate command and you’re done (or connect Snyk to GitHub and it’ll discover all of these automatically). Job done.
• Security teams love their security dashboards so they’ll ask you for a report. Easy peasy: snyk test --json > snyk-report.json and you’re done. They asked you for a SARIF format? snyk test --sarif > snyk-report.sarif and you’re done.

Snyk also provides you with a way to ignore vulnerabilities, so you can suppress false positives or known issues that you wish to defer addressing. You can also create a policy to enforce security standards across your organization and prevent other developers in your team from introducing new vulnerabilities based on policies and PR checks that you can setup if you integrate Snyk with your GitHub repository.

Conclusion

How to use npm audit? Well, just run it. Yes it’s that simple. But if you’re serious about securing your applications, shipping secure code with your team, then you should consider adopting a more robust security platform like Snyk.

Disclaimer - I work at Snyk!