5 ms·

Show HN: AppCanary – Keep vulnerable software off your servers

108 points by phillmv 11y ago

phillmv 11y ago
Hey everyone! 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. 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. We'd love to hear your feedback!
- m00dy 11y ago
  How can you figure out whether a software is vulnerable? Parsing public CVEs and matching with version number?
  - ryanlol 11y ago
    Unless they're watching updates from repos, it'd be very hard to automate this. CVEs are very far from reliable.
  - deleted 11y ago
    [deleted]
- joergsauer 11y ago
  This looks interesting. I have been looking for a solution to this problem without any clear conclusions so far. Nessus and Qualys have new agent-based scanners now, but I have not tested them because they both only support Red Hat-based Linux distros. It sounds like for most software you are using the Ubuntu package management system to check for vulnerable versions. Is that correct? And are you planning to add detection for binaries that live outside of the distro package manager? I am thinking of stuff like custom-compiled Nginx binaries for example. I realize it would be non-trivial to implement this but would consider it highly useful at least for a certain set of common software components.
  - phillmv 11y ago
    >And are you planning to add detection for binaries that live outside of the distro package manager? It's on the roadmap! Others have mentioned that before. First we need to get really good at knowing about CVEs :).
    - feld 11y ago
      If you can solve this people will throw boatloads of money at you. Unfortunately it's not easy -- even writing scripts to detect running processes across all our servers to identify Java, Apache, Tomcat, etc etc has proven difficult to get right. Sometimes you can get enough info from extended process list info, sometimes not. Sucks.
- vezzy-fnord 11y ago
  What advantage do I gain from this over periodically running various distro tools that compile CVEs and security advisories into a flat file database and search on top of that, e.g. pkg audit on FreeBSD and glsa-check on Gentoo?
  - phillmv 11y ago
    We only show you stuff that affects you, we automate the process, we light up your call tree and we'll be providing metrics and audit logs. It's definitely a leg up over just being spammed by pkg audit. Further, we also cover your app dependencies :).
efriese 11y ago
So you're cataloging the software installed and then monitoring for CVEs?
- phillmv 11y ago
  There's a stunning amount of elbow grease involved in that. If you're a random company, you have an engineer sitting around whose job involves reading a dozen mailing lists - and we want to save everyone from that redundancy.
  - federico3 11y ago
    And that's why there are Linux distributions with security teams doing that work for everybody. How is this service different?
    - phillmv 11y ago
      1. They all do a great job! But there's this last mile problem with managing the information they do put out. If you can handle the downtime, unattended-upgrades will work just dandy. If your postgres restarting in the middle of the night gives you pause, our service can help you choose how to roll out your security upgrades. 2. We cover app dependencies as well! For now just Ruby, but others as well pretty soon. I'm one of the maintainers of the Ruby Advisory Database https://github.com/rubysec/ruby-advisory-db/ https://github.com/rubysec/ruby-advisory-db/ - and we know all about the effort involved.
    - joergsauer 11y ago
      Currently, there is no straightforward way of checking Ubuntu package versions against CVEs. Debian provides this through debsecan[1], but this tool is pretty much broken on Ubuntu[2]. [1] http://www.enyo.de/fw/software/debsecan/ http://www.enyo.de/fw/software/debsecan/ [2] https://bugs.launchpad.net/ubuntu/+source/debsecan/+bug/95925 https://bugs.launchpad.net/ubuntu/+source/debsecan/+bug/9592...
    - HappyTypist 11y ago
      Correct, but if this will reduce the 0-day / 1-day time then it's very useful if your server does anything important. The difference between responding to Shellshock in 15 mins vs 2 hours could be exploitation.
dewey 11y ago
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.
- phillmv 11y ago
  It's very small and written in golang and up on github https://github.com/appcanary/agent/ https://github.com/appcanary/agent/ We understand how some people might have problems / have plans to improve upon it - maybe we run a proxy or some kind of enterprise edition. But we think the main pain relief comes from knowing what you have deployed is now fixed.
nickphx 11y ago
$9/server? lol.
jaryd 11y ago
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 n servers (where n is the number of server variants that I have) to ensure that my entire deployment is protected. 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).
- phillmv 11y ago
  >I would probably feel differently about the pricing if it were tiered levels (e.g.: 1-50 servers: $x/mo, 50-250 servers: $y/mo, 250+ servers: $z/mo). Ya, that's fair and a good suggestion. I think we may very well end up doing something like that. We're still trying to figure out what kind of model best suits the server fleets people have. We'll be keeping the first server free, and probably have a not for profit tier.
  - pdpi 11y ago
    As an added note, $9 per server doesn't seem excessive when I think of our large bare metal servers, but it starts looking _really_ pricy if I look at our $50/mo m3.mediums in AWS.
- justizin 11y ago
  Sampling like this is precisely what a lot of folks do with New Relic as well. It would be extremely dubious if they disallowed that.
deleted 11y ago
[deleted]
- phillmv 11y ago
  >A hashed password is only mine and the universe's secret. You always have to leave a little room for the holy spirit.
  - deleted 11y ago
    [deleted]
timboslice 11y ago
At my day job I am stuck on a Windows IIS stack. Any plans for windows servers? I'd honestly prioritize this after application dependencies checking for Java/Node etc, but just thought I'd ask.
- j_s 11y ago
  Check out Mike Taber's¹ cross-platform work-in-progress: https://www.auditshark.com/ https://www.auditshark.com/ It is targeted more at OS-level vulnerabilities (including IIS) rather than application dependency vulnerabilities, but may provide the solution you're looking for. ¹ https://news.ycombinator.com/item?id=9492839 https://news.ycombinator.com/item?id=9492839
- stephengillie 11y ago
  Competing solutions include SCCM, Applocker, and Application Whitelisting.
anc84 11y ago
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!
deleted 11y ago
[deleted]
ihsw 11y ago
> $9 per server How does this affect containers?
- phillmv 11y ago
  Docker shall be addressed soon! We'll probably end up sitting on your host and taking a peek inside your container filesystems.
  - sandGorgon 11y ago
    @phillmv - +1 for the Docker+supervisord version ! Would strongly recommend an "in-container" version, so that I can bake your agent into my Docker VMs. Remember that if I run my Docker VM on CoreOS, then it is very hard to install something on the host.
    - shazow 11y ago
      It could be a separate docker container with a volume mount to the docker sock. That's probably the best option, a bit better than baking it into all of your images.
  - justizin 11y ago
    i was wondering if there's an interactive version of this I could run in CI (e.g. test-kitchen), so that I can fail CI when the results of a fresh CM build is vulnerable.
ZeWaren 11y ago
Won't a database of vulnerable servers be something of interest for hackers? Are you confident in your own infrastructure?
- hellbanner 11y ago
  Maybe a PGP key instead of a javascript form for submitting a secret to setup the account?
- phillmv 11y ago
  This is a problem everyone in the security space faces. We used to work as security consultants, so we're more experienced than most, and we're working hard to be transparent and above board. As we grow, we'll definitely be conducting regular audits of our infrastructure.
Animats 11y ago
"Hey Hacker News! Try out our pilot program." Just sign here. 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. 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: CANARY COMPUTER CORPORATION File Number: 5749511 Filing State: Delaware (DE) Filing Status: Unknown Filing Date: May 18, 2015 They're not known to Dun and Bradstreet, so you can't do a background check on them. Those are all scumbag flags.
- NateLawson 11y ago
  I think "scumbag flags" is an extremely inflammatory conclusion to jump to. How about these are all signs for "just getting started"? Sure, if you don't want to do business with a brand new startup, just wait a bit for them to mature. But no need to sound the snake oil alarm. That being said, putting ToS and privacy policy links on the signup and main page would be a good idea.
  - Animats 11y ago
    That's not enough. This unknown, anonymous outfit wants you to trust them to collect info about security vulnerabilities on your site. That's asking a lot. Remember, in B2B you're selling to the main in the chair[1]: I don’t know who you are. I don’t know your company. I don’t know your company’s product. I don’t know what your company stands for. I don’t know your company’s customers. I don’t know your company’s record. I don’t know company’s reputation. Now—what was it you wanted to sell me? Now see the modern version of this: [2] [1] http://rhodescomm.com/_blog/Observations/post/Why_You_Should_Care_About_the_Man_in_the_Chair_/ http://rhodescomm.com/_blog/Observations/post/Why_You_Should... [2] https://www.youtube.com/watch?v=nXG7zYWKHGU https://www.youtube.com/watch?v=nXG7zYWKHGU
- phillmv 11y ago
  I also hate it when there's a total void of info. But! We're not yet launched, and I'm pretty easy to google :).
