The problem with Snyk and other automated vulnerability detection tools is the rate of false positives. For my open source library, the false positive rate so far (over many years) has been 100%. Not one of the many reports pointed to a single exploitable vulnerability in my library.
The reason is that a lot of vulnerabilities are context-specific. For example, a common one in JavaScript is Object prototype pollution; this is not an issue at all if the affected function is only used with trusted input.
Just because a function is vulnerable under a certain specific condition, it doesn't mean that it's generally vulnerable.
That's like saying that chainsaws have a critical security vulnerability on the basis that if you put your foot in front of it, you will be badly harmed... and then you use this as justification to warn millions of tree removal experts (and their customers too) all around the world that their businesses are critically vulnerable and fundamentally unsound because they happen to use chainsaws.
The other common problem is when it flags a vulnerability with a specific function within a library, but that function is not actually used by the project. It's not fair to label all downstream projects as vulnerable on the mostly false assumption that the project actually uses the vulnerable part of the code.
I think Snyk does this because it gets them attention and that's how they turn a profit, but they have to get wiser because this strategy is compromising the quality of their service.
The reason is that a lot of vulnerabilities are context-specific. For example, a common one in JavaScript is Object prototype pollution; this is not an issue at all if the affected function is only used with trusted input.
Just because a function is vulnerable under a certain specific condition, it doesn't mean that it's generally vulnerable.
That's like saying that chainsaws have a critical security vulnerability on the basis that if you put your foot in front of it, you will be badly harmed... and then you use this as justification to warn millions of tree removal experts (and their customers too) all around the world that their businesses are critically vulnerable and fundamentally unsound because they happen to use chainsaws.
The other common problem is when it flags a vulnerability with a specific function within a library, but that function is not actually used by the project. It's not fair to label all downstream projects as vulnerable on the mostly false assumption that the project actually uses the vulnerable part of the code.
I think Snyk does this because it gets them attention and that's how they turn a profit, but they have to get wiser because this strategy is compromising the quality of their service.