Ask HN: How do you security-audit external software using NPM packages? • Hacker News Board

Re: Ask HN: How do you security-audit external software using NPM packages?

#81

Post by AKluge » Thu, Nov 04, 2021, 9:12 PM UTC

bjpirt wrote: post #22

We've been using trivy [1] to audit the container builds we've been producing for a relatively security focussed project. As well as scanning for OS package level vulnerabilities it also scans for reported vulnerabilities in NPM packages. Works well for us. But the other complementary approach is to lock down other things - so for example, if you're running in a container, make sure that container can only talk to th…

It is also useful to keep track of entries in a vulnerability database for some of the more "enterprisy" dependencies https://nvd.nist.gov/

Running a pen test against web apps can also be educational and amusing. ZAP is highly customizable, so you can extend it to cover particular areas of concern. https://www.zaproxy.org/getting-started/

Re: Ask HN: How do you security-audit external software using NPM packages?

#82

Post by m0zg » Thu, Nov 04, 2021, 10:54 PM UTC

dncornholio wrote: post #73

PeterisP wrote: post #62

Earlier quoted context omitted.

A quantitative difference - in other programming languages you usually use a very limited number of dependencies, and the organization can follow every individual dependency that's used in production, knowing which versions you are using and tracking and monitoring their releases/notifications/changelogs as part of their software inventory. Like, a random quite large project that I recall had 10 dependencies from thr…

Sure but this problem is not mutually exclusive to npm. Python has pip, Rust has crates, Ruby has gems.. The fact that other languages have fewer dependencies, is (imo) probably because there aren't many dependencies uberhaupt? My argument by the way, is that many dependencies is a feature, not a bug. And the developer probably looked at you like that because he thinks you have no trust in his ability to pick depende…

Folks who publish stuff to PIP had the good sense to not require a hundred different other dependencies for each module they publish there. So it is tractable to just go through your entire transitive closure and ensure you're not including something you don't want.

And also, just because something is "hard" is not an excuse to just ignore it. NPM devs should be more aware of this issue, and make design decisions that improve the situation, such as, for example, not including a dep just to use a single function (the dep, by the way, might pull in 10 other deps, each of which could pull in some more). DRY is not a religious maxim, it's OK to do it to reduce "bushiness" and improve the predictability of the dependency graph.

Re: Ask HN: How do you security-audit external software using NPM packages?

#83

Post by WA » Fri, Nov 05, 2021, 8:58 AM UTC

KronisLV wrote: post #19

orangepanda wrote: post #6

Is there really anything better than `npm audit`, even with all its faults? Any relatively popular and well tested library will pull in dozens of dependencies. $ du -hs node_modules 289M node_modules Yeah no...

> Yeah no... That is only a valid stance to take while you're developing most of the "regular" software out there, but once you start dealing with finance data in an industry that's highly concerned with compliance and security you might get more demands forced upon you in regards to what you can or cannot do. That's not to say that there exists a better auditing mechanism, short of allotting a large amount of your t…

I think I just read half of your blog. Good stuff in there, keep it up.

Re: Ask HN: How do you security-audit external software using NPM packages?

#84

Post by richardwhiuk » Thu, Nov 11, 2021, 11:29 AM UTC

tompazourek wrote: post #75

richardwhiuk wrote: post #59

Earlier quoted context omitted.

You want to have a file specifying your dependencies, and a file specifying your currently locked set - e.g. Cargo.toml and Cargo.lock, or Gemfile and Gemfile.lock, or pyproject.toml and poetry.lock You'll then want tooling to periodically update your locked dependencies, so that you pick up fixes to security vulnerabilties. That wants to go through your CI.

This is a double edged sword. Because on one hand, you do pick up hotfix patches, but on the other hand, you are possibly bit more exposed to supply chain attacks. Any ideas on how to balance that out? Or should we just not consider supply chain attacks to be a real threat?

Mirror the upstream, and as part of mirroring, do an automated security analysis of your dependencies.

Sandbox your dependencies.

Run automated security vulnerability testing on your program, looking for rogue behaviour.

Require code signatures on dependencies.

Identity security critical components and audit them.

Re: Ask HN: How do you security-audit external software using NPM packages?

#85

Post by chha » Thu, Nov 11, 2021, 1:46 PM UTC

TheRealBrianF wrote: post #69

Sonatype Lifecycle is designed to analyze a built package and figure out what's inside it, specifically when there aren't manifest files to tell you what's -supposed- to be there. It can obviously do a lot more, but the analysis is designed to solve the exact problem you're describing. https://blog.sonatype.com/mapping-the-javascript-genome-for-...

Yeah, currently in the process of evaluating Lifecycle, Firewall and Repository. Impression so far is great, and coming from an org where everything is blocked by default having these tools in place is night/day for us...