DEV Community

Dan Miller
Dan Miller

Posted on

How to keep your Javascript projects safe

If you are building a Javascript project, you are likely going to be incorporating many different open source projects. After all, why reinvent the wheel - it’s likely that someone has already developed and created a package that does much of what you’re trying to do! According to the latest State of the Software Supply Chain report, around 80 to 90% of modern applications consist of open source components.

How confident are you that all of those open source components are free from security vulnerabilities? How about all of the dependencies of all of THOSE components? Or the dependencies of the dependencies of your dependencies?

Turtles all the way down!

It's turtles I mean dependencies all the way down and without automated tooling, you have no way to know if your application is truly secure.

What is AuditJS

AuditJS is a tool that was designed to help answer that question and make sure your dependencies (and all of THEIR dependencies) are all free of security vulnerabilities. AuditJS is an open source command line tool written by the Javascript community and sponsored by Sonatype. It uses Sonatype’s OSS Index v3 REST API to identify known vulnerabilities and outdated package versions.

Why would I use AuditJS?

AuditJS is a command line tool that supports any project with package managers that install npm dependencies into a node_modules folder (npm, angular, yarn, bower, etc.). AuditJS will scan your package.json file and scan it for vulnerabilities.

The great thing about AuditJS is that not only will it scan the packages in your package.json but it will scan all the dependencies of your dependencies, all the way down. Being able to know if you have a security vulnerability even on transitive dependencies can come with some significant peace of mind!

Alt Text

How do I use AuditJS?

To use AuditJS, first navigate to any project that contains a node_modules folder with a node LTS version of 8.x or higher installed. Then, you can run AuditJS in one of two ways. The easiest way is to just run it via npx

npx auditjs@latest ossi

If you prefer, you can also install AuditJS globally

npm install -g auditjs

No matter whether you install AuditJS globally or run it through npx, the usage is the same. You can either set configuration, audit your application using the Sonatype OSS Index, or audit your application using a Nexus IQ server instance.

  auditjs config          Set config for OSS Index or Nexus IQ Server
  auditjs ossi [options]  Audit this application using Sonatype OSS Index
  auditjs iq [options]    Audit this application using Nexus IQ Server

The OSS Index does have a rate limit in place - to increase your limit, you can sign up for a free account with OSS Index. AuditJS will cache results for a 12 hour period, which should help with rate limiting as well.

You can view the AuditJS usage page for additional configuration options for auditing with both the OSS Index as well as Nexus IQ server.

I ran AuditJS - now what?

Once you run AuditJS, it will output results to the screen

$ npx auditjs@latest ossi
npx: installed 109 in 13.27s
 ________   ___  ___   ________   ___   _________       ___   ________      
|\   __  \ |\  \|\  \ |\   ___ \ |\  \ |\___   ___\    |\  \ |\   ____\     
\ \  \|\  \\ \  \\\  \\ \  \_|\ \\ \  \\|___ \  \_|    \ \  \\ \  \___|_    
 \ \   __  \\ \  \\\  \\ \  \ \\ \\ \  \    \ \  \   __ \ \  \\ \_____  \   
  \ \  \ \  \\ \  \\\  \\ \  \_\\ \\ \  \    \ \  \ |\  \\_\  \\|____|\  \  
   \ \__\ \__\\ \_______\\ \_______\\ \__\    \ \__\\ \________\ ____\_\  \ 
    \|__|\|__| \|_______| \|_______| \|__|     \|__| \|________||\_________\

  _      _                       _   _              
 /_)    /_`_  _  _ _/_   _  _   (/  /_`_._  _   _/ _
/_)/_/ ._//_// //_|/ /_//_//_' (_X /  ///_'/ //_/_\ 
   _/                _//                            

  AuditJS version: 4.0.14

✔ Starting application
✔ Getting coordinates for Sonatype OSS Index
✔ Auditing your application with Sonatype OSS Index
✔ Submitting coordinates to Sonatype OSS Index
✔ Reticulating splines
✔ Removing whitelisted vulnerabilities

  Sonabot here, beep boop beep boop, here are your Sonatype OSS Index results:
  Total dependencies audited: 201

[1/201] - pkg:npm/@babel/runtime@7.4.4 - No vulnerabilities found!
[2/201] - pkg:npm/@babel/runtime@7.9.2 - No vulnerabilities found!
[3/201] - pkg:npm/@emotion/hash@0.8.0 - No vulnerabilities found!
[66/201] - pkg:npm/angular-vs-repeat@1.1.7 - No vulnerabilities found!
[67/201] - pkg:npm/angular-xeditable@0.2.0 - No vulnerabilities found!
[68/201] - pkg:npm/angular@1.6.10 - 1 vulnerability found!

  Vulnerability Title:  CWE-20: Improper Input Validation
  ID:  f6068161-e90a-4dfc-a613-be7a54d0580f
  Description:  The product does not validate or incorrectly validates input that can affect the control flow or data flow of a program.
  CVSS Score:  8.2
  CVSS Vector:  CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H
  CVE:  undefined

