Don't Mind The Fire
It's only in the rooms you're not in, so you should be fine to keep living next to those oily rags. Hearing JS developers moaning about TypeScript's "restrictions" and npm audit's "constant messages" is terrifying.
The open source Go programming language, developed by Google, has added support for vulnerability management in a way designed to preserve programmers' patience. The Go team recently set up a website at vuln.go.dev to host a selection of known vulnerabilities in packages that can be imported from public Go modules. These …
If there is a vulnerability in the way OpenSSL generates RSA keys, but I only ever use ECDSA in my application, the vulnerability doesn't affect me, and I don't need to upgrade (and have to rerun all my expensive regression tests).
Now maybe OpenSSL is overly complicated, and I would be better switching to LibreSSL or NaCl - but that's a much bigger change, and OpenSSL _has_ had a lot of eyeballs on it (at least since HeartBleed).
The same will apply to go modules.
From a technical perspective I agree, if you're not using the vulnerable code paths, then it is of no concern. What I take issue with is the idea of stripping away known vulnerable design pattern alerts for the sake of not bothering the developer. The point of these curated CVEs is basically "developers aren't actually fixing the bugs, because there's so many of them, so let's pretend there's less so they actually fix them"
I agree. Sort of. In some cases. But it's not an absolute thing.
Some time ago, I worked on a software that ran stochastic simulations of a physical process. In order to do this, it had to generate pseudorandom numbers. I imported a library that generated pseudorandom numbers, and some time later I got a warning that the RNG in that library was not cryptographically secure, i.e. if you used it for cryptography, it might weaken the cryptographical algorithm.
Buuuut, I wasn't using it for cryptography. The project had absolutely nothing to do with cryptography. The project needed fast random numbers, much more than it needed good quality random numbers, and all the "secure" alternatives were noticeably slower.
This is just one example. An entire category of warning happened when we used a little bit of a library that happened to use something bad to implement other bits that we never even touched, e.g. there was a library that did something we used, and also had the option of running as a server to do it over a web socket, and of course that pulled in all sorts of dependencies with all sorts of networking issues - but we never used the server functionality anywhere.
Overall, we spent quite some time to fix security issues that were never issues to begin with. Surely that's something that can be improved.
Seems like they are simply looking to avoid false positives, so that devs don't need to chase those down.
This is a sound approach :
"Govulncheck analyzes your codebase and only surfaces vulnerabilities that actually affect you, based on which functions in your code are transitively calling vulnerable functions ... "