couldn't agree more- we built Dassana [1] so solve this problem by adding context to security alerts. Currently we support AWS Config/GuardDuty alerts but had been thinking of adding context to vuln scan results too.

[1] https://oss.dassana.io/

I mean, you don't have to use the scanning tools if you'd prefer not to know.

It’s not about not wanting to know, it’s about wanting to know about real security issues and being buried in low quality reports which do not need to be addressed.

The problem is it gets weaponized. If you're unlucky you have a client who runs a scan naively on your software and demands these get addressed as critical priorities under SLA.

I'm sure there are plenty out there with managers who will just run the report and demand these "security issues" are fixed and won't understand an explanation on why it's not relevant.

This is a silly objection in my opinion - clients demand unreasonable things all the time. Its up to you to write a reasonable SLA that protects yourself.

Dont get me wrong, i wish npm audit was better. But unreasonable people will be unreasonable regardless of the tools they have access to.

The risk that a person could potentially write an infinite while loop and commit it to a codebase is about the same as the threat posed by the DoS "vulnerabilities" that seem to have completely overrun the NPM audit system. Noone wants to know about the former risk.

Even so, you should just upgrade to a secure version anyways. Wanting to stick to an old version with vulnerabilities in it seems like something you shouldn't want to do.

If anything you should be promoting easier upgrades for the packages affected by these security problems.

If only it were so easy. Typically, you're not using these dependencies directly. You use something that uses them. And it's not compatible with the "secure" version.

This sounds like a bigger problem than whatever issues exist with npm audit. Security updates should not be hard to do. When a vulnerability drops that impacts you project severely it should be easy to get to a secure state. Having to deal with working with downstream projects or a secure version being incompatible sound like big problems with the ecosystem.

> vulnerability drops that impacts you project severely

well if it's a regex ddos in build tooling, it doesn't "impact your project severly". That's the entire point of this thread

I never said it did. I am saying that if it's hard to patch irrelevant issues it is also hard to patch relevant issues. The ideal would be it is easy to patch all issues so you can always just upgrade to a safe version.

Sure, but that's not something you can fix at the ecosystem level, it requires effort from the package maintainers and/or researchers to backport these fixes to older versions. And if the fix requires effort from the maintainers that is not actually very benefical to anyone (i.e. the vulnerability does not actually impose a security risk) then we are back to the question if it's really worth it. The effort has just been moved from the consumer to the library author.

Just because npm audit says something doesn't mean it has any impact at all. Most of its outputs are false positives.

But when it's not a false positive, when it actually impacts your project it should be easy to update.