[69/201] - pkg:npm/axios@0.19.2 - No vulnerabilities found!
[191/201] - pkg:npm/regenerator-runtime@0.13.5 - No vulnerabilities found!
[192/201] - pkg:npm/rw@1.3.3 - No vulnerabilities found!
[193/201] - pkg:npm/scheduler@0.13.6 - No vulnerabilities found!
[194/201] - pkg:npm/semver@1.1.4 - 2 vulnerabilities found!

  Vulnerability Title:  [CVE-2015-8855]  Resource Management Errors
  ID:  630522d1-8cab-41ea-9c11-c4978a195661
  Description:  The semver package before 4.3.2 for Node.js allows attackers to cause a denial of service (CPU consumption) via a long version string, aka a "regular expression denial of service (ReDoS)."
  CVSS Score:  7.5
  CVSS Vector:  CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
  CVE:  CVE-2015-8855

  Vulnerability Title:  CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')
  ID:  00864743-f576-4ce5-a8f6-2b933cc2606e
  Description:  The software does not properly restrict the size or amount of resources that are requested or influenced by an actor, which can be used to consume more resources than intended.
  CVSS Score:  5.3
  CVSS Vector:  CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
  CVE:  undefined

[195/201] - pkg:npm/sjcl@1.0.7 - No vulnerabilities found!
[196/201] - pkg:npm/string.prototype.repeat@0.2.0 - No vulnerabilities found!
[197/201] - pkg:npm/symbol-observable@1.1.0 - No vulnerabilities found!
[198/201] - pkg:npm/tiny-warning@1.0.3 - No vulnerabilities found!
[199/201] - pkg:npm/typesettable@3.1.0 - No vulnerabilities found!
[200/201] - pkg:npm/xmlhttprequest@1.8.0 - No vulnerabilities found!
[201/201] - pkg:npm/xss-filters@1.2.7 - No vulnerabilities found!

(results truncated for readability; you can also use --quiet to skip packages without vulnerabilities)

As you can see, AuditJS gives a full bill of materials of the scanned code, including transitive dependencies. If a scan results in no vulnerabilities, it will return a 0 error code - otherwise it will return a 1. This can be used as part of a build process, if desired.

You can also output results to a file in JSON:

auditjs ossi --json > file.json


auditjs ossi --xml > file.xml

You can see additional information and example projects on how to include AuditJS in your npm build or integrate with Github, Travis CI, Jenkins, Travis and other build tools on the AuditJS homepage.

Excluding vulnerabilities that don’t apply

If you investigate a security vulnerability and decide that it is not applicable in your particular situation, you do have the ability to exclude it from future scans. You can do this in one of two ways - either create an auditjs.json file at the root of your project, or point to an exclusion file on the command line

$ auditjs ossi --whitelist /<PATH_TO>/auditjs.json

The syntax of the auditjs.json file should look something like this:

"ignore": [{ "id": "78a61524-80c5-4371-b6d1-6b32af349043", "reason": "Insert reason here" }]

The id is the only field that is relevant - this is the id that comes back with that vulnerability from running AuditJS. The reason attribute is where you can specify a reason or other notes as to why this vulnerability is excluded from future scans.

AuditJS vs npm audit

Another tool for evaluating security vulnerabilities in Javascript projects that you may have heard of is npm audit. The two tools (and other similar ones) evaluate dependencies in a similar manner. The big difference will always be the data from which it is getting its vulnerabilities. A vulnerability scanning tool is only as good as the data it uses to scan!

Alt Text

I am no doubt biased, since I work for Sonatype, the company that sponsors the OSS Index, but I believe that the OSS Index data is significantly more reliable than data gathered from other sources. This is especially true in removing false positives, where a vulnerability is reported but is not actually a problem. These false positives are not only a waste of your time but can lead to desensitization where you just start ignoring audit results.

For a more detailed comparison of the two tools - check out this comparison of npm audit vs auditjs

Other free scanning tools using the OSS Index

Besides AuditJS, there are a couple of other similar tools that use the OSS Index to scan for vulnerabilities. So if you're a programming polyglot, you might check one of them out. Think of them as AuditJS equivalents for other languages.

  • Nancy - for Golang dependencies
  • Jake - for Python / Conda environments
  • Chelsea - for RubyGem powered projects

Beyond AuditJS - the difference between auditing with OSS Index vs. auditing with Nexus IQ server

You'll have noticed that you can choose to run AuditJS either against the (free) OSS Index or against the Nexus IQ server. Here's a brief rundown of the difference between those 2 options

Auditing your application against the OSS Index will catch most security vulnerabilities. AuditJS traverses your node_modules directory, so it will compile a complete list of all of your direct and transitive dependencies. It then uses "coordinate" or "name based matching" to communicate with OSS Index to identify vulnerabilities.

This will catch most security vulnerabilities, but won’t catch edge cases such as if you have:

Moved a vulnerable copy of jQuery into your project and left it in your lib folder (npm does not know about this)
Copied and pasted code from a project into one of your files

The Nexus IQ server does have ways to capture additional cases like this. One way you might set up your project would be to use OSS Index scanning for development environments and then audit using the Nexus IQ server for more production-capable controls, including the ability to set up policies to audit against.

Contributing to AuditJS

I hope you’ll take a look at AuditJS as a way to help shift left on security and keep your Javascript projects safe from security vulnerabilities.

AuditJS is an open source project supported by Sonatype for the Javascript community. AuditJS welcomes contributors - check out the Github page or chat with other contributors on the AuditJS Gitter.

Top comments (0)