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 :).
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
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.
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.
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
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.
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.
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.
.png%2F){kind=link}
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