Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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 :).



How about a subscription service? Email me as soon as my installed gems are getting vulnerable.


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.


Part of it might be the link to your site is only clearly marked "we have a service" after you open a Gemfile.lock.


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


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


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


One more vote for Python/Django.


> Of course I have to suggest Python/Django

But do you have bugs?


Really nice and straightforward.

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.


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?


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.


This is pretty awesome, thanks! Can't wait for a GitHub integration and a badge to paste on the app readme. Seems like an excellent build check.


FWIW, The font spacing is too tight to the point of overlapping text on my browser (firefox 39, linux)


Very nice and simple. Maybe you can expose this as a public API too?


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.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: