
Show HN: Vuln Cost – immersive VS Code extension to surface vulnerabilities - lirantal
https://snyk.io/security-scanner-vuln-cost/
======
SahAssar
I think these sort of tools are detrimental to the security of apps and
developers that use them.

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).

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.

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.

4\. Just like some of snyks blogposts (like
[https://news.ycombinator.com/item?id=19255603](https://news.ycombinator.com/item?id=19255603))
they lead to more hysteria and security theater than productive work.

In my experience all this leads to security fatigue and people not taking the
profession or the work done seriously.

~~~
bastijn
I'm mixed between nodding my head in this and finding arguments against it.
For myself, I would absolutely see your points and agree to them but when I
think about the engineers inside the company at scale I'm seeing it's worth. A
large part of our company comes from hardware or more traditional console
languages like c/c++/c#. Now switching to .net core, typescript and the whole
open-source ecosystem is something they just are becoming familiar with. This
extension would certainly make them aware of the impact of their choices.
Raising awareness about the implications of taking in that third party
dependency the moment they do it.

~~~
SahAssar
> Raising awareness about the implications of taking in that third party
> dependency the moment they do it.

Sure, but if that was the goal then I think it should show that a package has
"578 subdependencies with 935 authors that have had 7681 vulns that took an
average of 67 days to be resolved. No currently active vulns (that we know
of...) though!"

Currently I think it more encourages shifting the blame to the tool and I
think some engineers would say something along the lines of "well, it didn't
show me any vulns when I installed the package, so it should be fine, right?"

Taking on deep or complex dependencies should be treated as code that needs to
be maintained in the long run, not as a one-time decision.

When a vuln appears in either a PR or in released code the checks in CI/CD
should alert and refuse to build that release or approve that PR.

~~~
bastijn
Of course, yet it starts with awareness. Would love if the extensions would
also show the number of child's, number of authors, if it has an active
community, the license, and more info that you use to make the decision. Then
again, we would also need the licenses of the children, their activity etc.
It's a zoo out there these days. Packages that are licensed MIT have children
that are GPL licensed. One package dragging in 200 more, leading to famous
left-shift debacles and maintenance hell. Meanwhile support periods are being
lowered to 1-3 years, even on big projects.

Another issue we run into is different libraries using different packages
which depend on the same package down the line but a different version which
do not work together.

So yes, I wholeheartedly agree that one must think before taking in a
dependency. Especially if you just took it because a nice stackoverflow.com
answer said so and you are going to use 1% of the package.

Our build already immediately flags SOUP that is brought in but not assessed
yet. We had it failing for a while but that was too much of a barrier for
engineers. CI/CD scans for vulnerabilities using tools like whitesource or
blackduck. Tools like fortify and sonarqube run amongst many more.

All leading to better code, definitely. Yet, at a cost. Haven't found the best
set of 'rules' yet what to allow and what a practical choice is today. Keeping
velocity at the right quality.

------
dmix
This made me curious what type of vulnerabilities were in something like
Lodash and the answer was mostly prototype overwriting:

[https://snyk.io/vuln/npm:lodash](https://snyk.io/vuln/npm:lodash)

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).

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.

I don’t have this problem in other languages nearly as much as JS using
NPM/yarn. So I tend to be far less eager to run ‘npm audit’ than I used to.

------
cjonas
I wish synk (and npm audit) would do a better job of providing simple
explanations to when these vurnabilities actually pose a threat. It's
impossible for devs to keep up with the constant flood of vurnabilities. Does
it matter if a dependency that I'm use in my build tooling is open to reDos? I
honestly do not know because I don'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

~~~
danenania
Yeah, somewhere in the reporting/auditing workflow, there should probably be a
flag distinguishing whether vulnerabilities are actually dangerous in a
devDependencies context (they rarely are). I find that jest and webpack
especially generate tons of these irrelevant "vulnerabilities" and it's really
annoying. It's a security issue too since it leads people to start ignoring
the audit output.

~~~
L84Dinner
I work on this project, so I'm biased, for sure, but why not take a gander at:

[https://github.com/sonatype-nexus-
community/auditjs](https://github.com/sonatype-nexus-community/auditjs)

By default we exclude devDeps (allowing you to run that later). The project
functions off EXACTLY what you have installed in your node_modules, so it's a
pretty accurate look at your actual risk profile. You can run it with --dev to
get a look at your dev Deps, but we tailored it by default to your "prod risk
profile". The notes y'all make are pretty much why. Every Dev Dep in the world
seems to use lodash, so yeah, we get it, it can be prototype polluted, tell me
what my actual risk is!

~~~
danenania
Nice, will check it out!

------
saadalem
This is actually something cool ! Good job !

~~~
lirantal
ooh thanks! would be really happy to capture any extra feedback if you have
ideas for what to improve

------
pojntfx
Awesome! I've moved away from JS to Go recently, but this is sure really
useful for frontend stuff.

~~~
L84Dinner
If you are doing Golang development, you might check out this project:
[https://github.com/sonatype-nexus-
community/nancy](https://github.com/sonatype-nexus-community/nancy)

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

