Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Npm Audit: broken by design?

overreacted.io

Post reply on HN
Print view View original

61–70 of 268 posts

Re: Npm Audit: broken by design?

#61

Post by scottfr »

dale_glass wrote: post #20

It's a tricky problem to solve. Ideally you'd want to show only relevant alerts, but... how? You'd need to know which kind of errors are relevant for a particular project, but that'd require solving the halting problem. This is made much worse by that it's JS. Some libraries have an enormous complexity and attack surface. Take a database interface -- there probably is a vulnerability in some obscure corner the typica…

You just need a way for a package maintainer to flag a vulnerability in a dependency as a non-issue that does not affect that package's use of the dependency.

In Dan's twitter thread, he calls this out as a viable solution.

Re: Npm Audit: broken by design?

#62

Post by mrweasel »

quintex wrote: post #6

As someone who only had just gotten into front end programming after years of backend work, npm has been a nightmare. I haven't experienced the same level of frustration with other package managers (pip, cargo, go mod, etc) as I have with npm. Is yarn the better option? What is our path forward?

I basically do no frontend development, partly due to tools npm and the current frameworks, I simply cannot wrap my head around it. I do help run a few modern javascript application however. Even a minimal app will pull in 1000+ dependecies, and I think that’s the problem.

It simply don’t happen in Python, Go or Rust (or even Java) because the languages comes with a rich standard library. Javascript comes with just the basics, everything else is a dependency. It’s not uncommon for people to audit their dependencies in Python or Go, but you pull in maybe 10 or 20. A basic Javascript app easily pull in 100 times that, how are you suppose to deal with that?

Re: Npm Audit: broken by design?

#63

Post by michaelt »

raziel2p wrote: post #16
mbesto wrote: post #13

> this “vulnerability” is absurd in this context Yes that's exactly the point. The audit tool has no awareness of the context and nor do the people who create severities. If severities were absolute then there would be no reason for anyone to review them. You would simply upgrade your libraries and be done with it, but that can't always be achieved nor may make business sense. I do agree with the author's note about…

Exactly. Why does it matter if it's absurd in this context? Just upgrade it to be on the safe side. Asking vulnerability databases to judge whether vulnerabilities are safe in devDependencies or not is a ridiculous idea, even more so when you consider that the line between static and dynamic have gone blurry long ago.

> Why does it matter if it's absurd in this context?

If I wanted shitty false alarms about bogus security issues, I'd get a PCI-DSS audit.

Re: Npm Audit: broken by design?

#64

Post by x0x0 »

esprehn wrote: post #30

Dan isn't the first person to notice: https://www.voitanos.io/blog/don-t-be-alarmed-by-vulnerabili... We disable [1] audit entirely because it's not a good default behavior within a monorepo. It spams the hundreds of developers with the list of "vulnerabilities" on every install, but only a few folks should really be upgrading packages. We then run audit in non-blocking CI and track the total number of issues and mos…

We also wanted to use npm audit in our CI process so, instead of humans being careful, we could assert any known CVE stops a staging or prod deploy. Very annoyingly, npm audit doesn't have ignore functionality, at least when I was last forced to use it. I had to hack something together with bash scripts.

For vulnerabilities that we determined weren't an issue ever (vuln in frontend framework we didn't use), or weren't high priority enough to P0 through, we needed some way to ignore either permanently or temporarily specific vulnerabilities.

Given the enormous dependency sets eg react create, you'd think the tools would be better at managing them.

Re: Npm Audit: broken by design?

#65

Post by jrochkind1 »

> Inline all dependencies during publish… From a maintainer’s point of view, the upsides are clear: you get faster boot time, smaller downloads, and — as a nice bonus — no bogus vulnerability reports from your users.

And when you inlined a version that later really does have a vulnerability, it is not easily flagged or fixed by your consumers.

The tension between "upgrades (especially of indirect dependencies) might break" and "upgrades (especially of indirect dependencies) might be necessary to fix bugs or patch security vulnerabilities" is real. There is no magic bullet to get around it. There are practices to try to balance it -- which generally involve ecosystem-wide commitment to backwards compatibility, reflected in semantic versioning (and minimizing major releases).

