Launch HN: Metlo (YC S21) – Open-source software for securing your APIs
Although APIs are one of the largest attack surfaces in companies today, there aren’t many good security tools to protect them. The few tools currently on the market are “enterprise” only; they require you to talk to a salesperson to use, or even see, the product.
We saw a need for an open-source solution that could be self-hosted and where you didn’t have to talk to a sales rep to see the product. So we started building an open-source API security tool with an MIT license that you can self-host, fork, and generally do whatever you want with. Since not everyone wants to self-host, we also built a hosted offering that you can get started with for free.
Our website is at https://metlo.com, repo is at https://github.com/metlo-labs/metlo. There’s a demo video here: https://www.loom.com/share/2c38c731cf044288995e5ee2566528a7. Check out our sandbox at https://demo.metlo.com (no email required). You can get started with our hosted service (in Beta) for free at https://app.metlo.com/signup (there’s an always free tier, and paid tier is not enforced yet) , or you can self-host by following the instructions at https://docs.metlo.com/docs/deploy-to-aws.
Our functionality can be divided into three areas – discovery (OSS), testing (OSS), and protection (closed source):
(1) Discovery: Metlo scans your API traffic and discovers all your public endpoints. This is especially useful for finding legacy, undocumented, and shadow endpoints your security team may not be aware of—a particularly nasty way to end up with vulnerabilities. We scan each endpoint for sensitive data (address, phone numbers, ssn, account info, etc) and assign it a risk score so you can instantly understand your highest-risk endpoints.
(2) Testing: Metlo runs a suite of automated tests against your API traffic and endpoints so you can find vulnerabilities before an attacker does. We find issues like unauthenticated endpoints returning sensitive data, no HSTS headers, PII in URL params, and many more. You can also write your own tests.
(3) Protection: Metlo analyzes ongoing traffic patterns and surfaces anomalous behavior so you can catch and shut down potential attacks in real-time. (This is not part of our open-source offering though.) Our ML Algorithms build a model for baseline API behavior and any deviation from this baseline is surfaced as soon as possible. Our UI gives you full context around any attack to help quickly fix the vulnerability.
We’ve tried to make it easy to set up and use Metlo (though deployment can still be easier and we’re working on making it so). You can self-host on AWS, GCP, etc. (should take <5 min to do it) or use our hosted service at https://app.metlo.com.
We make money by charging for our hosted service, protection features, multiple users, SAML/SSO, RBAC, audit logs, and support. As...
37 comments
[ 8.8 ms ] story [ 241 ms ] threadAnd if we can help with anything, I'm at shri@metlo.com :)
Being a solo dev with some higher than comfortable risks, I'm worried that I might mess up and let my customers down. This is another line of defense that I'll be adding tonight. Any and every defense will help me sleep better at night.
I'm sure Metlo's a little rough around the edges (being nice to ourselves, "little") so pls send us all your feedback in our discord community / at [shri,akshay]@metlo.com! :)
I’m working on something similar, but fully-automated, with declarative configuration, for REST, GraphQL and gRPC APIs:
https://github.com/stepci/stepci
Ps. Just gave you a star on GitHub, would love to see where you guys are going!
Edit: And thanks for the star! :)
Also what's the diff between what you do and cloudfilt
Re: diff between us and Cloudfilt -- Cloudfilt seems like a primarily bot-protection tool while we help find all your endpoints, rank them by risk, classify the sensitive info they expose, test against OpenAPI specs (or generate them based on your traffic), find and protect against anomalous requests, etc…
My biggest issue with most fuzzing tools has always been the high rate of false positives. When I worked at Uber, we intentionally never exposed these tools to dev teams because it was too "noisy" to bother with. Most of the alerts were false positives 90%+ of the time and we eventually ignored them (even though were the security team).
How do you avoid that alert fatigue trap? Do you have a plan to ensure a high signal-to-noise ratio?
1) We're a bit different from a standard fuzzing tool, instead of generating traffic to send to an API we find vulnerabilities by analyzing real production/staging traffic. This gives our models a better understanding of how the API actually works. Although we might add a fuzzer at some point!
2) We split out very high signal vulns (https://demo.metlo.com/vulnerabilities) from vulns/attacks that we detect with our ML models that may have some false positives (https://demo.metlo.com/protection)... Different classifications give you a better way to triage any alerts.
3) We're putting a lot of effort into making our models really good, we're not comfortable with our tool having high false positive rates so when there's a model that is returning 90%+ false positives were aware of that and don't even add it :)
Thanks for the feedback and playing devils advocate!
We're (eventually = 2-3 wks) likely going to price on usage so we should def chat! :)
Any security tool that helps devs has to go to market through opensource in my opinion.
If you have any feedback or advice btw, pls email me at shri@metlo.com! I'd really appreciate it! :)
Are you folks hiring?