Hey. We posted about our service last week and got great feedback. We took that feedback and decided to put isitvulnerable.com together to really showcase what you can get out of it / uh check your dang Gemfile.lock at least.
We're expanding platforms, so do tell us what to support next :).
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.
Although I'm worried about the part where I'm supposed to install a service monitor on our servers. I know, many people already do stuff like that with airbrake or newrelic but I know that admins get grey hair because of that. :)
You should think about offering an API where the client can upload its Gemfile.lock on their own.
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?
Sending data from your server to a third party is something many people are not comfortable with.
In environments with tighter security needs, this is outright verboten.
It is true that those tools help the developers and the admins to monitor their products but where you aren't allowed to use them and have to run your own stuff, you might pay in higher maintenance costs.
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.
The cases I have in mind are not because of NIH or because of greybeards' passed-down wisdom from the time when computers had to be carved out of stone.
There are places where there are heightened security requirements (for various reasons[1]). Disallowing unnecessary outbound connections is a standard practice. This results in pruning quite a lot of possible attack vectors.
[1] Of course some of those reasons are ridiculous. One place disallowed saving word documents as blobs in an Oracle database running on a Solaris server due to fear of malicious word document macros running on said server.
Saw the title and thought it might be you two. The site looks great! I'm surprised you found the time to put something like that together while in YCombinator.
Of course I have to suggest Python/Django, since that's what my company uses. But to maximize (number of users)x(number of security vulnerabilities), perhaps Wordpress plugins would be worth monitoring?
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
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.
Bug report: text here [1] is not rendering properly, but if I resize the window to be smaller it adjusts and is fine. Happens in Firefox 39.0.3 (no plugins) and Chrome 44.0.2403.130 (64-bit, no plugins) at 1000px window width on OSX Yosemite.
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.
Not sure why you were downvoted for asking a question and trying to learn.
The information is coming from publicly available descriptions of vulnerabilities. The affected versions of gems are already enumerated. This tool is a way to make it easier for devs to compare their set of gems against the vast database of vulnerabilities.
Thanks for the helpful response, this is exactly what I was wondering as I assumed there might be some publicly available info on vulnerabilities.
Is there a definitive source for keeping track of these out of curiosity? I'd consider myself an "early" programmer, so I know enough to be dangerous, but feel like there's no time like the present to start keeping track of known issues with things I might be using, even if I may not grasp the full extent of them at my level of experience.
Someone should reestimate severity of those "CVEs". I got 10 warnings and none of them is any severe for my app(and yours too, likely), so I'm definitely not vulnerable.
Also LOL "CSRF Vulnerability in jquery-rails" is known as not a bug at all.
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
50 comments
[ 2.9 ms ] story [ 47.9 ms ] threadWe're expanding platforms, so do tell us what to support next :).
It is a service! Visit https://appcanary.com for more deets.
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.
Although I'm worried about the part where I'm supposed to install a service monitor on our servers. I know, many people already do stuff like that with airbrake or newrelic but I know that admins get grey hair because of that. :)
You should think about offering an API where the client can upload its Gemfile.lock on their own.
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.
In environments with tighter security needs, this is outright verboten.
It is true that those tools help the developers and the admins to monitor their products but where you aren't allowed to use them and have to run your own stuff, you might pay in higher maintenance costs.
There are places where there are heightened security requirements (for various reasons[1]). Disallowing unnecessary outbound connections is a standard practice. This results in pruning quite a lot of possible attack vectors.
[1] Of course some of those reasons are ridiculous. One place disallowed saving word documents as blobs in an Oracle database running on a Solaris server due to fear of malicious word document macros running on said server.
Of course I have to suggest Python/Django, since that's what my company uses. But to maximize (number of users)x(number of security vulnerabilities), perhaps Wordpress plugins would be worth monitoring?
But do you have bugs?
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...
So the app just runs through the list and check whether version of the gem is vulnerable or not.
Checking the git history, I see that phillmv is a contributor to ruby-advisory-db.
https://github.com/rubysec/bundler-audit
https://github.com/rubysec/ruby-advisory-db
We figured we could do a better job all around if we managed to productize it.
It'll block any vulnerable version of a dependency in your project.
I think this is really awesome...
...I have to go update a few projects right now.
Definitely! We're building a service to monitor your app and server's dependencies, and we currently support Ubuntu and Ruby.
Our goal is to cover basically all of open source :).
Bug report: text here [1] is not rendering properly, but if I resize the window to be smaller it adjusts and is fine. Happens in Firefox 39.0.3 (no plugins) and Chrome 44.0.2403.130 (64-bit, no plugins) at 1000px window width on OSX Yosemite.
[1] http://i.imgur.com/rgQqli8.png
We don't associate any gemfiles with user information, so at best… all you could get is a list of vulnerable gemfiles, somewhere, out there :).
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.
The information is coming from publicly available descriptions of vulnerabilities. The affected versions of gems are already enumerated. This tool is a way to make it easier for devs to compare their set of gems against the vast database of vulnerabilities.
Is there a definitive source for keeping track of these out of curiosity? I'd consider myself an "early" programmer, so I know enough to be dangerous, but feel like there's no time like the present to start keeping track of known issues with things I might be using, even if I may not grasp the full extent of them at my level of experience.
https://annotate.driftt.com/view?i=99nffsejxeiittq%2F2015-08...
Also LOL "CSRF Vulnerability in jquery-rails" is known as not a bug at all.
But yeah, we do need to find the time to clean it up.