Show HN: Vuln Cost – immersive VS Code extension to surface vulnerabilities

I think these sort of tools are detrimental to the security of apps and developers that use them.<p>1. They often treat all vulns the same and do almost nothing to let a dev know if they are actually vulnerable or how bad a vuln really is (and no, just a pure CVSS is not good enough).<p>2. They lead to the idea that fixing vulns is just updating the dependencies. If you have enough vulns in your dependencies that you need it visualized in your IDE then the problem is how you choose dependencies or how many you have, not keeping them up to date.<p>3. Updates themselves are not always a safe bet since they bring in unknown code, so an update should not be treated as a silver bullet for fixing vulns without checking the code or actually trusting the authors.<p>4. Just like some of snyks blogposts (like <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19255603" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19255603</a>) they lead to more hysteria and security theater than productive work.<p>In my experience all this leads to security fatigue and people not taking the profession or the work done seriously.

This made me curious what type of vulnerabilities were in something like Lodash and the answer was mostly prototype overwriting:<p><a href="https:&#x2F;&#x2F;snyk.io&#x2F;vuln&#x2F;npm:lodash" rel="nofollow">https:&#x2F;&#x2F;snyk.io&#x2F;vuln&#x2F;npm:lodash</a><p>It’s nice to see the Snyk project contributing patches back into major open source projects, not just highlighting them. Even if the threat model is relatively mild for an average dev like myself working in a controlled environment, despite the fact the vuln gets marked as severe (don’t get me wrong, it is still important for the larger OSS projects that are widely deployed to a variety of environments like lodash).<p>I’ve become far more careful updating JS libraries as most frontend projects have thousands in their package.json and I’ve had countless deployment issues getting ground down once the dependencies try to update in production, even though they worked fine locally. We have protocols to catch stuff like that but it’s still a headache that often takes far more effort than it’s worth to have a few patches (same with keeping a Docker clone of production locally which is another nest of problems). So I try to keep updates to dependencies like that contained in their own commits which can be rolled back, and not part of other feature branches or fixes.<p>I don’t have this problem in other languages nearly as much as JS using NPM&#x2F;yarn. So I tend to be far less eager to run ‘npm audit’ than I used to.

I wish synk (and npm audit) would do a better job of providing simple explanations to when these vurnabilities actually pose a threat. It&#x27;s impossible for devs to keep up with the constant flood of vurnabilities. Does it matter if a dependency that I&#x27;m use in my build tooling is open to reDos? I honestly do not know because I don&#x27;t have time to study each of these issue. Instead I just try to upgrade as often as possible, but maybe not as often as I should if I knew there were actually security holes in my runtime application

This is actually something cool ! Good job !

Awesome! I&#x27;ve moved away from JS to Go recently, but this is sure really useful for frontend stuff.

Terminals have a HUD problem. Too much information and it will distract the real issues. Too little info and you might miss something.