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 (Read more...)

*** This is a Security Bloggers Network syndicated blog from Sonatype Blog authored by Mike Hoskins. Read the original post at: