At a previous job, we had to refactor our entire front end build system from Rollup(I believe it was) to a custom Webpack build because of this attitude. Our FE process was completely disconnected from the code on the site, existing entirely in our Azure pipeline and developer machines. The actual theoretically exploitable aspects were in third party APIs and our dotNet ecosystems which we obviously fixed. I wrote like 3 different documents and presented multiple times to their security team on how this wasn't necessary and we didn't want to take their money needlessly. $20000 or so later (with a year of support for the system baked in) we shut up Dependabot. Money well spent!

Very early in my career I'd take these vulnerability reports as a personal challenge and spent my day/evening proving it isn't actually exploitable in our environment. And I was often totally correct, it wasn't.

But... I spent a bunch of hours on that. For each one.

These days we just fix every reported vulnerable library, turns out that is far less work. And at some point we'd upgrade anyway so might as well.

Only if it causes problems (incompatible, regressions) then we look at it and analyze exploitability and make judgement calls. Over the last several years we've only had to do that for about 0.12% of the vulnerabilities we've handled.

My favorite: a Linux kernel pcmcia bug. On EC2 VMs.

the rating is nonsense anyway, which one actually applies to code you run varies wildly

9.x vulnerability might not matter if the function gets trusted data while 3.x one can screw you if it is in bad spot