5 ms·

Ruby Security Have You Not

96 points by vasinov 12y ago

deleted 12y ago
[deleted]
chc 12y ago
I can't help but feel that this could also be written as "How secure are Ruby and Rails apps? About as secure as all other apps." In my experience, vulnerabilities are pretty much endemic to software that has not been hardened by experts.
- dperfect 12y ago
  I agree. The fact that a large number of Ruby/Rails apps fall behind in terms of keeping dependencies up-to-date speaks more to Ruby's adoption than to its inherent insecurity. Without comparing these figures to other languages/frameworks (and accounting for flaws in completely custom-built apps), it's hard to draw any real conclusions here.
- danudey 12y ago
  I think the big thing here that threw me for a loop is just how many gems are pulled in by projects. 133 seems like a ridiculous amount of dependencies for a single project. Our entire company runs on Python in the backend and we don't even have 50 (and that's including ones I use for command-line utilities or corncobs, for example, which aren't in our public-facing software). Even if the Python modules we have had the same number of vulnerabilities as gems, our exposure for a given system would be 1/10th, just from not using so many external libraries. Couple that with the fact that many of those gems are outside of end-user control, of generally unknown quality, might only be pulled in for one small piece of functionality, and might themselves depend on other gems which you weren't necessarily aware of and haven't necessarily vetted.
  - steveklabnik 12y ago
    A blank Rails app installs ~40 gems last I checked.
  - chc 12y ago
    I think part of it is that people tend to separate things out into lots of gems. For example, if you're using Ember in your Rails app, that's two gems right there just for that library. If you want to allow delegated authentication with the common providers (Facebook, Twitter, OpenID), that's like 10 gems. Your unit testing and error reporting comes from gems, your app server is a gem, every database you want to support is at least one gem, etc. It gets explosive, but it's really just an organization thing. One thing to keep in mind, though, is that not all gems are actually used at a given time. Your gems for testing, development and production all go in the Gemfile, but you're probably not going to install all of them on one system.
  - bstar77 12y ago
    Not all gems are created equal. Large amount of gems don't necessarily mean that they are arbitrarily included. In fact, it's often better to pull in a dependency for things that specialize in a particular task because they are more likely to have hardened security and better performance. The flip side is actually knowing that this "meme generator" gem you are using actually pulls in 50 dependencies, many of which are terribly implemented. I've seen this problem just as rampant in the Node.js and jQuery worlds. As developers, we should be as aware as possible of the state of our critical apps dependencies. I've recently gone through an app that had over 50 gem dependencies and reduced it to under 20. One thing that's probably not considered is that testing frameworks (rspec) have tons of dependencies that are not scoped to production. I'm not sure if these reports considered that.
  - GlennS 12y ago
    It would be interesting to know why this is. Are each of these dependencies really small on average? Or is there some big cascade of dependencies? Or is there a particular framework that's to blame? I've had a similar issue when using the Spring Framework in Java, where including it in your project at all brings a whole host of other (often not very good) libraries in. This is a problem in Java, which doesn't have any built in capacity for loading multiple versions of the same library. In Python, I suspect that I've been in a similar situation when using things like Pyproj, Numpy or Scipy, because those all depend on components written in C or Fortran. Perhaps next time I use any of those libraries I shall take some time to read more of the code and try to trace out what things they may be brining in.
    - ddebernardy 12y ago
      > Are each of these dependencies really small on average? Or is there some big cascade of dependencies? Or is there a particular framework that's to blame? All of that, really. For better or worse, scores of gems have dependencies. Rails and a few popular others add large dependencies that cascade to other dependencies at that — some large, some not. It's extremely rare to run into quality gems with very few if any dependencies. (Sequel comes to mind, and that's just about the only 1st-class gem I can think of in pure Ruby.)
    - chc 12y ago
      A lot of them really are small. There is a tendency for Ruby libraries to be separated into "core" and "feature" gems that you can pull in separately, For example, if you want to use DataMapper, you might be pulling in dm-core, dm-rails, dm-validations, dm-migrations, dm-timestamps, dm-postgres-adapter, dm-mysql-adapter, dm-is-searchable…
tkellogg 12y ago
It's neat (if not alarming) to see security metrics visualized like this. Nice work!
crazydoggers 12y ago
Unpatched Rails apps are found vulnerable until patched... news at 11.
- vasinov 12y ago
  I think the interesting part is how many unpatched, hence vulnerable, apps there are.
  - crazydoggers 12y ago
    But this article does not analyze that. It's only scanning CVE's and most have already been patched when the CVE is issued. Of the 53 mentioned for Rails for instance, all have been patched. This article is incredibly misleading.
    - vasinov 12y ago
      I don't understand... The article first analyzes apps that use a certain number of vulnerable gems. Sure, most of them are probably patched, but it doesn't change the fact that certain apps use old unpatched versions of these gems. The second part focuses on historical vulnerability data for Ruby gems. In what way any of it is misleading?
      - crazydoggers 12y ago
        > Sure, most of them are probably patched, but it doesn't change the fact that certain apps use old unpatched versions of these gems Why is that news?? That is true across every and all software platforms. > In what way any of it is misleading? Because the article assumes or implies the conclusion that there are a huge number of vulnerable Rails apps. The only way to discover that is to not simply count how many CVEs have been issued for each gem, but how many systems in production have not been patched. From the comments here, many people seem to assume this is an analysis of the number of unpatched vulnerable systems in production, which it most definitely is not.
        12y ago
hawleyal 12y ago
Nice graphs. Meaningless, but nice.
unreal37 12y ago
I am not a ruby developer, but it does seem shocking that 66% of all gemfiles contain a known previously-disclosed 5+ exploit. Yes, most software is flawed, but you would think once it's been reported, it would be fixed.
- spatten 12y ago
  The gems have probably been updated by the developers of the gem. The data used in the article contains a list of the versions being used in production by real app, not the latest versions released by the gem developers.
  - unreal37 12y ago
    Ah, thanks for the clarification.
  - vasinov 12y ago
    I think unreal37 meant "once it's been reported, it would be fixed [in the app]." As in updated.
  - klochner 12y ago
    Risk also depends on how you're using the gem. If it's a bug in a YAML parser but you're not loading YAML from untrusted sources, then it would be a false positive.
  - robotfelix 12y ago
    Yes, after seeing many familiar gems in the graphic I was almost surprised to see that hakiri gave my Gemfile.lock an 'all clear'. The should be able to calculate what percentage of these would still be vulnerable if fully updated - now that would be an interesting stat!
- phillmv 12y ago
  So, all software has two problems. First one is finding, reporting and getting vulnerabilities. Most people don't perform security audits. Most vendors take forever to reply back to security reports. Infuriatingly, many vendors will roll security fixes into the next major release instead of backporting patches and minor versions. The second one is about finding out about disclosed and patched vulnerabilities. Outside of larger institutions where you have someone whose job it is to worry over configuration management and subscribe to every mailing list, the ecosystem for disseminating this information is broken. That's why we've started the https://github.com/rubysec/ruby-advisory-db https://github.com/rubysec/ruby-advisory-db, at least for the Ruby ecosystem.
enraged_camel 12y ago
This doesn't surprise me, and I'm not even an experienced Rails developer. I think a big part of the problem is that there are a ton of gems that are simply hobby projects that gained traction and became popular. They were originally architected by enthusiasts, rather than experts. Some of these projects may also have been abandoned by their authors, but still in use because they may be the only way to accomplish a complex task or integration. You can't expect stuff like that to be very secure. You just have to think carefully about whether the risks of using them are worth the gains made from not having to implement the functionality yourself.
- hox 12y ago
  This can be said of any open source library, but it is unfortunately true that the average Ruby gem seems to be more hobby-grade than enterprise-grade. The fact of the matter is, if you are developing an application and are integrating 3rd-party code, always pay attention to what that 3rd-party code is, how well-maintained it is, and how the project has responded to bugs and vulnerabilities in the past.
  - midas007 12y ago
    Yup. I've done enterprise Rails consulting, which is almost a contradiction in terms. But it's possible and I've brought fixes like net ldap to work with AD. Edit: Can't take all the credit, client hacked together the first version but we managed to extract it for "the greater good." Also fun stuff like XML-RPC (Xen API -> gem xenapi, VMware (gem rbvmomi)), which wasn't bad and worked OOTB. Wished MS exposed their APIs as RESTful endpoints, because WinRM + gem winrm just doesn't cut it with some products... generated powershell run by an agent instead. For some products, even having the (.someextiforgot) files that describe the API, there's no MS docs on them, so lots of trial-and-error in PowerGUI to find the right objects and methods (Yuck).
    - hox 12y ago
      You sir are a saint. Dealing with net_ldap and AD was the bane of my existence for a while.
mratzloff 12y ago
This doesn't surprise me in the least, but the increase in 2013 is obviously due to increased security scrutiny, which is good so long as people act on that information. As a side note, I'd be interested to see a similar analysis of popular Java projects.
molf 12y ago
The graphs of Gem distribution and Vulnerability distribution are utter nonsense. You can't just measure your mean and standard deviation and expect a bell curve that fits those two parameters to correspond to your distribution. Especially if you cut off one of the tails.
- vasinov 12y ago
  Do you mind sharing how you would present this data?
  - blt 12y ago
    A histogram.
    - vasinov 12y ago
      Why do you think it would be better/more meaningful?
      - teraflop 12y ago
        The current graph is actively misleading because it misrepresents the data as following a (truncated) normal distribution when that's very unlikely to be the case. A histogram would show the actual distribution. The kind of graph being used here -- a "best fit" bell curve based on the sample mean/s.d. -- can be useful when overlaid on a histogram, to illustrate how closely the data can be approximated by a normal distribution. Without that context, it's essentially meaningless.
  - saraid216 12y ago
    Start with having a y-axis. That graph isn't a graph. It's just two numbers.
phillmv 12y ago
Hey! I'm one of the maintainers behind the Ruby advisory database: https://github.com/rubysec/ruby-advisory-db https://github.com/rubysec/ruby-advisory-db We're trying to build a common database for people building these tools; at the moment, trawling through CVE disclosures and various mailing lists is a largely manual process that we can reap economies of scale by pooling our efforts together. It's free and volunteer run. I would like to encourage you and anyone else reading this who is interested in bolstering the security ecosystem to consider using and contributing to the advisory database. It's the database that powers http://github.com/rubysec/bundler-audit http://github.com/rubysec/bundler-audit and (disclaimer: I made this) https://gemcanary.com https://gemcanary.com and the more people contributing the more we can all benefit from improving the ways we can notify end users of their vulnerable dependencies. Thanks,
- vasinov 12y ago
  Do you know of any apps like https://hakiri.io https://hakiri.io that automate security scanning and serve as a security monitor for any future disclosures? Also, how would one use bundler-audit if a Rails app is not actively maintained?
  - phillmv 12y ago
    Yeah, like I mentioned above the app I built (https://gemcanary.com https://gemcanary.com) automates disclosure notification, and I believe? https://codeclimate.com/ https://codeclimate.com/ may use the advisory database as well, but I do not know for a fact. There's a few others but they've slipped my mind at the moment. I use bundler-audit when performing security audits for clients. You could wrap it in a git commit hook and have it publish results, but to my knowledge no one's done it that way.
  - jamie_ca 12y ago
    I believe [Code Climate](https://codeclimate.com/ https://codeclimate.com/) will report vulnerable gem versions in your app. Their marketing page suggests that they also analyze how you use a vulnerable library to see if you're affected or not.
- 12y ago
midas007 12y ago
Generally: don't trust anything from the outside world or anything that can transit untrusted infrastructure, that means check types and sanitize values before passing along. Break loudly and quickly to get attention for a fix. Keep the codebase as tiny as possible too. Ruby: recompile with minimized OpenSSL 1.0.1+ (LibreSSL when possible) and with patches that improve Ruby's default OpenSSL security. https://gist.github.com/steakknife/8228264 https://gist.github.com/steakknife/8228264 https://gist.github.com/steakknife/10092587 https://gist.github.com/steakknife/10092587 https://gist.github.com/steakknife/10096008 https://gist.github.com/steakknife/10096008 For Rails apps: use brakeman as one part of security audit strategy For gem authors, sign them (please!): I wrote waxseal to make it dead simple [sudo] gem cert --add <(curl -L https://gist.github.com/steakknife/5333881/raw/gem-public_cert.pem) # adds my cert (do once) [sudo] gem install waxseal --trust-policy HighSecurity For gem users, find which aren't signed Add this to ~/.gemrc gem line: --trust-policy MediumSecurity or just if there's no gem: .... already: gem: --trust-policy MediumSecurity For anyone using git, sign your tags (git tag -s ...) and commits (git commit -S ...) por favor
- InAnEmergency 12y ago
  For what it's worth, --trust-policy has been broken since RubyGems 2.0.0 and will not be fixed until 2.3: https://github.com/rubygems/rubygems/issues/859 https://github.com/rubygems/rubygems/issues/859
steveklabnik 12y ago
It's possible some of these are false positives, at least with regards to Rails, as most of the recent vulnerabilities I can remember come with workarounds and patch files. Some people need to stay on a specific Rails version, but may have fixed the problem. I'm not ready to speculate which is more probable.
- vasinov 12y ago
  Yep, totally agree, that's why I added a post scriptum :)
  - steveklabnik 12y ago
    Ah! Missed it! My bad.
jusob 12y ago
More alarming than vulnerable gems is the the number oh high severity vulnerability found in Rails itself: http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-Rails.html?vendor_id=12043 http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-.... Compare this to Django (http://www.cvedetails.com/vulnerability-list/vendor_id-10199/product_id-18211/year-2013/Djangoproject-Django.html http://www.cvedetails.com/vulnerability-list/vendor_id-10199...) per year.
- techpeace 12y ago
  number of reported vulns != number of existing vulns
Glyptodon 12y ago
This article kind of confuses me - what does it mean for a gem do be 'secure' ? The idea of many gems being 'secure' or 'non-secure' is a non-sequitur. Obviously for some projects, like Rails, it's fairly clear what is meant when someone talks about a vulnerability - that you can hacked somehow. However, if someone wrote a gem to wrap eval into a command line tool so they can use some random ruby commands or libraries from their shell, well, secure would be a non-sequitur, but also beside the point.
fuj 12y ago
STOP LYING! Everyone knows the only security issues nowadays are caused by developing in PHP, that's why we bash it every day, right guys?!
thesp0nge 12y ago
Hi there I'm the man behind the codesake-dawn security scanner for ruby code. It will be great having some of you comparing the results obtainw with haikiri or other scanner and mine. Just for sake to reach an enterprise level tool. Regard paolo@armoredcode.com

96 points by vasinov 12y ago

deleted 12y ago

[deleted]

chc 12y ago

I can't help but feel that this could also be written as "How secure are Ruby and Rails apps? About as secure as all other apps." In my experience, vulnerabilities are pretty much endemic to software that has not been hardened by experts.

dperfect 12y ago
I agree. The fact that a large number of Ruby/Rails apps fall behind in terms of keeping dependencies up-to-date speaks more to Ruby's adoption than to its inherent insecurity. Without comparing these figures to other languages/frameworks (and accounting for flaws in completely custom-built apps), it's hard to draw any real conclusions here.
danudey 12y ago
I think the big thing here that threw me for a loop is just how many gems are pulled in by projects. 133 seems like a ridiculous amount of dependencies for a single project. Our entire company runs on Python in the backend and we don't even have 50 (and that's including ones I use for command-line utilities or corncobs, for example, which aren't in our public-facing software). Even if the Python modules we have had the same number of vulnerabilities as gems, our exposure for a given system would be 1/10th, just from not using so many external libraries. Couple that with the fact that many of those gems are outside of end-user control, of generally unknown quality, might only be pulled in for one small piece of functionality, and might themselves depend on other gems which you weren't necessarily aware of and haven't necessarily vetted.
- steveklabnik 12y ago
  A blank Rails app installs ~40 gems last I checked.
- chc 12y ago
  I think part of it is that people tend to separate things out into lots of gems. For example, if you're using Ember in your Rails app, that's two gems right there just for that library. If you want to allow delegated authentication with the common providers (Facebook, Twitter, OpenID), that's like 10 gems. Your unit testing and error reporting comes from gems, your app server is a gem, every database you want to support is at least one gem, etc. It gets explosive, but it's really just an organization thing. One thing to keep in mind, though, is that not all gems are actually used at a given time. Your gems for testing, development and production all go in the Gemfile, but you're probably not going to install all of them on one system.
- bstar77 12y ago
  Not all gems are created equal. Large amount of gems don't necessarily mean that they are arbitrarily included. In fact, it's often better to pull in a dependency for things that specialize in a particular task because they are more likely to have hardened security and better performance. The flip side is actually knowing that this "meme generator" gem you are using actually pulls in 50 dependencies, many of which are terribly implemented. I've seen this problem just as rampant in the Node.js and jQuery worlds. As developers, we should be as aware as possible of the state of our critical apps dependencies. I've recently gone through an app that had over 50 gem dependencies and reduced it to under 20. One thing that's probably not considered is that testing frameworks (rspec) have tons of dependencies that are not scoped to production. I'm not sure if these reports considered that.
- GlennS 12y ago
  It would be interesting to know why this is. Are each of these dependencies really small on average? Or is there some big cascade of dependencies? Or is there a particular framework that's to blame? I've had a similar issue when using the Spring Framework in Java, where including it in your project at all brings a whole host of other (often not very good) libraries in. This is a problem in Java, which doesn't have any built in capacity for loading multiple versions of the same library. In Python, I suspect that I've been in a similar situation when using things like Pyproj, Numpy or Scipy, because those all depend on components written in C or Fortran. Perhaps next time I use any of those libraries I shall take some time to read more of the code and try to trace out what things they may be brining in.
  - ddebernardy 12y ago
    > Are each of these dependencies really small on average? Or is there some big cascade of dependencies? Or is there a particular framework that's to blame? All of that, really. For better or worse, scores of gems have dependencies. Rails and a few popular others add large dependencies that cascade to other dependencies at that — some large, some not. It's extremely rare to run into quality gems with very few if any dependencies. (Sequel comes to mind, and that's just about the only 1st-class gem I can think of in pure Ruby.)
  - chc 12y ago
    A lot of them really are small. There is a tendency for Ruby libraries to be separated into "core" and "feature" gems that you can pull in separately, For example, if you want to use DataMapper, you might be pulling in dm-core, dm-rails, dm-validations, dm-migrations, dm-timestamps, dm-postgres-adapter, dm-mysql-adapter, dm-is-searchable…

tkellogg 12y ago

It's neat (if not alarming) to see security metrics visualized like this. Nice work!

crazydoggers 12y ago

Unpatched Rails apps are found vulnerable until patched... news at 11.

vasinov 12y ago
I think the interesting part is how many unpatched, hence vulnerable, apps there are.
- crazydoggers 12y ago
  But this article does not analyze that. It's only scanning CVE's and most have already been patched when the CVE is issued. Of the 53 mentioned for Rails for instance, all have been patched. This article is incredibly misleading.
  - vasinov 12y ago
    I don't understand... The article first analyzes apps that use a certain number of vulnerable gems. Sure, most of them are probably patched, but it doesn't change the fact that certain apps use old unpatched versions of these gems. The second part focuses on historical vulnerability data for Ruby gems. In what way any of it is misleading?
    - crazydoggers 12y ago
      > Sure, most of them are probably patched, but it doesn't change the fact that certain apps use old unpatched versions of these gems Why is that news?? That is true across every and all software platforms. > In what way any of it is misleading? Because the article assumes or implies the conclusion that there are a huge number of vulnerable Rails apps. The only way to discover that is to not simply count how many CVEs have been issued for each gem, but how many systems in production have not been patched. From the comments here, many people seem to assume this is an analysis of the number of unpatched vulnerable systems in production, which it most definitely is not.
      - 12y ago

hawleyal 12y ago

Nice graphs. Meaningless, but nice.

unreal37 12y ago

I am not a ruby developer, but it does seem shocking that 66% of all gemfiles contain a known previously-disclosed 5+ exploit. Yes, most software is flawed, but you would think once it's been reported, it would be fixed.

spatten 12y ago
The gems have probably been updated by the developers of the gem. The data used in the article contains a list of the versions being used in production by real app, not the latest versions released by the gem developers.
- unreal37 12y ago
  Ah, thanks for the clarification.
- vasinov 12y ago
  I think unreal37 meant "once it's been reported, it would be fixed [in the app]." As in updated.
- klochner 12y ago
  Risk also depends on how you're using the gem. If it's a bug in a YAML parser but you're not loading YAML from untrusted sources, then it would be a false positive.
- robotfelix 12y ago
  Yes, after seeing many familiar gems in the graphic I was almost surprised to see that hakiri gave my Gemfile.lock an 'all clear'. The should be able to calculate what percentage of these would still be vulnerable if fully updated - now that would be an interesting stat!
phillmv 12y ago
So, all software has two problems. First one is finding, reporting and getting vulnerabilities. Most people don't perform security audits. Most vendors take forever to reply back to security reports. Infuriatingly, many vendors will roll security fixes into the next major release instead of backporting patches and minor versions. The second one is about finding out about disclosed and patched vulnerabilities. Outside of larger institutions where you have someone whose job it is to worry over configuration management and subscribe to every mailing list, the ecosystem for disseminating this information is broken. That's why we've started the https://github.com/rubysec/ruby-advisory-db https://github.com/rubysec/ruby-advisory-db, at least for the Ruby ecosystem.

enraged_camel 12y ago

This doesn't surprise me, and I'm not even an experienced Rails developer. I think a big part of the problem is that there are a ton of gems that are simply hobby projects that gained traction and became popular. They were originally architected by enthusiasts, rather than experts. Some of these projects may also have been abandoned by their authors, but still in use because they may be the only way to accomplish a complex task or integration. You can't expect stuff like that to be very secure. You just have to think carefully about whether the risks of using them are worth the gains made from not having to implement the functionality yourself.

hox 12y ago
This can be said of any open source library, but it is unfortunately true that the average Ruby gem seems to be more hobby-grade than enterprise-grade. The fact of the matter is, if you are developing an application and are integrating 3rd-party code, always pay attention to what that 3rd-party code is, how well-maintained it is, and how the project has responded to bugs and vulnerabilities in the past.
- midas007 12y ago
  Yup. I've done enterprise Rails consulting, which is almost a contradiction in terms. But it's possible and I've brought fixes like net ldap to work with AD. Edit: Can't take all the credit, client hacked together the first version but we managed to extract it for "the greater good." Also fun stuff like XML-RPC (Xen API -> gem xenapi, VMware (gem rbvmomi)), which wasn't bad and worked OOTB. Wished MS exposed their APIs as RESTful endpoints, because WinRM + gem winrm just doesn't cut it with some products... generated powershell run by an agent instead. For some products, even having the (.someextiforgot) files that describe the API, there's no MS docs on them, so lots of trial-and-error in PowerGUI to find the right objects and methods (Yuck).
  - hox 12y ago
    You sir are a saint. Dealing with net_ldap and AD was the bane of my existence for a while.

mratzloff 12y ago

This doesn't surprise me in the least, but the increase in 2013 is obviously due to increased security scrutiny, which is good so long as people act on that information. As a side note, I'd be interested to see a similar analysis of popular Java projects.

molf 12y ago

The graphs of Gem distribution and Vulnerability distribution are utter nonsense. You can't just measure your mean and standard deviation and expect a bell curve that fits those two parameters to correspond to your distribution. Especially if you cut off one of the tails.

vasinov 12y ago
Do you mind sharing how you would present this data?
- blt 12y ago
  A histogram.
  - vasinov 12y ago
    Why do you think it would be better/more meaningful?
    - teraflop 12y ago
      The current graph is actively misleading because it misrepresents the data as following a (truncated) normal distribution when that's very unlikely to be the case. A histogram would show the actual distribution. The kind of graph being used here -- a "best fit" bell curve based on the sample mean/s.d. -- can be useful when overlaid on a histogram, to illustrate how closely the data can be approximated by a normal distribution. Without that context, it's essentially meaningless.
- saraid216 12y ago
  Start with having a y-axis. That graph isn't a graph. It's just two numbers.

phillmv 12y ago

Hey! I'm one of the maintainers behind the Ruby advisory database: https://github.com/rubysec/ruby-advisory-db https://github.com/rubysec/ruby-advisory-db We're trying to build a common database for people building these tools; at the moment, trawling through CVE disclosures and various mailing lists is a largely manual process that we can reap economies of scale by pooling our efforts together. It's free and volunteer run. I would like to encourage you and anyone else reading this who is interested in bolstering the security ecosystem to consider using and contributing to the advisory database. It's the database that powers http://github.com/rubysec/bundler-audit http://github.com/rubysec/bundler-audit and (disclaimer: I made this) https://gemcanary.com https://gemcanary.com and the more people contributing the more we can all benefit from improving the ways we can notify end users of their vulnerable dependencies. Thanks,

vasinov 12y ago
Do you know of any apps like https://hakiri.io https://hakiri.io that automate security scanning and serve as a security monitor for any future disclosures? Also, how would one use bundler-audit if a Rails app is not actively maintained?
- phillmv 12y ago
  Yeah, like I mentioned above the app I built (https://gemcanary.com https://gemcanary.com) automates disclosure notification, and I believe? https://codeclimate.com/ https://codeclimate.com/ may use the advisory database as well, but I do not know for a fact. There's a few others but they've slipped my mind at the moment. I use bundler-audit when performing security audits for clients. You could wrap it in a git commit hook and have it publish results, but to my knowledge no one's done it that way.
- jamie_ca 12y ago
  I believe [Code Climate](https://codeclimate.com/ https://codeclimate.com/) will report vulnerable gem versions in your app. Their marketing page suggests that they also analyze how you use a vulnerable library to see if you're affected or not.
12y ago

midas007 12y ago

Generally: don't trust anything from the outside world or anything that can transit untrusted infrastructure, that means check types and sanitize values before passing along. Break loudly and quickly to get attention for a fix. Keep the codebase as tiny as possible too. Ruby: recompile with minimized OpenSSL 1.0.1+ (LibreSSL when possible) and with patches that improve Ruby's default OpenSSL security. https://gist.github.com/steakknife/8228264 https://gist.github.com/steakknife/8228264 https://gist.github.com/steakknife/10092587 https://gist.github.com/steakknife/10092587 https://gist.github.com/steakknife/10096008 https://gist.github.com/steakknife/10096008 For Rails apps: use brakeman as one part of security audit strategy For gem authors, sign them (please!): I wrote waxseal to make it dead simple [sudo] gem cert --add <(curl -L https://gist.github.com/steakknife/5333881/raw/gem-public_cert.pem) # adds my cert (do once) [sudo] gem install waxseal --trust-policy HighSecurity For gem users, find which aren't signed Add this to ~/.gemrc gem line: --trust-policy MediumSecurity or just if there's no gem: .... already: gem: --trust-policy MediumSecurity For anyone using git, sign your tags (git tag -s ...) and commits (git commit -S ...) por favor

InAnEmergency 12y ago
For what it's worth, --trust-policy has been broken since RubyGems 2.0.0 and will not be fixed until 2.3: https://github.com/rubygems/rubygems/issues/859 https://github.com/rubygems/rubygems/issues/859

steveklabnik 12y ago

It's possible some of these are false positives, at least with regards to Rails, as most of the recent vulnerabilities I can remember come with workarounds and patch files. Some people need to stay on a specific Rails version, but may have fixed the problem. I'm not ready to speculate which is more probable.

vasinov 12y ago
Yep, totally agree, that's why I added a post scriptum :)
- steveklabnik 12y ago
  Ah! Missed it! My bad.

jusob 12y ago

More alarming than vulnerable gems is the the number oh high severity vulnerability found in Rails itself: http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-Rails.html?vendor_id=12043 http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-.... Compare this to Django (http://www.cvedetails.com/vulnerability-list/vendor_id-10199/product_id-18211/year-2013/Djangoproject-Django.html http://www.cvedetails.com/vulnerability-list/vendor_id-10199...) per year.

techpeace 12y ago
number of reported vulns != number of existing vulns

Glyptodon 12y ago

This article kind of confuses me - what does it mean for a gem do be 'secure' ? The idea of many gems being 'secure' or 'non-secure' is a non-sequitur. Obviously for some projects, like Rails, it's fairly clear what is meant when someone talks about a vulnerability - that you can hacked somehow. However, if someone wrote a gem to wrap eval into a command line tool so they can use some random ruby commands or libraries from their shell, well, secure would be a non-sequitur, but also beside the point.

fuj 12y ago

STOP LYING! Everyone knows the only security issues nowadays are caused by developing in PHP, that's why we bash it every day, right guys?!

thesp0nge 12y ago

Hi there I'm the man behind the codesake-dawn security scanner for ruby code. It will be great having some of you comparing the results obtainw with haikiri or other scanner and mine. Just for sake to reach an enterprise level tool. Regard paolo@armoredcode.com