That npm dependency trees are often insane doesn't help though. I'm not totally sure why they are so insane, but I increasingly think that npm's ability to have multiple versions of same dependency in the dependency tree -- often seen as a huge advantage over other platforms -- is in fact part of the problem. It makes the dependency tree even more insane, and it also accomodates a false belief that it's fine to lock to very specific versions of dependencies -- because it won't prevent other dependencies from co-existing in tree with other conflicting requirements after all. Which then accomodates a false belief that dependency maintainers don't need to worry too much about backwards compatibility, after all consumers can just lock to specific working versions... and now we wind up with insane dependency trees which depend on vulnerable versions in ways that require a whole bunch of releases to resolve.

Re: Npm Audit: broken by design?

#66

Post by ratww »

gentleman11 wrote: post #43

npm is a bit nuts on its own. I started learning react this year and the course I'm taking had me install that create react app module or similar. It dragged in 1700 dependencies, and the folder for a hello world app was almost 90mb iirc. How can you possibly pretend you have any control over your app or it’s security in that situation?

Yeah, that’s the biggest issue, IMO.

Even a simple app with only React as a production requirement will have dozens of issues a month.

There are some packages that don’t have as many dependencies such as Typescript or Prettier, but that’s not enough, since the most popular bundlers have hundreds of of dependencies.

No matter how careful you are, you get flooded by security issues.

Re: Npm Audit: broken by design?

#67

Post by genezeta »

The title is "Broken by Design". Then the author proceeds to explain how the design is actually reasonable and meant to work ok, and how the problem lies in the relevance and context of the vulnerabilities reported.

That doesn't seem to be the meaning of "broken by design".

Re: Npm Audit: broken by design?

#68

Post by cphoover »

So currently the algorithm is... check (dev)Dependencies and descendent/transient dependencies to see if they exist in a security advisory database if they do, highlight and surface them to the user.

What are alternatives? A way to ignore or mark a dependency as safe? Could this be abused if an author can just mark a dependency as safe?

Or perhaps, actually analyze syntax with a tool like ESLint (parse -> AST -> validate) to check that dangerous parts of libraries are not in use? This solution comes with it's own complications. Who is authoring these validations?

Perhaps there are other strategies I'm not aware of.

Re: Npm Audit: broken by design?

#69

Post by JonathonW »

esens wrote: post #60
nkozyra wrote: post #59

Earlier quoted context omitted.

> A regex "denial of service" "vulnerability" could be important, if it shows up in code that processes untrusted input from end users. But in this context what's the end result? Chrome locking up on the end user's (attacker's) machine? Again, an "attacker" doesn't have access to the source code for distribution. By inputting bad regexp data they're only DOSin themselves, no?

Could be in a service on a server, which in this case a RegEx DOS could lock the server for all users.

Or if a JS frontend takes in input that comes from other users-- something like forum post titles or content.

That's "just" a browser freeze for end users, but still a potential DOS vulnerability if it's in the application's critical path.

Re: Npm Audit: broken by design?

#70

Post by mmis1000 »

city41 wrote: post #57
raziel2p wrote: post #16

Earlier quoted context omitted.

Exactly. Why does it matter if it's absurd in this context? Just upgrade it to be on the safe side. Asking vulnerability databases to judge whether vulnerabilities are safe in devDependencies or not is a ridiculous idea, even more so when you consider that the line between static and dynamic have gone blurry long ago.

> Just upgrade it to be on the safe side Upgrading a dependency can go anywhere from trivial to absolute nightmare. Usually somewhere in the middle where it takes time and effort to do right. A typical JS app nowadays has hundreds if not thousands of dependencies. I'd love to see a world where "just upgrade" is reasonable advice, but we are not there.

Or even undoable because it is a dependency of dependency, that vulnerable major version is no longer maintained, and your dependency heavily relies on specific feature of that major version.

At this point, what should you do now?

The author of dependency of dependency is probably not going to touch it because it is fixed in the new major version. The author of dependency is probably also not going to fix it instantly because it requires major rewrite.

Post reply on HN