🔒 Make your JavaScript project safer by using this workflow

The security issue

Have you ever been thinking about security in your JavaScript projects? No? Well, you should, because with new thousands of package published on npm everyday, vulnerabilities could come from your own code but also from your direct dependencies (node_modules).

Few months ago, coa npm library was used to steal users' personal data by injecting malicious code.
As a reminder coa was:

• Downloaded approximately 9 million times per week
• Used by about 5 million GitHub projects

And that's just one story among many others...

If you're using npm to download dependencies, you have probably already encountered this message:

After each npm install, npm runs an audit scan against your updated dependencies. Here, we have 79 vulnerabilities, coming from one or many dependencies. Each one represents a potential threat and should be fixed.

Where do these vulnerabilities come from? Basically, npm maintains a vulnerability Database which is updated on a daily basis. Many other databases exist, here is an exhaustive list about most popular open-source databases for the JavaScript ecosystem:

• Node.js Security Working Group
• Snyk
• GitHub

These ressources are great, but we are lazy developers focused on productivity and we want to automate that, so we don't have to manually check all databases at 8 am every day before processing new features.

The security solution

First things first, I want to warn you about the fact that there is no silver bullet for security concerns.

If security were all that mattered, computers would never be turned on, let alone hooked into a network with literally millions of potential intruders. Dan Farmer, pioneer in the development of vulnerability scanners for Unix operating systems and computer networks.

Nevertheless, you can drastically reduce the amount of vulnerabilities by using tools that can be easily integrated with your projects.
However most of the time these tools are not open-source hence not for free use.

NodeSecure Continuous Integration

NodeSecure is an open source organization that aims to create free JavaScript security tools. Our biggest area of expertise is in npm package and code analysis.

To see more, read these NodeSecure series, written by Thomas @fraxken, founder of the GitHub organization.

What is @nodesecure/ci

@nodesecure/ci brings together a set of tools to identify dependencies vulnerabilities and track most common malicious code and patterns using Static Code Analysis and Vulnerabilities Analysis

If your project (custom configuration is available) passes all security checks, the process exit with no error code otherwise, it fails.

Here is a preview:

How to use

- GitHub Action

If you use GitHub Actions, you have a very straightforward way to add the official NodeSecure ci-action action to your workflow:

workflow.yaml

steps:
      - uses: actions/checkout@v2
      - uses: NodeSecure/ci-action@v1

Now your source code and its dependencies will be automatically analyzed, ironically without even adding new dependencies to your projects. That's also a perfect fit if your tech lead doesn't want you to add new dependencies (node_modules already heavier than the universe).

- Node.js Script

Install the @nodesecure/ci package and start using the entry script node_modules/.bin/nsci

As well as for the GitHub Action, you can provide a custom configuration through CLI arguments.

First, reference the binary script in the package.json

{
   "scripts": {
       "nsci": "nsci"
   }
}

Then start it providing different arguments (all can be used at once, by the way):

$ npm run nsci -- --directory=/Users/user1/myproject
$ npm run nsci -- --strategy=npm
$ npm run nsci -- --vulnerability=all
$ npm run nsci -- --warnings=error
$ npm run nsci -- --reporters=console

- Module API

@nodesecure/ci exposes its pipeline runner as an API to allow use in any other combined workflow.

import { runPipeline } from "@nodesecure/ci";

const optionsExample = {
    directory: process.cwd(),
    strategy: "node",
    vulnerabilities: "all",
    warnings: "error",
    reporters: ["console"]
}

await runPipeline(optionsExample);
// => the process can either exit with error code (1) 
// or no error code (0), depending on the pipeline status.

That's it, now you have no more excuses not to practice DevSecOps =)

Any feedback on @nodesecure/ci is welcome, the library is just getting started.

Feel free to reach me on GitHub @antoine-coulon

Thanks for reading.