What NPM should do to stop a new colors attack

Re:What NPM should do to stop a new colors attack by mcintyre1994 on Tuesday January 11, 2022 @02:48AM (#29888737)

We used to use npm audit at my last job, and it’d regularly flag dependencies 20+ layers deep - usually with something like create-react-app or jest at the top, and some trivial obviously not actually a problem issue at the bottom.

The resolver tool we used couldn’t fix dependencies that deep even when there were fixed versions available. And since their internal processes didn’t use the same audit tooling, Facebook devs would often close issues requesting dependency upgrades to fix those not actually security issues. I think Dan Abramov wrote a post on overreacted about it at some point too. I’m not convinced any of the time we spent on those issues was well spent to be honest.

[ Parent | on HN ]

Re:What NPM should do to stop a new colors attack by woutr_be on Tuesday January 11, 2022 @03:56AM (#29889132)

There's obviously very valid security concerns sometimes. We didn't use npm audit, but an external tool. And often it would highlight things like "use https", and when looking at which line, it was just a comment that referred to an external link.

Obviously a non-issue, but you still had to verify, and document everything. Best practice would be that we ran this scan on every commit, but the scan took about 15-20 minutes. It just ended up being something that was part of our release process, with the obvious danger of breaking our application right before release.

All in all, it stopped me from relying on third party modules, and tried to use as much vanilla code as possible.

[ Parent | on HN ]