Add script for vulnerability checking of Node.js dependencies

[facutuesca]

Description

This change adds a new script that queries vulnerability databases in order to find if any of Node's dependencies is vulnerable. The idea is to run this script as part of the CI of the Node.js repo, and if any new vulnerabilities are found automatically open an issue tagging Node's maintainers and security WG members.

The deps/ directory of Node's repo is scanned to gather the currently used version of each dependency, and if any vulnerability is found for that version a message is printed out with its ID and a link to a description of the issue.

Closes nodejs/security-wg#802. See the description and discussion there for more details.

How to use

In order to query the GitHub Advisory Database, a Personal Access Token has to be created (no permissions need to be given to the token, since it's only used to query the public database). Once acquired, the script can be run like:

cd node/tools/dep_checker/
pip install -r requirements.txt

# Python >= 3.9 required
python main.py --gh-token=$PERSONAL_ACCESS_TOKEN

# or to skip querying the GitHub Advisory Database, simply run:
python main.py

Example output

WARNING: New vulnerabilities found
- npm (version 1.2.1) :
	- GHSA-v3jv-wrf4-5845: https://github.com/advisories/GHSA-v3jv-wrf4-5845
	- GHSA-93f3-23rq-pjfp: https://github.com/advisories/GHSA-93f3-23rq-pjfp
	- GHSA-m6cx-g6qm-p2cx: https://github.com/advisories/GHSA-m6cx-g6qm-p2cx
	- GHSA-4328-8hgf-7wjr: https://github.com/advisories/GHSA-4328-8hgf-7wjr
	- GHSA-x8qc-rrcw-4r46: https://github.com/advisories/GHSA-x8qc-rrcw-4r46
	- GHSA-m5h6-hr3q-22h5: https://github.com/advisories/GHSA-m5h6-hr3q-22h5
- acorn (version 6.0.0) :
	- GHSA-6chw-6frg-f759: https://github.com/advisories/GHSA-6chw-6frg-f759

For each dependency and vulnerability, check the following:
- Check the vulnerability's description to see if it applies to the dependency as
used by Node. If not, the vulnerability ID (either a CVE or a GHSA) can be added to the ignore list in
dependencies.py. IMPORTANT: Only do this if certain that the vulnerability found is a false positive.
- Otherwise, the vulnerability found must be remediated by updating the dependency in the Node repo to a
non-affected version.

Implementation details

• The databases queried are the National Vulnerability Database and the GitHub Advisory Database
• The queries can return false positives (see this comment for an example). These can be ignored by adding the vulnerability to the ignore_list in dependencies.py
• The script takes a while to finish (~2 min) because queries to the NVD are rate-limited. This could be reduced by getting and setting up an API key.
• Querying the GitHub DB requires an auth token, which can be provided using the --gh-token argument. For CI, this token will be provided by GH itself using Automatic token authentication.

[mhdawson]

@facutuesca, how closely is this tied to being in the Node.js repo? I'm wondering if it needs to be in the nodejs/node repo or if it could be in something like nodejs/deps-watcher ?

[facutuesca]

@facutuesca, how closely is this tied to being in the Node.js repo? I'm wondering if it needs to be in the nodejs/node repo or if it could be in something like nodejs/deps-watcher ?

@mhdawson It is tied in the sense that the script gets the dependencies' current versions by reading the files from the repo. This makes it simpler if you want each branch/version of Node to check its own dependencies. By having it separate, you would have to manually clone and checkout the Node repo at the desired version(s), and then point the script to it.

Adding to that, the script contains information about each dependency (basically, how to look it up in the vulnerability databases). If dependencies are added/removed on a future Node version, it would make the mainteinance of that information a bit more complicated (having one branch of the script per Node version to maintain)

[mhdawson]

@facutuesca thanks, makes sense to me, just wanted to understand if it needed to be bundled in or not.

[mhdawson]

Will try to review/comment tomorrow

[mhdawson]

@facutuesca I tried running, is there a dependency on a particular python version?

[midawson@midawson dep_checker]$ python2.7 main.py
  File "main.py", line 24
    def __init__(self, id: str, url: str):
                         ^
SyntaxError: invalid syntax
[midawson@midawson dep_checker]$ python3 main.py
Traceback (most recent call last):
  File "main.py", line 16, in <module>
    from dependencies import ignore_list, dependencies
  File "/home/midawson/deps-check/node/tools/dep_checker/dependencies.py", line 36, in <module>
    "CVE-2019-0190",  # openssl, can be only triggered in combination with Apache HTTP Server version 2.4.37
TypeError: 'type' object is not subscriptable
[midawson@midawson dep_checker]$ 
111

[facutuesca]

@facutuesca I tried running, is there a dependency on a particular python version?

@mhdawson Yes, sorry I didn't realize it when I created the PR. Any Python >= 3.9 should work.

[RafaelGSS]

cc: @nodejs/security-wg

[mhdawson]

LGTM. Overall this looks like a good start to me. I think we should land and then start running nightly as the best way to fully validate.

[mhdawson]

And just to confirm it ran ok for me with python 3.9

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/44942/

[vdeturckheim]

lgtm, this is pretty cool!

[UlisesGascon]

LGTM! Great contribution! 👍

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/44962/

[RafaelGSS]

Would you mind adding README.md explaining how this tool works? For reference see: https://github.com/nodejs/node/blob/main/tools/snapshot/README.md

[mhdawson]

@facutuesca, I think the suggestion for a README.md is good and you can probably re-use of of the context instructions that you have in the first part of this PR.

[facutuesca]

@RafaelGSS @mhdawson Sorry for the delay, README added!

[RafaelGSS]

LGTM.

[RafaelGSS]

@facutuesca what are the next steps? I mean, we need automation to run it and open issues, right?

[mhdawson]

@RafaelGSS once it lands my plan was to create a Jenkins job that runs it nightly as a first step. Once its running we'll want to figure out if we need emails/alerts if it fails, where to post responses/documentation to what's been reported/exclusions and then backports to earlier lines.

[mhdawson]

Landed in 07411da

[mhdawson]

@richardlau I'm wondering about running this in the CI from the instructions.

cd node/tools/dep_checker/
pip install -r requirements.txt

Any concerns about installing those as it would likely be persistent. Using a virtualenv might improve that, but not sure if there would be remaning concerns?

[richardlau]

@mhdawson it would be better if they weren't persistent. Could we run in a GitHub Actions workflow? Or maybe in a container?

Otherwise maybe we could do what we do in the Makefile where we use -t to install into a directory and then reference via PYTHON_PATH?

node/Makefile

Line 1479 in 98ade2d

$(PYTHON) -m pip install --no-user --upgrade -t tools/pip/site-packages flake8 || \

node/Makefile

Line 1487 in 98ade2d

PYTHONPATH=tools/pip $(PYTHON) -m flake8 --count --show-source --statistics .

[mhdawson]

@richardlau I had thought that GitHub action could make sense as well. Maybe that is the easiest way to go.

[RafaelGSS]

I'm +1 to GH Actions. In addition to the concern about persistence, it will make automation even easier. for example, when a vulnerability is found, a issue will be created

[richardlau]

Removing lts-watch-v14.x as the vulnerability checking and scripts, including v14.x, are now in https://github.com/nodejs/nodejs-dependency-vuln-assessments.