wompa164 11y ago
Apologies if I'm misunderstanding as I only skimmed the source code but.. Why are you sending the full file contents from the agent to the client? https://github.com/appcanary/agent/blob/master/agent/agent.go#L72 https://github.com/appcanary/agent/blob/master/agent/agent.g... agent.client.SendFile(file.Path, file.Kind, contents) Extremely insecure design with a ton of unnecessary overhead. What if those files are configuration files with sensitive data embedded?
- phillmv 11y ago
  >Why are you sending the full file contents from the agent to the client? 1. We only send files you tell us to send in the configuration, and you're not going to be storing any sensitive information in your Gemfile.locks or package.jsons. It's not functionally any different from us parsing it client side - but allows us to support new platforms without having to update the agent. >CRC is not a hashing algorithm. 2. You're absolutely correct! Which is why we're not using it as a cryptographic hash, i.e. as part of an HMAC. We're only using CRCs to determine if a file has changed, which is the purpose of CRCs :). Do you have any other concerns? We've spent a lot of time being paranoid, and we know it's a hard communication problem.
  - apazzolini 11y ago
    So is the idea here that you're just monitoring the libraries my web application is using? So for example: 1. I have library X version 1.2.3 in package.json. 2. My package.json file gets sent to you 3. You parse this file, and tell me library X version 1.2.3 has a vulnerability, and that I should upgrade AppCanary then doesn't monitor for the fact I have an outdated version of httpd for example?
    - phillmv 11y ago
      >AppCanary then doesn't monitor for the fact I have an outdated version of httpd for example? It does! So long as you've installed it via the package manager. Right now we support Ubuntu, and Debian will be out soon and RHEL systems in the very near future. In the near future we'll add the ability to scan hand-compiled binaries, but that's a technical challenge that depends on solving the first part of the equation (knowing what's vulnerable) really well.
pki 11y ago
Any way of cheaper pricing for VMs? We have a bunch of VMs that run on not-our-host-node, so it would be effectively $9 for a 256MB RAM instance.
- phillmv 11y ago
  We're still getting started, so - give it a spin, and we won't charge you until it's worth your while.
justizin 11y ago
I put together a basic chef cookbook to configure this today: https://github.com/bitmonk/chef-appcanary CentOS / RH / Fedora support isn't in, yet, and for kitchen to pass, you have to edit .kitchen.yml to set your api key. Tomorrow or this evening I'll finish that up and show its' use in a wrapper cookbook.
kylequest 11y ago
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...
iang 11y ago
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.
altharaz 11y ago
Sounds interesting! Is the vulnerability scanner of Gemfile based on bundler-audit[1]? Do you add other value to this part? [1] https://github.com/rubysec/bundler-audit https://github.com/rubysec/bundler-audit

108 points by phillmv 11y ago

Hey everyone! 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. 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. We'd love to hear your feedback!

m00dy 11y ago
How can you figure out whether a software is vulnerable? Parsing public CVEs and matching with version number?
- ryanlol 11y ago
  Unless they're watching updates from repos, it'd be very hard to automate this. CVEs are very far from reliable.
- deleted 11y ago
  [deleted]
joergsauer 11y ago
This looks interesting. I have been looking for a solution to this problem without any clear conclusions so far. Nessus and Qualys have new agent-based scanners now, but I have not tested them because they both only support Red Hat-based Linux distros. It sounds like for most software you are using the Ubuntu package management system to check for vulnerable versions. Is that correct? And are you planning to add detection for binaries that live outside of the distro package manager? I am thinking of stuff like custom-compiled Nginx binaries for example. I realize it would be non-trivial to implement this but would consider it highly useful at least for a certain set of common software components.
- phillmv 11y ago
  >And are you planning to add detection for binaries that live outside of the distro package manager? It's on the roadmap! Others have mentioned that before. First we need to get really good at knowing about CVEs :).
  - feld 11y ago
    If you can solve this people will throw boatloads of money at you. Unfortunately it's not easy -- even writing scripts to detect running processes across all our servers to identify Java, Apache, Tomcat, etc etc has proven difficult to get right. Sometimes you can get enough info from extended process list info, sometimes not. Sucks.
vezzy-fnord 11y ago
What advantage do I gain from this over periodically running various distro tools that compile CVEs and security advisories into a flat file database and search on top of that, e.g. pkg audit on FreeBSD and glsa-check on Gentoo?
- phillmv 11y ago
  We only show you stuff that affects you, we automate the process, we light up your call tree and we'll be providing metrics and audit logs. It's definitely a leg up over just being spammed by pkg audit. Further, we also cover your app dependencies :).

efriese 11y ago

So you're cataloging the software installed and then monitoring for CVEs?

