 Okay, welcome back everyone to theCUBE's live coverage here in Boston, Massachusetts for AWS Reinforce 22. I'm John Furrier, your host with Dave Vellante, co-host of theCUBE at Trayron's and a CTO and founder of Sequence Security, CUBE alumni, great to see you. Thanks for coming on theCUBE. Yeah, thanks for having me here. So when we chatted, you were part of the startup showcase. You guys are doing great. Congratulations on your business success. I mean, you guys got a good product in a hot market. You're here. Before we get into it, your perspective on the keynote and the talk, tracks here and the show, but for the folks that don't know you guys, explain what you guys, take a minute to explain what you guys do and key product. Yeah, so we are in the unified API protection place. I mean, a lot of people don't know what unified API protection is, but before I get into that, just talking about Sequence, we've been around since 2014, but we're protecting close to six billion API transactions every day. We are protecting close to two billion customer accounts, more than $2 trillion in customer assets and 100 million plus sort of data points that we look at across customer base. So that's who we are. I mean, of course, we all know APIs is the basis of cloud computing and you got successful companies like Stripe, for instance, you know, you put an API and you got a financial gateway. Billions of transactions. What's the learnings? And now we're in a mode now where single point of failure is a problem, you got more automation, you got more reasoning coming, a lot more computer science, next gen ML AI there too, more connections, no perimeter, right? More and more use cases, more in the cloud. Yeah, so what we're seeing today is, I mean, from six years ago to now when we started, right? Like the monolith apps are breaking down into microservices. What effectively what that means is like every of the, every such microservices talking APIs. And so what used to be a few million web applications have now become billions of APIs that are communicating with each other. I mean, if you look at, I mean, you spoke about IoT earlier, I call like a Tesla is an application on four wheels that is communicating to its cloud over APIs. Everything is API today, 80% traffic on the internet is API. Now that's stated transit right there. Yeah. Couldn't resist. Yeah. Fully encrypted too. Yeah, well, hopefully. Maybe, maybe. You don't know yet. But seriously, everything is talking to an API. Yeah. Every application. And there is no single choke point, right? Like you spoke about it, like everybody is hosting that application in the cloud environments of their choice. AWS being one of them, but it's not the only one, right? Your APIs are hosted behind a CDN. Your APIs are hosted on behind an API gateway, behind a load balancer, the interest controllers. There is no single choke point. So what's the problem? What's the problem now that you're solving? Because one was probably, I can imagine, connecting people, connecting the APIs. Now you've got more operational data. Yeah. Potential security hacks, more surface area. What are you facing? Well, I can speak about some of the well-known sort of exploits that have been well-publicized. Everybody gets exploited. But I mean, some of the well-knowns, like if you heard about Expedient last year, there was a third-party API that was exposing your credit scores without proper authentication. Facebook had Ebola vulnerability some time ago where people could actually edit somebody else's videos online. Peloton, again, a well-known one. So everybody is exposed, right? But that is the end results, right? But it all starts with, people don't even know where their APIs are, and then you have to secure it all the way. So, I mean, ultimately, APIs are prone to business logic attacks, fraud, that's what you need to go and protect. So, is that the first question? Is, okay, what APIs do I need to protect? I got to take an API portfolio inventory, is that? Yeah. So, I think the starting point is where are my APIs? And so, we spoke about there's no single choke point, right? So, APIs could be in your cloud environment. APIs could be behind your cloud front. We are here at Reinforce today. So, APIs could be behind your AKS, Ingress Controllers, API Gateways, and it's not limited to AWS alone, right? So, knowing the unknown is the number one problem. So, how do I find them? I asked Fred, hey, where are our APIs? No, you must have some automated tooling to help me. Yeah, so, I, Sequence provides an option without any integration, what we call it the API spider, like, we give you visibility into your entire API attack surface. Without any integration into any of these services, where are your APIs? What's your API attack surface about? And then, sort of, more details around that as well. But that is the number one. Is that agentless or is that an agent? There's no agent. So, that means you can just sign up on our portal and then fire it away. And within a few minutes to an hour, we'll give you complete visibility into where your API is. Is it a full auditor or is it more of a discovery? Or both? So, number one, it's discovery, but we are also uncovering some of the potential vulnerabilities through zero knowledge, right? So, we've seen a ton of Lock 4J exposed servers still. Like, recently there was an article that Lock 4J is going to be endemic, that it's going to be here for a long time. Where's your mask on that one? That's the COVID of security. Absolutely, absolutely. So, you need to know where your assets are. What are they exposing? So, that is the first step, effectively, discovering your attack surface. I'm sure it's an efficiency issue, too, with developers. Having the spider allows you to at least see what's connecting out there versus having a meeting and going through code reviews, right? Is that another big part of it or no? It is actually the last step, but you actually go through a journey. So, effectively, once you're discovering your assets, you actually need to catalog it, right? So, I know where they're hosted, but what are developers actually rolling out, right? So, they are updating the API endpoints on a daily basis, if not hourly basis. They have the CI CD pipelines running. Yes, dev ops, welcome to dev ops. It's actually why we do it. Yeah, and people have actually, in the past, created manual ways to catalog their APIs and that doesn't really work in this new world. Humans are terrible at manual cataloging. Exactly, so cataloging is really the next step for them. So, you have tools for that that automate that, using math, presumably. Exactly, and then we can integrate with all these different choke points that we spoke about, there's no single choke point. So, in any cloud or any on-prem environment, where we actually integrate and give you that catalog of your APIs, that becomes your second step, really. Okay, so. What's the third step? There's a third step, and then compliance. Compliance is the next one. So, basically, catalog. There's four steps. There's actually six, so I'll go. So, discover catalog, then compliance. Yeah, compliance is the next one. So, compliance is all about, okay, I've cataloged them, but what are they really exposing? Right, so, there could be PII information, there could be credit card information, health information, so, I will treat every API differently based on the information that they're actually exposing. So, that gives you a risk assessment, essentially. Exactly. So, you can then start looking into, okay, I might have a few thousand API endpoints, like where do I prioritize? So, based on the risk exposure associated with it, then I can start my journey of protecting. So, that's. That's the remediation, that's fixing it. Okay, keep going. So, what's four? Four. That was that one, fix it. Four is the risk assessment? So, number four is detecting abuse. Okay. So, now that I know my APIs, and each API is exposing different business logic. So, based on the business you are in, you might have login endpoints, you might have new account creation endpoints, you might have things around shopping, right? So, pricing information all exposed through APIs. Every business has a business logic that they end up exposing, and then the bad guys are abusing them in terms of scraping pricing information. It could be competitors scraping pricing, they would be doing account takers. So, detecting abuse is the fourth step, right? The fifth one is about preventing that, because just getting visibility into abuse is not enough. I should be able to detect and prevent natively on the platform, because if you send signals to third-party platforms like your Vabs, it's already too late, and it's too coarse-grained to be able to act on it. And the last step is around what you actually spoke about developers, right? Like, can high-shift security towards the left? But it's not about shifting left, just about shifting left. Obviously, you want to bring in security to your CICD pipelines, to your developers, so that you have a full spectrum of API security. Sure, Ram, Dave and I were talking earlier about how cloud operations needs to look the same. Yeah. On cloud, premise, and edge. Yes, absolutely. And edge is a wild card, because it's growing really fast, changing. How do you do that? Because APIs will be everywhere. How are you guys going to rein that in? What's the customer's journey with you as they need to architect? Not just deploy, but how do you engage with a customer who says, I have my environment, I'm IDAPS, I'm going to be on premise and edge, I'll use some other clouds too, but I got to have an operating environment that's pure cloud. So, Vinny, like you said, we live in a heterogeneous environment, right? Effectively, you have different, you have your edge in your CDN, your API gateways, so you need a unified view, because every gateway will have a different protection place, and you can't deal with five or 15 different tools across your various different environments. So what we provide is a unified view, number one, and the unified way to protect those applications. So think of it like you have a data plane that is sprinkled around, wherever your edges and gateways and English controllers are, and you have a central brains to actually manage it in one place in a unified way. I have a computer science or computer architecture question for you guys. So Stephen Schmidt again said single controls or binary states will fail. Obviously he's talking from a security standpoint, but I remember the days where you wanted a single point of control for recovery. You talked about microservices, so what's the philosophy today from a recovery standpoint? Not necessarily security, but recovery, like something goes wrong. If I don't have a single point of control, how do I ensure consistency? So do I recover at the microservice level? What's the philosophy today? Yeah, so the philosophy really is, and it's very much driven by your developers in how you want to roll out applications. Number one is applications will be more rapidly developed and rolled out than in the past. What that means is you have to empower your developers to use any cloud and serverless environments of their choice and it will be distributed. So there's not going to be a single choke point. What you want is an ability to integrate into that life cycle and centrally manage that. So there's not going to be a single choke point, but there is going to be a single control plane to manage them on. So you want that unified visibility and protection in place to be able to protect each other. So there's your single point of control. What about the company? You're in series C, you've raised, I think over a hundred million dollars, right? So are you, where are you at? Are you scaling now? Are you hiring salespeople? Or are you still trying to sort of be careful about that? Can you help us understand where you're at? Yeah, so we are absolutely scaling. So we built a product that is getting, that is deployed already in all these different verticals, like ranging from finance to retail to social to telecom, anybody who has exposure to the outside world. So product that can scale up to those demands, right? I mean, it's not easy to scale up to six billion requests a day. So we built a solid platform. We've rolled out new products to complete the vision in terms of the API spider I spoke about. The unified API protection covers three aspects of all aspects of API life cycle. We are scaling our teams from go to market motion. We brought in recently our chief marketing officer, our chief revenue officer as well. So putting all the new pieces in place. So you guys are like API observability on steroids. In a way, right? Because you're doing the observability. Yes. You're getting the data analysis for risk. You're having opportunities and recommendations around how to manage the stealthy attacks. And essentially, you're the API store. So you guys are what we call best of breed. This is a trend we're seeing. Pick something that you're best in breed in. Absolutely. And nail it. So you're not like an observability platform for everything. No. You guys pick the focus. Specific to APIs. And so basically you can have your existing tools in place. You will have your CDN. You will have your BAFs in place. But for API protection, you need something specialized and that stuff. Explain why I can't just rely on CDN infrastructure for this. So CDNs are good for content delivery. They do your basic TLS and things like that. But APIs are all about your applications and business that you're exposing. Okay, so you- They have no context around that. So yeah, because this is a super cloud vision that we're seeing of structural change in the industry. A new thing that's happening in real time. Companies like yours are keeping a focus and nailing it. And now the customer's going to assemble these services and capabilities. That's happening. It's happening like right now. Structural change has happened. It's called the cloud, cloud scale. Now this new change, best of breed. What are the gaps? Because I'm a customer. I got you for APIs, done. You take the complexity away. At scale, I trust you. Where are the other gaps in my architecture? What's new? Because I want to run cloud operations across all environments and across clouds when appropriate. So I need to have a full up. Where's the other gaps? Where are the other best of breed components that need to be developed? So it's about the layers that you build, right? So what's the thing is you're bringing in different cloud environments that is your infrastructure, right? You either rely on the cloud provider for your security around that for rollouts and operations, right? So then is going to be the next layer which is about is it serverless? Is it Kubernetes? What about it? So you think about like a service mesh type environment. Ultimately, it's all about applications, right? That's then you're going to roll out those applications and that's where we actually come in. Wherever you're rolling out your applications, we come in, baked into that environment, forgiving you that visibility and control protection around that. Well, great, great. First of all, APIs is why cloud is based on. So can't go wrong there. It's not a headwind for you guys. Absolutely. Give a quick plug for the company. What are you guys looking to do higher? Get customers, who's that? What's the pitch? So like I said earlier, sequences around unified API protection, protecting around the full lifecycle of your APIs ranging from discovery all the way to testing. So helping you throughout the lifecycle of APIs. Wherever those APIs are in any cloud environment, on-prem or in the cloud, in your serverless environments. That's what sequence is about. And you're doing billions of transactions. You're doing six billion requests every day. Which is unheard for a lot of companies here on the floor today. Thanks for coming on theCUBE. Appreciate it. Congratulations on your success. Thank you. Sequence security here on theCUBE at Reinforced, I'm John Furrier, Dave Vellante. More coverage after this short break.