You may want to rethink the pricing. I have several server variants that I effectively clone in different datacenters across my deployment. Since the base images are static I would really only need to run the agent on <i>n</i> servers (where <i>n</i> is the number of server variants that I have) to ensure that my entire deployment is protected.<p>I'm not sure if you would consider this unethical. I would probably feel differently about the pricing if it were tiered levels related to the entire size of the deployment (e.g.: 1-50 servers: $x/mo, 50-250 servers: $y/mo, 250+ servers: $z/mo).
Hey everyone!<p>appCanary monitors the software on your servers and notifies you when you have to take action. In a previous life, we spent a lot of time worrying about what needs to be updated where and so we built this.<p>We currently let you know about Ruby vulns deployed on any linux, and vulnerable packages if you run Ubuntu. Support for Docker and other vuln sources is just around the corner.<p>We'd love to hear your feedback!
At my day job I am stuck on a Windows IIS stack.<p>Any plans for windows servers? I'd honestly prioritize this after application dependencies checking for Java/Node etc, but just thought I'd ask.
How does this work? Do I need to run your software on my servers? A software calling home to some third party seems to be a problem for many use cases.
I had that exact idea a while ago and filed it into my "ideas that might be fun and might be successful" list. Time to cross it off. Good luck with this, it's a great idea!
I put together a basic chef cookbook to configure this today:<p><pre><code> https://github.com/bitmonk/chef-appcanary
</code></pre>
CentOS / RH / Fedora support isn't in, yet, and for kitchen to pass, you have to edit .kitchen.yml to set your api key.<p>Tomorrow or this evening I'll finish that up and show its' use in a wrapper cookbook.
Apologies if I'm misunderstanding as I only skimmed the source code but..<p>Why are you sending the full file contents from the agent to the client?<p><a href="https://github.com/appcanary/agent/blob/master/agent/agent.go#L72" rel="nofollow">https://github.com/appcanary/agent/blob/master/agent/agent.g...</a>
agent.client.SendFile(file.Path, file.Kind, contents)<p>Extremely insecure design with a ton of unnecessary overhead. What if those files are configuration files with sensitive data embedded?
I like the idea but most of the servers we manage have out going firewalls to block them from talking to the internet. We produce installed package lists during deployment (as much as possible we run immutable pre-built images and replace the image rather than upgrade in place) which could be sent to a service like this but wouldn't want to start punching holes and adding routes for it. To work as is we'd need to add duplicate canary servers in an isolate environment to talk to the service.
Sounds interesting! Is the vulnerability scanner of Gemfile based on bundler-audit[1]? Do you add other value to this part?<p>[1] <a href="https://github.com/rubysec/bundler-audit" rel="nofollow">https://github.com/rubysec/bundler-audit</a>
A couple of years ago there was a similar startup called SourceNinja. They used a different method to get the dependency/library info though. It turned out to be not as profitable as they hoped...
<i>"Hey Hacker News! Try out our pilot program."</i> Just sign here.<p>It's another wannabe startup that asks people to sign up before disclosing terms, or, in this case, anything at all. And they want access to your server. Right.<p>No business address on the site. A low-rent "domain control only validated" SSL cert. Anonymous domain registration. They do show up as a Delaware corporation, all of two months old:<p><pre><code> CANARY COMPUTER CORPORATION
File Number: 5749511
Filing State: Delaware (DE)
Filing Status: Unknown
Filing Date: May 18, 2015
</code></pre>
They're not known to Dun and Bradstreet, so you can't do a background check on them. Those are all scumbag flags.