
Putting It All Together
So what does it look like when we put it all together? It's simple – we can construct a one-liner to scan the JavaScript of a target site just by passing the right directory references:
grabjs https://www.target.site sourcejs; scanjs sourcejs output.json | formatjs
Keep in mind we've already symlinked these scripts to our /usr/local/bin and changed their permissions using chmod u+x to make them executable and accessible from our path. With this command, we're telling our CL to download the JavaScript from http://target.site to the sourcejs directory, then scan that directory, create an output.json representation of the data, and finally format everything as a plain-text report.
As a means of testing the command, I recently read a blog decrying the fact that jQuery, responsible for a large chunk of the web's client-side code, was running an out-of-date WordPress version on http://jquery.com/, so I decided to see whether their JavaScript had any issues:
grabjs https://jquery.com sourcejs; scanjs sourcejs output.json | formatjs

The fact that http://jquery.com/ has a few issues is nothing huge, but still surprising! Known component vulnerabilities in JavaScript are a widespread issue, affecting a sizable portion of sites (different methodologies put the number of affected sites at between one-third and three-quarters of the entire web).