Show HN: Is it vulnerable? Drag-n-drop your Gemfile.lock to check

This looks so simple but clearly a lot of work went into it. I'm learning Ruby and this is certainly going to be one of my most used tools - thanks!

Hah, well, okay, I didn't expect that page to read as too subtle.

It is a service! Visit https://appcanary.com for more deets.

Gemnasium.com offers this. (as does OP, see sibling comment)

I think developers could use way better security tooling.

It seems like a lot of people would love to have an easy way to integrate this into their continuous integration services, for instance - and we're working on making that a Real Thing That Exists.

That's the plan! We're going to be rolling that out in the next little while.

If you want to get a personal email when it comes out, put "API" in the platform field in the email form on the link above.

I thought that Airbrake and New Relic were supposed to support the ops team? I wouldn't want to run apps in production without them. I'm curious what admins object to?

I love how greybeards lose sleep over things perceived to be "not invented here" because there's a commercial entity behind it, but are completely fine with installing hundreds of open source tools by default that are often poorly audited because reasons.

It's a been a long couple of months :).

> Of course I have to suggest Python/Django

But do you have bugs?

I've put something together over the last weekend, tailored for django. It's still relatively early, but if you want to check it out: https://github.com/jayfk/django-updater

Just don't want it to be yet another "We found 123 vulnerabilities, sign up to learn more". E.g. if it's Rails RCE it confidence should be 3/3, if some app-specific, 2/3 etc. But anyway great job

bundler.io has a very good explanation[1]:

After developing your application for a while, check in the application together with the Gemfile and Gemfile.lock snapshot. Now, your repository has a record of the exact versions of all of the gems that you used the last time you know for sure that the application worked. Keep in mind that while your Gemfile lists only three gems (with varying degrees of version strictness), your application depends on dozens of gems, once you take into consideration all of the implicit requirements of the gems you depend on.

This is important: the Gemfile.lock makes your application a single package of both your own code and the third-party code it ran the last time you know for sure that everything worked. Specifying exact versions of the third-party code you depend on in your Gemfile would not provide the same guarantee, because gems usually declare a range of versions for their dependencies.

1) http://bundler.io/v1.7/rationale.html#checking-your-code-int...

It's a file which Ruby on Rails uses to keep track of currently used gem versions. Gems are just Ruby libraries.

So the app just runs through the list and check whether version of the gem is vulnerable or not.

Rails apps use a Gemfile.lock file to "lock" an app to specific Ruby library/dependency (gems) versions.

It's what ruby uses to "pin" the dependencies for a project.

Novice here, but wouldn't a list of vulnerable gems be almost as valuable a target (if it doesn't already exist elsewhere)? I would imagine it is not difficult to generate a list of sites using those versions of gems that have public repos.

Please feel free to educate me if that is not at all the case though--like I said, novice, so just starting to wrap my head around security implications of things like this.