4 ms·

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

86 points by lirantal 7y ago

z3t4 7y ago
Terminals have a HUD problem. Too much information and it will distract the real issues. Too little info and you might miss something.
axiosgunnar 7y ago
Is Snyk a YC company or why is so much content marketing spam by that company tolerated here?
- danpalmer 7y ago
  This is just good regular marketing from a company who happen to market to developers. If it had no value then it would be fine to complain, but they’re giving away a free tool, it’s definitely worth something. I’ve yet to see a post from Snyk that wasn’t at least “not bad”, and plenty have been much better than that. This is no different to GitLab’s marketing - huge release announcements every month, or Cloudflare’s technical blog posts, but I don’t see complaints about them.
  - lirantal 7y ago
    @danpalmer appreciate that. If and when you try it out and have any feedback I'd be happy to capture that and see how it works with our plans for it.
    - danpalmer 7y ago
      My only feedback would be that I'm not a server-side JS developer, so I don't feel it will have that much signal to noise. It's JS only, and the only JS I do is frontend and a little tooling. In general, I find that for JS that basically gets compiled at build time and used statically on a site, or things like linters that don't do any networking and are run only in dev/CI, the scope for vulns is pretty low. It's mostly just self-denial-of-service, because it's standard practice to not trust the client for anything anyway, so all the canonical security is server-side. There's obviously a vector for packages that have been backdoored and taken over by an attacker, but I'm not sure having that in my editor would help because I'd have to have the file open to see it, vs getting a notification about it from GitHub security (or Snyk's service I guess?). For new packages I'm adding, I would be researching it on NPM (for JS) anyway. I mostly write backend Python, and I'd probably use it for that. The fact that there's a more useful notion of a vuln means I want to see them more (it's more of a spectrum rather than safe vs backdoored in the frontend case).
dmix 7y ago
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.
saadalem 7y ago
This is actually something cool ! Good job !
- lirantal 7y ago
  ooh thanks! would be really happy to capture any extra feedback if you have ideas for what to improve
pojntfx 7y ago
Awesome! I've moved away from JS to Go recently, but this is sure really useful for frontend stuff.
- L84Dinner 7y ago
  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
cjonas 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      Nice, will check it out!
SahAssar 7y ago
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 7y ago
  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 7y ago
    > 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.

86 points by lirantal 7y ago

z3t4 7y ago

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

axiosgunnar 7y ago

Is Snyk a YC company or why is so much content marketing spam by that company tolerated here?

danpalmer 7y ago
This is just good regular marketing from a company who happen to market to developers. If it had no value then it would be fine to complain, but they’re giving away a free tool, it’s definitely worth something. I’ve yet to see a post from Snyk that wasn’t at least “not bad”, and plenty have been much better than that. This is no different to GitLab’s marketing - huge release announcements every month, or Cloudflare’s technical blog posts, but I don’t see complaints about them.
- lirantal 7y ago
  @danpalmer appreciate that. If and when you try it out and have any feedback I'd be happy to capture that and see how it works with our plans for it.
  - danpalmer 7y ago
    My only feedback would be that I'm not a server-side JS developer, so I don't feel it will have that much signal to noise. It's JS only, and the only JS I do is frontend and a little tooling. In general, I find that for JS that basically gets compiled at build time and used statically on a site, or things like linters that don't do any networking and are run only in dev/CI, the scope for vulns is pretty low. It's mostly just self-denial-of-service, because it's standard practice to not trust the client for anything anyway, so all the canonical security is server-side. There's obviously a vector for packages that have been backdoored and taken over by an attacker, but I'm not sure having that in my editor would help because I'd have to have the file open to see it, vs getting a notification about it from GitHub security (or Snyk's service I guess?). For new packages I'm adding, I would be researching it on NPM (for JS) anyway. I mostly write backend Python, and I'd probably use it for that. The fact that there's a more useful notion of a vuln means I want to see them more (it's more of a spectrum rather than safe vs backdoored in the frontend case).

dmix 7y ago

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.

saadalem 7y ago

This is actually something cool ! Good job !

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

pojntfx 7y ago

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

L84Dinner 7y ago
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

cjonas 7y ago

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 7y ago
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 7y ago
  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 7y ago
    Nice, will check it out!

SahAssar 7y ago

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 7y ago
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 7y ago
  > 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.