JavaScript library checks

Many real-world break-ins start with an old library on a page, not a bug in the site's own code. Every replay therefore notes which JavaScript libraries the pages actually loaded and checks them against a public list of known vulnerabilities.

Where the data comes from

StepTrails ships no vulnerability data of its own. It uses the retire.js project's open data (Apache-2.0), which you download once and update when you like. Without it, replay still lists the libraries it finds but does not say whether they are vulnerable.

Set it up

node bin/vulndata.js update

This downloads the data into .steptrails/vuln/ in your project and checks it before accepting it. After that, every replay checks the libraries it sees. To see what is installed and how old it is:

node bin/vulndata.js status

The data changes as new problems are found, so update it now and then. Replay tells you when it is more than 30 days old. On a computer with no internet, download the file elsewhere and install it with node bin/vulndata.js update --from jsrepository.json.

What you get

Run a replay as usual:

node bin/replay.js recording.json --html report.html

• A LIBRARIES line in the terminal listing what was found, for example jquery 1.12.4, bootstrap 3.3.7.
• A finding for each vulnerable library version, in the same list as the other security checks: its severity, what the problems are, the version to upgrade to, the CVE and GitHub advisory numbers, links to the public advisories and the pages where it was loaded.
• A JavaScript libraries table in the HTML report with how many known vulnerabilities each library has.

Because it looks at what the browser really loaded, you see the libraries your visitors get, including ones added by a tag manager or a widget, and you do not get warnings about packages that never reach a page.

How a library is recognised

By its address (/ajax/libs/jquery/3.4.1/), its file name (jquery-3.4.1.min.js), the banner comment inside the file (/*! jQuery v3.4.1) or the file's fingerprint. Scripts over 3 MB are not read. A library that hides all of these, for example inside a bundle without a banner, is not found; tell your bundler to keep the banners if you want it found.

A bill of materials

Add --sbom libraries.json to get the libraries as a CycloneDX bill of materials, the standard list that audit and supply-chain tools read. It has each library's name, version and package URL, and no host names.

Tune it

• --no-libraries turns the library check off (and hides the note about missing data).
• In the policy file you can accept one library for a while, with a reason and an expiry date:

{ "accepted": [ { "check": "vulnerable-library", "library": "jQuery", "reason": "Upgrade planned for the March release", "expires": "2027-03-31" } ] }

• Use "checks": { "vulnerable-library": "high" } to change how serious it counts as for your project.
• Baselines and SARIF treat each library version as its own finding, so upgrading one library does not hide another.

Limits

• It only knows libraries in the retire.js data (around 75 popular ones) and only versions it can read from the file.
• A match means the version is in a range with a published vulnerability. Whether your site is actually exploitable depends on how the library is used, so the report says "known vulnerabilities", not "you are vulnerable".
• Libraries that your server runs (not the browser) are not covered; use your package manager's audit for those.