[HN Gopher] Launch HN: Metlo (YC S21) - Open-source software for...
       ___________________________________________________________________
        
       Launch HN: Metlo (YC S21) - Open-source software for securing your
       APIs
        
       Shri and Akshay here - we are building Metlo
       (https://github.com/metlo-labs/metlo), an open-source API security
       tool. Metlo works by discovering all your API endpoints, running
       security tests, and detecting potential attacks. It runs before
       your APIs go into production, and also in real time, alerting your
       security team when anomalous usage patterns are detected. Metlo
       secures your APIs against the OWASP Top 10 (broken auth, injection,
       excessive data exposure etc.) and more.  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 for pricing, here we're a bit
       embarrassed because so far we have the dreaded "contact us" for our
       enterprise plan with some early pricing for others. That's bad
       because, as mentioned, our goal is that you should never have to
       talk to a sales rep. However, we should have a "compare plans and
       pricing" page figured out in the next few months.  We look forward
       to hearing your feedback and ideas, and your experiences with API
       security, and are happy to answer any questions!
        
       Author : shrisukhani
       Score  : 75 points
       Date   : 2022-11-09 17:25 UTC (5 hours ago)
        
       | AnhTho_FR wrote:
       | Awesome, can't wait to try it out at Lago. Congrats team!
        
         | shrisukhani wrote:
         | Thanks! Lago seems incredible too.
         | 
         | We're (eventually = 2-3 wks) likely going to price on usage so
         | we should def chat! :)
        
       | ushakov wrote:
       | Looks interesting. Great Job, Shri and Akshay!
       | 
       | I'm working on something similar, but fully-automated, with
       | declarative configuration, for REST, GraphQL and gRPC APIs:
       | 
       | https://github.com/stepci/stepci
        
         | shrisukhani wrote:
         | Thanks! StepCI looks great too; and your docs are _beautiful_!
         | :)
        
           | ushakov wrote:
           | Thanks a lot! I'm actually writing docs _as we're speaking_.
           | We use VitePress and GitHub Actions for deployment. The docs
           | look beautiful out of the box, we only changed the colors ;)
           | 
           | Ps. Just gave you a star on GitHub, would love to see where
           | you guys are going!
        
             | shrisukhani wrote:
             | Incredible. Will definitely have to check it out!
             | 
             | Edit: And thanks for the star! :)
        
       | HoyaSaxa wrote:
       | Looks interesting! I'd suggest expanding your value prop by
       | adding automated input fuzzing (e.g. changing one key in the body
       | of a `application/x-www-form-urlencoded` request until you raise
       | a 5xx). That could help uncover a slew of potential bugs and/or
       | security issues before a real user or an attacker does. It would
       | also help expand your value proposition from simply being a
       | security offering.
        
         | ashekhawat wrote:
         | That makes sense... Since we generate specifications for an API
         | automatically, it would be much more efficient (and accurate)
         | than other fuzzing tools :) We'll definitely look into doing
         | that, thank you for the advice!
        
       | quadcore wrote:
       | Beginner question: do you secure websockets?
       | 
       | Also what's the diff between what you do and cloudfilt
        
         | shrisukhani wrote:
         | Websockets -- not yet, no. We might do it in the next couple
         | months if more people ask for it. The main business logic
         | should be similar but there are some differences in the way web
         | socket traffic behaves which will require some tweaks to our
         | anomaly detection.
         | 
         | 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...
        
       | freeqaz wrote:
       | I'll play devil's advocate for a second since I've got experience
       | in this space.
       | 
       | 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?
        
         | ashekhawat wrote:
         | Hey! Yes, false positives are are a problem that we're hyper
         | aware of, and a big challenge with most security tools. We have
         | less of a problem with this than other tools for a few reasons
         | :)
         | 
         | 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!
        
       | netman21 wrote:
       | I track 31 API Security vendors (not including the big guys like
       | Imperva and Vericode.) This approach is going to disrupt a space
       | that has taken in just over a billion dollars in funding in the
       | last two years. Well done!
       | 
       | Any security tool that helps devs has to go to market through
       | opensource in my opinion.
        
         | shrisukhani wrote:
         | Thanks! (Selfishly) We really hope so! :)
         | 
         | If you have any feedback or advice btw, pls email me at
         | shri@metlo.com! I'd really appreciate it! :)
        
       | samoshay wrote:
        
         | shrisukhani wrote:
        
       | singwhenurdown wrote:
       | Looks really cool -- does it only work for projects in the AWS
       | regions listed?
        
         | ashekhawat wrote:
         | Currently we only have AMI's in US Regions, although Metlo
         | should work anywhere... Let me know which region you want to
         | deploy in and I can make an AMI there right away :)
        
           | singwhenurdown wrote:
           | us-east-2 plz:)
        
             | ashekhawat wrote:
             | Here you go!
             | https://backend.metlo.com/deploy/aws?region=us-east-2
        
               | singwhenurdown wrote:
               | Thanks!!
        
       | Boelensman1 wrote:
       | Looks very nice, will try it out later! Congratulations on the
       | launch!
        
         | shrisukhani wrote:
         | Thanks! Please reach out if we can help with something!
        
       | 4ft4 wrote:
       | Wow exactly what I am looking for right now. Congrats on the
       | launch.
        
         | shrisukhani wrote:
         | Awesome. Hope you like it!
         | 
         | And if we can help with anything, I'm at shri@metlo.com :)
        
       | mikercampbell wrote:
       | This is fantastic and exactly what I needed!!
       | 
       | 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.
        
         | shrisukhani wrote:
         | Thank you! Glad you like it! :)
         | 
         | 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! :)
        
       | vmatsiiako wrote:
        
       ___________________________________________________________________
       (page generated 2022-11-09 23:00 UTC)