phillmv 11y ago
There's a stunning amount of elbow grease involved in that. If you're a random company, you have an engineer sitting around whose job involves reading a dozen mailing lists - and we want to save everyone from that redundancy.
- federico3 11y ago
  And that's why there are Linux distributions with security teams doing that work for everybody. How is this service different?
  - phillmv 11y ago
    1. They all do a great job! But there's this last mile problem with managing the information they do put out. If you can handle the downtime, unattended-upgrades will work just dandy. If your postgres restarting in the middle of the night gives you pause, our service can help you choose how to roll out your security upgrades. 2. We cover app dependencies as well! For now just Ruby, but others as well pretty soon. I'm one of the maintainers of the Ruby Advisory Database https://github.com/rubysec/ruby-advisory-db/ https://github.com/rubysec/ruby-advisory-db/ - and we know all about the effort involved.
  - joergsauer 11y ago
    Currently, there is no straightforward way of checking Ubuntu package versions against CVEs. Debian provides this through debsecan[1], but this tool is pretty much broken on Ubuntu[2]. [1] http://www.enyo.de/fw/software/debsecan/ http://www.enyo.de/fw/software/debsecan/ [2] https://bugs.launchpad.net/ubuntu/+source/debsecan/+bug/95925 https://bugs.launchpad.net/ubuntu/+source/debsecan/+bug/9592...
  - HappyTypist 11y ago
    Correct, but if this will reduce the 0-day / 1-day time then it's very useful if your server does anything important. The difference between responding to Shellshock in 15 mins vs 2 hours could be exploitation.

dewey 11y ago

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.

phillmv 11y ago
It's very small and written in golang and up on github https://github.com/appcanary/agent/ https://github.com/appcanary/agent/ We understand how some people might have problems / have plans to improve upon it - maybe we run a proxy or some kind of enterprise edition. But we think the main pain relief comes from knowing what you have deployed is now fixed.

nickphx 11y ago

$9/server? lol.

jaryd 11y ago

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 n servers (where n is the number of server variants that I have) to ensure that my entire deployment is protected. 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).

phillmv 11y ago
>I would probably feel differently about the pricing if it were tiered levels (e.g.: 1-50 servers: $x/mo, 50-250 servers: $y/mo, 250+ servers: $z/mo). Ya, that's fair and a good suggestion. I think we may very well end up doing something like that. We're still trying to figure out what kind of model best suits the server fleets people have. We'll be keeping the first server free, and probably have a not for profit tier.
- pdpi 11y ago
  As an added note, $9 per server doesn't seem excessive when I think of our large bare metal servers, but it starts looking _really_ pricy if I look at our $50/mo m3.mediums in AWS.
justizin 11y ago
Sampling like this is precisely what a lot of folks do with New Relic as well. It would be extremely dubious if they disallowed that.

deleted 11y ago

[deleted]

phillmv 11y ago
>A hashed password is only mine and the universe's secret. You always have to leave a little room for the holy spirit.
- deleted 11y ago
  [deleted]

timboslice 11y ago

At my day job I am stuck on a Windows IIS stack. Any plans for windows servers? I'd honestly prioritize this after application dependencies checking for Java/Node etc, but just thought I'd ask.

j_s 11y ago
Check out Mike Taber's¹ cross-platform work-in-progress: https://www.auditshark.com/ https://www.auditshark.com/ It is targeted more at OS-level vulnerabilities (including IIS) rather than application dependency vulnerabilities, but may provide the solution you're looking for. ¹ https://news.ycombinator.com/item?id=9492839 https://news.ycombinator.com/item?id=9492839
stephengillie 11y ago
Competing solutions include SCCM, Applocker, and Application Whitelisting.

anc84 11y ago

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!

deleted 11y ago

[deleted]

ihsw 11y ago

> $9 per server How does this affect containers?

phillmv 11y ago
Docker shall be addressed soon! We'll probably end up sitting on your host and taking a peek inside your container filesystems.
- sandGorgon 11y ago
  @phillmv - +1 for the Docker+supervisord version ! Would strongly recommend an "in-container" version, so that I can bake your agent into my Docker VMs. Remember that if I run my Docker VM on CoreOS, then it is very hard to install something on the host.
  - shazow 11y ago
    It could be a separate docker container with a volume mount to the docker sock. That's probably the best option, a bit better than baking it into all of your images.
- justizin 11y ago
  i was wondering if there's an interactive version of this I could run in CI (e.g. test-kitchen), so that I can fail CI when the results of a fresh CM build is vulnerable.

ZeWaren 11y ago

Won't a database of vulnerable servers be something of interest for hackers? Are you confident in your own infrastructure?

