Congrats on launching guys, but I'm going to be really honest here. The requirement that I provide access to my Github repos like this is a deal breaker. For a security related product, this creates a huge attack surface and audit requirement.
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.
>For a security related product, this creates a huge attack surface and audit requirement.
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 :).
I think that's how GitHub OAuth works though. As far as I know, you can't ask for access to a specific repository for an account, just access to private repositories in general.
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?
Hey! We built this as an itch scratcher - something that will only notify us about security updates. We've been working on this for a couple weeks now, and we think other people might find it useful.
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.
Seems it'd be much more useful to be able to have a commit hook POST the app's Gemfile to your service instead of doing everything via GitHub, unless there's something I'm missing?
I think this is the best headline/page I've read for a long time.
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. :)
This is really well done, thanks! I read HN every day and I thought I was fairly up to date after the last Rails security scramble but you guys pointed out a few more gems I need to update/remove. Integration was seamless and I got the information I came for in less than 2 minutes.
Very interesting, but why is it ruby specific? What about packages vulnerabilities in other languages? Surely you can parse Javascript and Python requirement files as well, the concept is no different.
So, we're only interested in sending security notices. We don't care about being notified about every dependency out there.
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. 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.
I found out why the Twitter link isn't working; it's because you're using the "Twitter button(TM)". This gets blocked by Ghostery, so using an old time-y link would probably be better for fallback purposes. Up to you, of course. :)
I wrote http://getshrubbery.com with a friend to do this for python packages. It's still a bit beta-ish but it works. It also notifies of all updates, not just security ones.
How is this better than brakeman? (http://brakemanscanner.org/) Seems like they only pretty much check your gem dependencies while brakeman also does static code analysis and points out potential sql injection spots etc...
Brakeman will not check all gem dependencies and is not a general-purpose gem dependency security checker... bundler-audit will probably end up being the de facto tool for that: https://github.com/postmodern/bundler-audit
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.
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.