feat: Create fuzzer for the JavaScript language parser

Description

cve-bin-tool has an existing fuzz testing setup which is based on Google Atheris. One of the areas it doesn't yet cover is the files used by the language list parsers. These are typically lists of 3rd party components/requirements written in a format to a specific packaging tool for a specific programming language. These may be lists of requirements generated by a human, or they could be generated by a tool.

This particular request is to fuzz the JavaScript language parser which uses package-lock.json files, but I'll be filing requests for the other parsers as well. You can see which ones are listed under the security tag.

Why?

Regular fuzz testing can help us find bugs and potential security issues in parsing . While we hope users aren't going to be regularly scanning malicious package-lock.json files we'd still like to be able to handle things correctly if a file is really malformed.

How should I do this?

Set up your own environment for fuzzing cve-bin-tool using Atheris. We recommend you use a container or vm for this for safety (a misconfigured fuzzer can potentially make a big mess).
Be aware that Atheris and its requirements can be a bit finicky to set up and last time we ran a big fuzzing campaign only some versions of Python in some environments actually worked easily. If you find any issues with following the setup docs, or manage to find good workarounds for an environment we haven't mentioned, please file issues or make a PR to add them to our docs.
Create a new proto file (or files) to generate fuzzed package-lock.json files and add them to our proto files directory: https://github.com/intel/cve-bin-tool/tree/main/fuzz/proto_files. It's ok to have tests against files that are completely garbage, but probably the most interesting bugs will come from files that mostly look correct, and the proto setup will help you do that. If you're not sure how any of this works, you may find it useful to read this primer on structure-aware fuzzing. Note that we already have some fuzzers that use the json format such as the cyclonedx one, so that might help you figure out how to make this one.
Make a python file to call your fuzzer. Here's what the cyclonedx fuzzer looks like, as an example. Yours may be considerably different -- feel free to search for other examples and read the Atheris/libfuzzer/protobuf-mutator docs to help you figure out what you need.

Hacktoberfest

I'm filing this with the intention of it being a bug for hacktoberfest 2023. If you're intending to do it as part of that contest, make sure you follow their rules. I believe we have to accept/merge your PR between Oct 1-31 for it to count, and you'll need to register after September 28 but probably before we merge anything. You may be able to open a draft PR earlier. Do let me know if you need something to count for hacktoberfest.

New Contributor Tips

Since this is marked as a hacktoberfest issue there's a good chance whoever does it will be new to cve-bin-tool, so here's the tips we usually put on new contributor friendly bugs

Short tips for new contributors:

cve-bin-tool's contributor docs
If you've contributed to open source but not this project, you might just want our checklist for a great pull request
cve-bin-tool uses https://www.conventionalcommits.org/ style for commit messages, and we have a test that checks the title of your pull request (PR). A good potential title for this one is in the title of this issue.
You can make an issue auto close by including a comment "fixes #ISSUENUMBER" in your PR comments where ISSUENUMBER is the actual number of the issue. This "links" the issue to the pull request.

Claiming issues:

You do not need to have an issue assigned to you before you work on it. To "claim" an issue either make a linked pull request or comment on the issue saying you'll be working on it.
If someone else has already commented or opened a pull request, assume it is claimed and find another issue to work on.
If it's been more than 1 week without progress, you can ask in a comment if the claimant is still working on it before claiming it yourself (give them at least 3 days to respond before assuming they have moved on).

intel / cve-bin-tool