hellbanner 11y ago
Maybe a PGP key instead of a javascript form for submitting a secret to setup the account?
phillmv 11y ago
This is a problem everyone in the security space faces. We used to work as security consultants, so we're more experienced than most, and we're working hard to be transparent and above board. As we grow, we'll definitely be conducting regular audits of our infrastructure.

Animats 11y ago

"Hey Hacker News! Try out our pilot program." Just sign here. 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. 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: CANARY COMPUTER CORPORATION File Number: 5749511 Filing State: Delaware (DE) Filing Status: Unknown Filing Date: May 18, 2015 They're not known to Dun and Bradstreet, so you can't do a background check on them. Those are all scumbag flags.

NateLawson 11y ago
I think "scumbag flags" is an extremely inflammatory conclusion to jump to. How about these are all signs for "just getting started"? Sure, if you don't want to do business with a brand new startup, just wait a bit for them to mature. But no need to sound the snake oil alarm. That being said, putting ToS and privacy policy links on the signup and main page would be a good idea.
- Animats 11y ago
  That's not enough. This unknown, anonymous outfit wants you to trust them to collect info about security vulnerabilities on your site. That's asking a lot. Remember, in B2B you're selling to the main in the chair[1]: I don’t know who you are. I don’t know your company. I don’t know your company’s product. I don’t know what your company stands for. I don’t know your company’s customers. I don’t know your company’s record. I don’t know company’s reputation. Now—what was it you wanted to sell me? Now see the modern version of this: [2] [1] http://rhodescomm.com/_blog/Observations/post/Why_You_Should_Care_About_the_Man_in_the_Chair_/ http://rhodescomm.com/_blog/Observations/post/Why_You_Should... [2] https://www.youtube.com/watch?v=nXG7zYWKHGU https://www.youtube.com/watch?v=nXG7zYWKHGU
phillmv 11y ago
I also hate it when there's a total void of info. But! We're not yet launched, and I'm pretty easy to google :).

wompa164 11y ago

Apologies if I'm misunderstanding as I only skimmed the source code but.. Why are you sending the full file contents from the agent to the client? https://github.com/appcanary/agent/blob/master/agent/agent.go#L72 https://github.com/appcanary/agent/blob/master/agent/agent.g... agent.client.SendFile(file.Path, file.Kind, contents) Extremely insecure design with a ton of unnecessary overhead. What if those files are configuration files with sensitive data embedded?

phillmv 11y ago
>Why are you sending the full file contents from the agent to the client? 1. We only send files you tell us to send in the configuration, and you're not going to be storing any sensitive information in your Gemfile.locks or package.jsons. It's not functionally any different from us parsing it client side - but allows us to support new platforms without having to update the agent. >CRC is not a hashing algorithm. 2. You're absolutely correct! Which is why we're not using it as a cryptographic hash, i.e. as part of an HMAC. We're only using CRCs to determine if a file has changed, which is the purpose of CRCs :). Do you have any other concerns? We've spent a lot of time being paranoid, and we know it's a hard communication problem.
- apazzolini 11y ago
  So is the idea here that you're just monitoring the libraries my web application is using? So for example: 1. I have library X version 1.2.3 in package.json. 2. My package.json file gets sent to you 3. You parse this file, and tell me library X version 1.2.3 has a vulnerability, and that I should upgrade AppCanary then doesn't monitor for the fact I have an outdated version of httpd for example?
  - phillmv 11y ago
    >AppCanary then doesn't monitor for the fact I have an outdated version of httpd for example? It does! So long as you've installed it via the package manager. Right now we support Ubuntu, and Debian will be out soon and RHEL systems in the very near future. In the near future we'll add the ability to scan hand-compiled binaries, but that's a technical challenge that depends on solving the first part of the equation (knowing what's vulnerable) really well.

pki 11y ago

Any way of cheaper pricing for VMs? We have a bunch of VMs that run on not-our-host-node, so it would be effectively $9 for a 256MB RAM instance.

phillmv 11y ago
We're still getting started, so - give it a spin, and we won't charge you until it's worth your while.

justizin 11y ago

I put together a basic chef cookbook to configure this today: https://github.com/bitmonk/chef-appcanary CentOS / RH / Fedora support isn't in, yet, and for kitchen to pass, you have to edit .kitchen.yml to set your api key. Tomorrow or this evening I'll finish that up and show its' use in a wrapper cookbook.

kylequest 11y ago

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

iang 11y ago

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.

altharaz 11y ago

Sounds interesting! Is the vulnerability scanner of Gemfile based on bundler-audit[1]? Do you add other value to this part? [1] https://github.com/rubysec/bundler-audit https://github.com/rubysec/bundler-audit