3 ms·

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

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.

rester324 1y ago
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.
- righthand 1y ago
  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.
righthand 1y ago
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.