Don't find out about Ruby vulnerabilities through Hacker News and Twitter
gemcanary.com
gemcanary.com
From a security standpoint, what you want to do is less important than what you can do, and the access controls you use currently -- public or public + private -- just aren't fine grained enough.
We agree. We spent a lot of time debating this.
We originally set out to build a gem, but realized it was so much easier to use through GitHub. Unfortunately, we can't provide more granular access due to what the API gives us.
We plan on eventually releasing said gem, as noted in the "I don't use github" link on the front page :).
On deploy posting the Gemfile is something that came to my mind too and would work.
You could probably hack around it by creating an integration account that only has access to the repositories that you want to integrate. If you're asking for only access to the Gemfile and not the repository, that's far outside the security model of GitHub, and even Git.
Maybe a good alternative for people security conscious would be a manual Gemfile upload?
We're still in beta and adding some polish, so please let us know if something breaks. Also, it's possible we may run up against the GitHub API rate limit, so bear with us if we turn off new user signups.
Thanks!,
If you login through github and enable notifications, we install a post-receive hook.
For non github projects… we plan on eventually supporting that, but GitHub was an easy-lowest-common-denominator.
If you're interested, add your email through the "I don't use GitHub" link on the front page, and we'll let you know when it's ready :).
It neatly states an obvious problem in the headline, then on landing, proposes a service to solve the problem that we know exists. If I had a ruby system, I'd be on this like, well, frosting on a cupcake. Mmmmm, cupcakes. :)
As a result, the hard part is collecting info on vulnerable dependencies. We solved this problem for Ruby by… co-maintaining an open source database https://github.com/rubysec/ruby-advisory-db/ – which everyone is free to use.
We don't have the resources to do this for every community :).
BundleScout[1] does this for other languages, including Node.js and Python--and of course Ruby Gems. We don't have Github integration yet, but you can simply upload your requirements file (which, it seems, some people would rather do anyway).
1. When I upload a requirements.txt file, let me just pick 5 packages from the file instead of telling me I have to upgrade to use it.
2. Why is Django listed as the old version 1.3.7 in my dash?
3. You have a Twitter account, but there appears to be no link on your website that I could spot.
1. We just pushed the import feature a couple days ago so we're still tweaking how it works. This is a good suggestion, I'll definitely take it into consideration.
2. You should be seeing 1.3.7 as the 'old version' (last update we detected). We're still working on better branch/track breakdown--this isn't an issue for most packages.
3. The Twitter account is linked at the bottom of the page :)
Let me know at friends [at] bundlescout [.] com if you're not seeing the right Django version and I'll look into it today.
Congrats on a cool product and I'm glad it was posted here.
https://github.com/presidentbeef/brakeman/issues/276
A complementary command-line tool would be fine too.
Check it out: https://github.com/rubysec/ruby-advisory-db
You should consider building something similar.
Having a record of all the security vulnerabilities that affect the Ruby community is important. To that end, we help maintain https://github.com/rubysec/ruby-advisory-db/ which is free for anyone to use or contribute to.