The Value Behind the Structure

We've developed several scripts to achieve a single goal. The exercise begs this question: why didn't we write one program instead? We could've included all our steps (download the JSON, analyze it, print a report) in a Python or Shell script; wouldn't that have been easier?

But the advantage of our current setup is the modularity of the different pieces in the face of different workflows. For example, we might want to do all the steps at once, or we might just want a subset. If I've already downloaded all the JSON for a page and put it into a folder, scanned it, and created a report at some-site-1-18-18.json, then, when I visit the info, all I need is the ability to format the report from the raw json. I can achieve that with simple Unix:

cat output.json | formatjs

Or we might want to extend the workflow. Because the foundation is built on plain text, it's easy to add new pieces. If our mail utility is set up, we can email ourselves the results of the test:

grabjs https://www.target.site sourcejs; scanjs sourcejs output.json | formatjs | mail -s "JS Known Component Vulnerabilities" email@site.com

Or we could decide we only want to email ourselves the critical vulnerabilities. We could pull out the text we care about by using ag, a grep-like natural-language search utility known for its blazing speed:

grabjs https://www.target.site sourcejs; scanjs sourcejs output.json | formatjs | ag critical | mail -s "Critical JS Known Component Vulnerabilities" email@site.com

We could substitute using email as a notification with using a script invoking the Slack API or another messaging service – the possibilities are endless. The benefit from using these short, stitched-together programs, built around common input and output, is that they can be rearranged and added to at will. They are the building blocks for a wider range of combinations and services. They are also, individually, very simple scripts, and because they're invoked through and pass information back to the command line, can be written in a variety of languages. I've used Python and Shell in this work, but could employ Ruby, Perl, Node, or another scripting language, with similar success.

There are obviously a lot of ways these short scripts could be improved. They currently have no input-verification, error-handling, logging, default arguments, or other features meant to make them cleaner and more reliable. But as we progress through the book, we'll be building on top of the utilities we're developing until they become more reliable, professional tools. And by adding new options, we'll show the value of a small, interlocking toolset.