Hacker News Reader

Comment by rester324 | Hacker News Reader

I think this would be a fair assessment, if the security advisory would be true.

Since it's most probably false, the implications you refer to remain hypothetical, while the cost of cleaning up after npm's decision are measured in real M$s. And I think that's the real issue here.

I am not saying that we should give up on security altogether, but now there is so much toil attached to managing security, compliance and such aspects of the development lifecycle, that at some point managing all these aspects will outweigh all productivity a dev can bring to the project.

It's admittedly a hyperbole, but at that point the whole development procedure would simply become a pointless exercise without any benefit to anyone.

View on HN

So I understand that in NPM world, spurious security advisories are common and that the tooling will constantly have you run "fix" commands without real reasons? That's bad and it would explain this lax security culture oozing from it.

So the damage is already done, and real security problems will never be properly addressed. One must come to the conclusion that NPM has to be avoided at all cost if security is a concern at all. Additionally, one must make sure that when onboarding a developer coming from the NPM world into a sane project, they have to be properly de-conditioned with regards to security advisories.

Which is a wrong conclusion if I understand you correctly.

You can just host your own package repo and run your own verification to confirm if a package is indeed vulnerable or not. If it's not, you can just continue your operations as usual, regardless of what NPM (the company, the host provider, not the CLI tool) does in the background.

Not if your IT dept is lazy and has to meet some sort of security compliance, then they force the task on you to develop this “own package repo” or just use Dependabot and force your team to create a quarterly ticket to rake the security bugs out of the code.

The fix command just upgrades or downgrades the package to the first-known-unaffected-version. Meaning if “audit” api is unaware of a modern version for the fix (due to cache or human latency), then you can be downgraded to when the version before the bug was introduced, for ex. 25 major versions prior or something.

Reply on news.ycombinator.com