Beyond npm Audit to Traverse an Increasingly Complex Dependency Tree

If you've been immersed in the Node.js/JavaScript community for awhile, or even if you are just getting started, you are likely using npm audit to scan package dependencies in your projects. It's easy to stumble upon as part of the ubiquitous npm, and even without trying you'll periodically be prompted to run npm audit fix (a healthy example of nagging).

Much like #DevOps tore down silos and got product teams thinking more about "Day Two" issues such as continuous deployment and observability, #DevSecOps is once again asking us to "shift left" many of the security challenges traditionally seen as a checkbox or someone else's responsibility.

For a small hobby project or proof-of-concept (PoC), this is often less of a concern... but for big enterprise or the latest "unicorn" seeking to move quickly without loosing reputation or intellectual property, the need for product teams to innovate faster than competitors while taking on increased responsibility presents a challenge. I'll argue that even hobby projects and PoCs need to address this balancing act (though often with more risk tolerance), since building good hygiene habits as part of our development katas helps the community at large and PoCs tend to live longer than anyone likes to admit!

The Problem

The problem of course is that, even if you love security and fully embrace DevSecOps, you will often hear and perhaps even believe that product teams should focus on their "value proposition" – what differentiates you from all the other players in the market. This is how you move fast enough to stay relevant. In contrast, security is often seen as a bolt-on, something everyone agrees is needed without much alignment on how to achieve the desired outcome.

"Agreement is easy... alignment is hard. When I ask my wife if she wants dinner, she quickly says okay – the trouble starts when I ask where we should go." – Mark Magliocco

Referring back to DevOps learnings, many of the application lifecycle challenges around Continuous Integration and Continuous Deployment ultimately got solved through a SRE mindset – automate all the things. What started as bespoke duct tape and baling wire (a natural starting point in any new paradigm shift as practitioners find their footing) slowly evolved into a plethora of tooling for everything from automated testing to infrastructure provisioning. To be successful in a DevSecOps world, teams need to embrace a similar mindset... picking the right tools to help with the toil and heavy lifting so they can "check the right boxes" while continuing to focus on their core value.

Beyond tooling, part of focusing on value is not reinventing the wheel. While this has long been sound advice for harder things like caching or crypto, the scenarios in which the typical product team reaches for off the shelf components has grown exponentially over the past decade. Problems which were once thought of as novel or at least worth owning are now available as libraries in your favorite package ecosystem. Much like PyPi or RubyGems, npm is a large part of what made Node.js so successful (so quickly)!

While a great way to save time, these dependencies often add up to encompass more functionality than initially planned or what's necessarily visible within a specific project (as many projects organically grow and bolt together to form "big-A" applications). Auditing efforts now must traverse an increasingly complex tree of constituent components (dependencies of dependencies), and mitigating any issues depends on more than the will of the immediate team.

Aside from the normal bugs and CVEs inherent to any system dreamt up by human beings, rogue actors pose an increasing threat. Typosquatting is no longer limited to common misspelling for DNS domains. The sheer number of oddly familiar but not-quite-right repos and projects is concerning. Often even good projects have maintainers who lose interest over time (maintainers have lives too!), and fall victim to social attacks as individuals with questionable motives leverage the project's popularity as an attack vector in obscure ways which often go unnoticed for months. This has impacted everything from GitHub projects to npm packages to plugins for your favorite editor...each time with similarly obfuscated success, giving devoted adversaries adequate time to hit and run.

It's All About the Data

We've seen the importance of tools, but tooling is only as good as the intelligence behind it... whether the brain child of some algorithmic genius (or community), or the data set behind everything from our Google searches to reputation engines.

OSS Index is a free web service (and API) which aggregates security data from trusted sources such as the Common Vulnerabilities and Exposures list. The nice thing is having one interface to search numerous security feeds, and the fact that the data and sources continuously evolve. This makes it easier for developers trying to do the right thing (even on smaller projects) to make informed decisions in an increasingly complex and hostile landscape.

Whether you are developing in Java, Python, Ruby, Go, Node.js or many other popular languages there is great ecosystem support. It's also easy to get started incorporating OSS Index into your favorite toolchain and workflow thanks to an increasing number of integrations.

Automate the Dirty Work

I'm not going to talk more about how to use OSS Index, because there's already a lot of great information on how to do that. Instead, I'd like to tie the headline and subsequent points in this post together... How can we leverage tooling backed by data to move faster and improve the quality of our Node.js project?

One answer is Audit.js which leverages the OSS Index API and data to report on vulnerabilities in your project – as well as any transitive dependencies. You can even point it at a package.json for targeted scanning. Aside from increasing confidence, this helps over-worked developers sleep at night!

The nice thing is, since OSS Index is free, you don't even need to signup for an account to use Audit.js. For (very) large projects having a (free) account helps bypass API rate limits, but my experience scanning "typical" web services with UI and API components didn't necessitate signing up to reap the benefits. The tool quickly calls out potential issues, and is fast enough to plugin to your IDE or CI/CD pipeline.

With little effort (npm i auditjs -D;npx auditjs), you essentially have npm audit on steroids! If you already leverage make to build container images and simplify other project tasks, just add an audit target:

NPM=/usr/local/opt/node@12/bin/npm
NPX=/usr/local/opt/node@12/bin/npx

audit:
	$(NPM) audit
	$(NPX) auditjs

As it turns out, you can have your cake and eat it too – by leveraging free tools backed by powerful data you can shift left without slowing down.