Transcript
to talk about, that I wanted to talk about, was why we should think of APIs as critical infrastructure, right? Like, it's the title of the webinar, you know, and I think that the number one thing that comes to my mind when I think about what is critical within a business is, does it touch money or customer experience, right? Those are kind of the two top of mind pieces for me. And one of the things that we see increasingly, you know, here at Wallarm and, you know, with our partners over at Postman, you know, when we look at APIs, we see that they are really a revenue driver for a huge number of organizations today. And so, Craig, I don't know, does that line up for you? Is that why you think of APIs as critical infrastructure, or is there something else there for you? Yeah, 100%. I mean, we've spent the past decade or so securing networks and the cloud, but the reality is that business runs on APIs now. I think Sam Altman had a really good quote saying, every company is now an API company, whether they want to be or not. APIs used to be technical plumbing, and now they're not that. As you pointed out, they sit directly in the path of revenue, identity, critical information data. Absolutely. You know, you bring up the issue of cloud or network infrastructure, and I think that also brings to mind when we think about infrastructure is what is the cost of downtime, right? You know, I think there's a very clear understanding for a lot of security orgs, a lot of IT orgs, what it means when network infrastructure goes down or cloud infrastructure goes down. But I think the reality, as you mentioned, is that with APIs being in that business critical path, that's also now a place where API downtime is really business downtime, or a breach that focuses on APIs is really something that is breaching business critical systems. So I don't know. Hopefully that resonates for folks online. If there's some other reason that you view APIs as critical infrastructure, please feel free to share in the chat. But hopefully that at least brings to top of mind some of the reasons that APIs really ought to be treated like the critical infrastructure that they are. With that, I'd like to talk about how we treat critical infrastructure. You know, and Craig, I'm going to ask you to speak to a lot of these. In terms of what we do from a security and an IT perspective for things that are already recognized as first-class infrastructure objects, like network and cloud, and then seeing where we're at with APIs, where most organizations are with APIs in your experience. So the first one that I want to look at is asset inventory, and I think that's something that we definitely see being a strong part of security and IT in network and cloud. Where do you think most orgs are for APIs when it comes to that inventory? I would say complete inventory is probably aspirational for most organizations that I engage with. Maybe the external facing APIs or things that are going in and out of their environment are well understood or documented at least. But APIs that move data internal to an environment are often kind of more tribal knowledge, and without those, it's really hard to understand how data truly flows in an environment, which becomes incredibly relevant as companies are going through AI transformation. Absolutely. I have seen in some of my past orgs, I think very manual attempts at these kinds of inventories as well. You mentioned sort of that North, South, East, West, that maybe we're getting better coverage on APIs that are public facing, less so on internal. The other thing that I've seen a lot of is just manual process around documenting these. Is that something that you've seen as well? Yeah, 100%. We'll talk about this in a little bit about AI transformation and all of that stuff, but how something is documented and supposed to work at a state and time inspection versus how it is actually working is becoming incredibly important. That understanding of how things are operating at runtime is critical. I think overall, we gave this one a grade of partial, that organizations are maybe trying but it's really difficult to get to that complete and continuous inventory around API assets. Next one that we'll talk about is, you actually already brought this up, is runtime monitoring. Going beyond just the behind the scenes to what's happening in production, is that something that you think orgs are having a hard time with, with APIs? Yeah, 100%. I think we've been told shift left, shift left, shift left for so long. Then now, with these various AI components being able to actually execute on behalf of us, runtime is now very, very important, but I haven't seen a lot of orgs that have a good understanding or have a solid understanding of how everything is operating at runtime. All right. When we look at budget, this is something where obviously I think there is very clear both budget owners and budget line items for networking cloud security, networking cloud IT infrastructure. Do you see a lot of companies that have a specific line item for APIs or is that a little more rare? I think it depends on the industry. If you're maybe more tech forward or if you already have the understanding that your business operates on APIs, I think it's likely that you have it as a budgeted line item, but if not, then it's probably more of a best effort bundled in with your WAF or CEN or something like that. It's probably something that is more of a checkbox type of approach and isn't a dedicated budget item. Gotcha. Again, on that partial rating here, I wanted to also talk about reporting since this is something that when we think about, we talked about uptime earlier, right? That's something that we have really strong reporting on in networking cloud in most cases. Do you think that API reporting is reaching that same level for most organizations or no? I would say no on this one, but I would say maybe with a little bit of a caveat on a not yet because more and more CISOs that I talk to are asking like, how do I prep my board for these types of questions as we're going through AI transformation? How can I partner better with the business? And I think those things are starting to come up more often, but I would say that it's probably very early stages. Okay. So definitely hearing that the AI transformation is driving maybe some urgency around that. For sure. Dedicated ownership. This one, I think, I have strong opinions about, obviously, I think when we look at network or cloud infrastructure, there's very clear owners for IT, responsible for uptime, et cetera, security responsible for ensuring that there's not a breach. I'm personally not seeing dedicated ownership of API security in large part because I think that APIs are so incredibly cross-functional and often become sort of the odd thing out when we look at that. Is that lined up for you as well, Craig? Um, yeah, I guess it would probably go back to the dedicated budget line item. If it's a tech forward industry, it's probably something that there is a dedicated, at least a security overlay, but as far as like an overall infrastructure side of it, it's probably more team by team. Yeah. You know, I think I've also seen that be affected by the fact that there are different, you know, teams, but then there are also other, lots of other organizations, you know, sub organizations are dealing with APIs on a day-to-day basis, even if they're not part of a dev or a coding team. So, you know, definitely, I think an interesting point about that infrastructure layer. Our last one here is around regulatory coverage. You know, obviously, I think regulation's well-known in the networking cloud space. How is that evolving for APIs? I would give this one maybe a half grade too, because there's certainly things that we could point to, but how well they're understood and audited, like the audit effectiveness is, can vary pretty, pretty wildly. Definitely. Well, you know, I think that the very clear trend here is that while some of the aspects of security and governance, when it comes to APIs, you know, there's an understanding of urgency or importance, there's definitely not mature coverage across the board for the majority of organizations. Any other takeaways here before we move forward? No, not on that one. Sorry, I was just answering a question in the chat. Oh, no worries, no worries. And yeah, do keep the questions coming in the chat. You know, the thing that we're going to move into next, I think, is trying to get an understanding of why APIs are not treated as critical infrastructure. If we can see how important they are, why is there this gap between the way that we treat other infrastructure apps and the way that we treat APIs? And you've mentioned AI a couple of times, so I'll hand it over to you to chat about this slide. Yeah, I think this one is really interesting, and it paints a perfect visual for something that I've been talking about, is if you understand the API layer and you're going into AI transformation, maybe this slide makes a lot of sense for you because you understand you're creating and chaining a lot of things together. But if you're coming at it from the other angle of the AI layer, going back, because there's this layer of obfuscation, it might not be as well understood that you're creating all of this connectivity because, again, there's a layer of obfuscation there, and a lot of it is almost pre-set up for you. So when we go into organizations, when we talk to AI architects and things like that, this problem statement might not make as much sense. But when we go talk to security teams and teams that have been dealing with APIs internally and externally, this makes a lot of sense. And one of the questions that we got in the chat just a second ago that I wanted to answer, I just want to make sure I don't get it wrong, is how does agentic AI and interconnected systems expand the attack surface for APIs? So I would say, again, all of this AI connectivity is run on APIs, so it's expanding the attack surface. But then, really, if you look at any threat sensors report, ours, CrowdStrike, anyone else's, what you're really seeing is the speed is increasing. You're chaining a lot of identities and tools together because API security has been, again, from what I've seen, mostly aspirational for internal connectivity. So there's a lot of over-provisioning, and you're driving towards the same security concepts that we've always been talking about, least privilege, all of that. And that isn't well understood in this API layer just yet. So when you connect an MCP server or AI agents or give these tools the ability to act on your behalf, it will take whatever path it needs to take to get the job done, and that's where you start to see data flowing in ways that you normally wouldn't expect. Again, that shift right mentality of needing runtime observability and security all of a sudden becomes very, very important. So I hope I answered your question and kind of explained this slide. Yeah, absolutely. I think that was very clear for me, hopefully clear for our friend JC as well. You mentioned this huge overlap between AI and API risk. These are some stats that we pulled together from our 2026 API threat stats report. But this one that was so interesting to me is the extent to which AI vulnerabilities really are API vulnerabilities. It's something that I've been thinking about a lot is that AI security is API security and vice versa. So I think that you talked about that in terms of the volume and the speed, but it's really something that's proven out in the numbers when we look at them more specifically. I think a couple of... Yeah, sorry, Craig. No, I was just going to say, you nailed it. It didn't really create the problem, it just really accelerated it. The data proves it, exactly. Yeah, absolutely. You talk about that acceleration, we're looking at close to 400% year-over-year vulnerability growth. I think that MCP, Model Context Protocol, is driving a portion of that, but realistically just that overlap is really interesting and I think really important. And the speed in which you can get in and out of these environments is absolutely astonishing. I think the CrowdStrike threat stats report put out something that said the average breach time was like 29 minutes and the fastest that they had was 27 seconds. So you're talking about everything operating at machine speed in what traditionally has been a human-centric security model. So it's just an evolution. I think that's so interesting. When you look across maybe your career in security, when I look back at mine, I think that's in strong contrast to things that we saw in the past. When we looked at ransomware as the top threat in the market, we were seeing longer and longer dwell times for ransomware prior to execution. And so it was very much about that long game and understanding what was in the environment. And now when we look at AI and we look at these API pieces, it's really so accelerated. It's so fast, not just in terms of the market accelerating, but also in terms of, as you know, it's so incredibly short these days, so very interesting. When we look at this, I think, you know, we talk about the extent to which, you know, cloud native architecture, AI, agentic AI are all causing this incredible growth of APIs, but we also have to look at what are the consequences of that, right? I think that we think about sprawl, but we also have to think about what sprawl means. And, you know, in the instance of APIs, that's often going to mean that there's multiple entry points for individual, you know, for environments, you know, there's going to be, you know, significant, like you said, machine to machine communication that's occurring without human oversight, you know, and ultimately, I think that that leads largely to significant visibility issues. When we think about that, you know, are there other specific problems or, you know, within this visibility group, you know, things that you're seeing, Craig, that are really, you know, causing significant issues? Yeah, I think we talked about it a little bit at the beginning, right? Like clear, defined ownership. And we also have to acknowledge the pace at which everything is changing. I mean, it was kind of, we had an interesting conversation with Shane, our CEO, the other day that he said he's never seen something be adopted so fast. He was like, he wasn't around when the wheel was created or fire was first discovered or whatever, but everything else was met with some sort of pushback, telephone, internet, everything else, right? But every organization is kind of diving in the deep end of AI. And what you're seeing is a need for dramatic change because like application reviews previously would be, you know, you'd sit down, you talk about how the API was designed, rate limiting, how data was transmitted, all of this stuff. But again, with all of this AI kind of adoption, that layer is slightly obfuscated. So we're creating all of this connectivity that may or may not be recognized. And then the security team is in this very interesting position where they have to not only secure all of the legacy tech stack, but all of the other stuff that the business is kind of running off and doing. And there's no provisioning process here where they're stopping by the CISO's office and saying, hey, we're thinking about doing this. What do you think? You know, it's very, very important now for security practitioners and professionals to learn how to partner with the business and be curious about that, because as this slide says, you can't protect what you can't see. And if you're not aware of what your business colleagues are doing, you're likely going to be left in the dark to some extent. And all of this starts again with observability and needing to understand really what is out there, what is authorized to be out there, what it is supposed to be doing and how it's supposed to be doing it. Yeah, that right there is the biggest issue that I'm talking to most CISOs about right now is we just simply don't know what's out there, what's being spun up, what's not. So kind of starting with this turning on the lights and getting rid of all the shadow assets, similar to how just like we did when we moved to the cloud and any other tech leap forward, right, it's just getting back to the basics, find everything we have, drive it to least privilege. We know how to do this. It's just some new acronyms. So do it in the clear, constructed way that we know how to. And the hardest part about this is going to be establishing a clear owner that is capable of operating across multiple business units because everybody's creating the problem. We can't just we can't just treat kind of the the symptoms. We need to go to the root of it. Yeah, you mentioned, you know, shadow IT, which obviously a concept that's been with us for many years. And I think it's it's fascinating when we look at that and when we think about that, AI is, again, that multiplier, right? So let's say that somebody introduces a new AI tool to the organization that maybe they didn't clear, as you said, with the security team. That's not just one new new point. That's a huge number of API calls that can be made to either internal systems if somebody's hooked the tool up that way. You know, and so I think it's like you said, it's the same problems, but definitely at a different scale. We talked a lot about, you know, APIs being this cross-functional piece. And so I just wanted to dive a little bit into some of the ways that we're seeing this. Obviously, maybe you can speak to security teams, what their view on APIs is, but we also have to look across other orgs that are interacting with APIs since they are so cross-functional. You know, anything on the priorities for security orgs or particular challenges there? Yeah, I would say that, you know, again, it just goes back to partnering with all the various stakeholders because everybody has a piece of the puzzle and the most effective security practice here will be who partners the best. We can buy tools, we can write down policies and all of that type of stuff. But whoever partners best with the business and truly understands what's going on, that's probably going to be the most effective security strategy. So being curious, again, caring about risk and exposure, but tying it back to the business impact, right? You know, simple questions. Can we answer how many of our APIs transmit sensitive data or how many of them are revenue generating? What would the business impact be if this went out? Various things like that. I think being able to tie it back to a business risk or uptime, like we were talking about earlier, becomes very important because the security team only has so much budget and they can't be effective without being more of that kind of internal advocate to here's why this matters to you, not just security says you have to do this. Yeah, you know, I think you're pointing to a tension that obviously is very inherent to a lot of orgs that are tech forward, which is that that balance or push and pull between security control and then speed of innovation or speed of creation. Is that something that you think applies in the API space in the same way that it does in other tools? Oh, yeah, 100 percent. I mean, everything that we do is going to have to be at the machine speed now, like everything we're doing is speeding up so, so fast. It's going to be very relevant that all of these APIs have uptime, that they're protected from business logic abuse. And that's the that's the other thing about about this connectivity is that it was designed to give us data. So it's doing what it's designed to do. We just have to protect it not only from the like the vulnerabilities and the security issues, but we also have to make sure that it was designed and implemented well so that it's not subject to business logic abuse and things like that so that there's multiple different ways to kind of attack these things. And again, that's why that shift right mentality of understanding not only how it's supposed to work, but what what it is actually doing so that you can develop a baseline for risk and then build your security program around that. Definitely. You know, I think the last group that comes to mind for me is obviously compliance teams. What are you seeing in terms of evolving landscape from a regulatory and compliance perspective when it comes to APIs? I think it's it's being. In the same way that we had like a shift in identity around the covid time frame where it was always a part of every compliance or auditors list, it was kind of a OK, you have something and then as it became more relevant, it was more understood and then it was deeper inspected. I think we're going to go through that same type of transition in the API security space just because, again, now it's it's very front and center. Where before it was, you know, kind of technical plumbing and it good enough was good enough. And now it's not. Yeah. And the you talked about the speed of the shift and the magnitude of the shift. And I do think that really, you know, the shift to work from home and the pandemic really has that same sense of being, you know, a full paradigm shift that happened incredibly quickly around, as you mentioned, identity as people are accessing all of their resources remotely. Absolutely a great analogy for the shift that we're going through right now with AI and API regulation. So, you know, I think that the other thing that we have to look at is who's who's solving the problem, who's trying to solve the problem. How is that going? You know, when we look out across the landscape, something that I see is that there are many tools that are tangentially touching some of these problems, but aren't necessarily like you said, we're cobbling something together that doesn't create that full coverage that's really needed. You've mentioned, you know, WAF web application firewall a couple of times during this during this chat. Why specifically is WAF not not solving this problem? Well, there's I mean, there's a few there's a few things you can talk about there. Number one, just pure payload inspection size. It's well documented that it only inspects a very small amount before passing traffic through. Again, it's very human centric. It needs to be tuned constantly. And we're in a machine speed world. But I think the real thing to talk about here is that there's a lot of WAF technologies that have API security as kind of like an add on feature or something that can be kind of bolted on. But that kind of goes back to that good enough is no longer good enough and needing to shift into the runtime layer because. The complete observability is now required to have a solid security strategy, especially as we continue to roll out more and more connectivity with these AI tools. But I really think it goes back to building a big wall, like a big solid perimeter. And I'm not saying WAFs are still needed. Of course, like I said earlier, we have to secure all of the legacy tech stack, too. But building big walls is great. But now we need to understand what's happening inside of it. That's I guess that's kind of the analogy I'd use there. Yeah, absolutely. I think the other piece that I'm looking at in my day to day is around actual API tools that are our purpose built for APIs. Something I'm seeing a lot of is that a lot of those vendors, API gateways, for example, are really about the IT side of API management, right? So there's limited security functionality. It's really more about just managing the API tools that are in the environment without the ability to detect or block attacks. And that's something that I think we've also seen haunt standalone API security products as well. Obviously, some have some native blocking. But I think that there's this gap where a lot of tools are really focused on observability rather than on protection or real time blocking. Anything that sticks out to you there? Yeah, I mean, look, the last thing we need is another flashing light that tells us we have a problem without being able to solve it. I think the days of those types of tools built purely around visibility are vastly coming to a close. But it's important to have a well-rounded understanding of all of your APIs, whether that's governing them, the observability side, like you talked about detection, the protection side of things, and then testing as well. But you have to solve all of the pieces of the puzzle to have a good program. So just being able to see your APIs doesn't really do much other than give you a solid first start. It's a nice first step. And it's definitely a leg up on nothing. But I think it's something that has to be built upon. It's not enough to just alert anymore. I think we have to provide value. Yeah, I think we'll talk about it in a little bit. But we'll be sharing an assessment that folks on the call can use. Just to kind of walk through, we had that big chart of here's all the green check marks, and here's maybe some of those red Xs, yellow warning signs, and helping folks to understand where is my org at right now, and what can I be doing to move past that? So I think that recommendation of going beyond visibility into a more well-rounded space of visibility plus protection plus testing plus governance is really important. So we think about this a lot. We say APIs should be treated as infrastructure. I think the other really compelling argument for that is that attackers are treating APIs as critical infrastructure. as critical infrastructure. So again, a lot of stats on the slide, we won't go through all of them individually, but I think the overarching story here is just about the fact that this is a number one attack surface for bad actors now, and that we have not only a really wide range of attacks that are working, but also specifically attacks that don't require really intense, deep technological ability to be able to execute, right? We looked at this 59%, close to 60% of API attacks actually don't even require authentication to execute. And so I think that the gap is very much there, very much real, and it's pointed out by the fact that this is where attackers are spending their time and their energy. Yeah, I think that's a hundred percent. I mean, like I get some flack for saying this sometimes, but APIs, excuse me, the attacks don't need to be super high-tech right now because the low-tech, high-speed attacks are working. Again, reference the reports on how fast things are getting in and out of environments. And I'm not saying that no high-tech breaches are happening. Obviously that is true, but why do it the hard way when the easy way is right there is kind of, and this just goes to my earlier point about driving towards the core security principles, understanding the identities that are flowing through there, what they have access to, the data's classification, and all of those things driving everything back towards those core principles, these numbers will start to shrink. But this has been kind of, again, an aspirational thing for most organizations that I've engaged with. And now it's very top of mind, which is great because we see massive security improvements when that happens. Again, tying it back to like identity during the COVID times it was painful for some companies that the pivot was hard, but everybody got better for it. And then including employees work lives got better and all of that stuff. And that's exactly what will happen with this AI transformation. It'll make lives better. The employee experience would be better. Security will have to level up, but as a tangential benefit of that, we'll get tighter with the business and everything will improve because of it. Yeah. To use another analogy, a friend of mine, a colleague of mine who currently works for an application security group talked about APIs as being like the gold rush for attackers that right now there's just nuggets laying out in the street. You know, and so there's going to be this huge rush to go and exploit that, take advantage of that. And that really is, we can step up security over time. That will, like you said, that'll reduce, we'll get the gold behind vault doors, you know, but right now it's really there for the taking as far as attackers are concerned. So speaking of, you know, cost and all of that, you know, these are, again, some of the breaches that we've seen, you know, this year. Something that is very interesting to me when I look at API oriented attacks, breaches, et cetera, is the sheer volume of these attacks that we're not talking about thousands or hundreds of thousands of customer records. We're talking about millions of, you know, customer records, millions of, you know, people's data that's been exposed, you know, and so I think that something that we shouldn't underestimate, you know, is how big the blast radius is on these types of API attacks. Yeah, and kind of going back to the point that we made earlier about the threat surface or the API surface expanding kind of exponentially, it's all at machine speed, right? Everything is interconnected and now we're introducing AI tools and everything else that can execute on our behalf and we've all used them. We see the benefits and how fast things go, but that's, going back to that 27 second breach, it's incredible and it's, no one can respond to that. The best, you know, a human centered security model is very quickly gonna be obsolete. We're gonna need more tools that can act and block and detect risky behavior because that's way too fast for a human to go investigate and respond to effectively. Yeah, I think that's another fascinating arc because you're talking about human centric security, you know, from the perspective of, you know, having humans who are part of that review process, you know, et cetera. I also think about it in terms of, you know, the objects of attacks, the objects, the targets of attacks. You know, I don't think that we're gonna see social engineering or phishing go away, right? Obviously I think those will remain part of the attack landscape, but something that I'm seeing increasingly, you know, we talk about this idea of moving toward a userless internet, right? At what point, you know, is most of our interaction with the internet really funneled through whether it's AI, LLM, other pieces, so much of the vast majority of, we talked about, you know, CrowdStrike reports earlier, the majority of internet traffic now is driven by API calls. It's not humans doing the search, it's APIs doing it on behalf of, you know, LLMs or others. And so not only I think, are we gonna see this shift from security where, you know, that's very human centric in terms of the, you know, how security is run and operated, but also that security is increasingly gonna have to account for userless, you know, headless operations that are occurring where machines are just talking to machines on the open web. Oh yeah, absolutely. I mean, that's why you see the non-human identity already exponentially outnumbering human identities, right? I mean, that's the way that things are going. Even to the point of like being in a marketing meeting the other day, I brought up, I was like, man, we haven't talked about SEO for so long. And it's because we're literally changing the way that everything is written so that it's for LLMs to go find and parse and show up in those results instead of the search engine. We were kind of talking about, when's the last time you Googled something the other day? And it's funny because it's been a minute. So it's- And even when you Google something, the top results all AI, right? AI, yeah. It's crazy how fast everything changed. It's a really awesome, exciting time to be in this space. Yeah, fascinating. You know, I think we've touched on regulation a few times, but I think it is worth noting that, you know, obviously as the cost of security breaches goes up, so does the pressure, you know, to be compliant, you know, and the types of regulatory fines and regulatory actions that we see associated, you know, with these types of breaches goes up as well. So I think, you know, we can definitely tell that this is, you know, a field day for attackers. And that does come with a very significant cost for organizations out there that, you know, like you said, are still trying to come up to speed on the API security side. So we've talked a lot about the problem. Hopefully have established that for folks on the call as a very significant one. I wanna talk a little bit about how we fix that, right? I've been in security for a number of years and something I hate is when teams focus just on FUD, right? You know, being FUDdy-duddies, it's all fear, uncertainty, and doubt. I think it's really important that we talk about how do we fix this? How can organizations fix this? Not just in terms of the tools that they're adopting, but also in terms of systemic changes that they can make internal to the organization. So I'm looking forward to diving into that now. You know, for folks on the call, if you do have any questions, please do feel free to keep putting those in the chat. I'm seeing some of those come through and we will try to address as many of those as we can, you know, in our last Q&A section. But for now, we're gonna move on to, you know, how do we solve this problem that we've enumerated here? As I mentioned, I'd love for us to start by talking about systemic fixes, right? What can we be doing? You talked about needing to play nicely with others. What can we be doing across the organization? We've talked about ownership several times. Craig, how would you recommend that organizations go about picking an owner for API security or API, you know, API management more broadly? It's kind of an interesting one because I think there's multiple components to it. Security is a good spot to start because they have a voice in every conversation. But if not, I mean, I've seen it run under multiple different teams as long as it seems to be whoever is willing to step up and own it and be the most curious about what's going on because it's gonna take a lot of curiosity to discover all the connectivity that's happening. But I would say whoever owns it, whether it's security partnering with the business or business partnering with security, that relationship needs to be very tight so that we can go through this AI transformation responsibly. Absolutely. I think, you know, the tech stack evaluation is fairly self-explanatory here. You know, as we mentioned, some applications, some tools are really oriented towards APIs, others less so, you know, but it can be a really interesting exercise to go through and say, hey, what tools do we have that are specific to this use case and which are we using as kind of that bundling checkbox? And is the bundling in the checkbox enough or is that something where we need to look at a dedicated solution? You know, and how do you do that without creating a million point solutions that don't integrate well, right? You know, we love to talk about a dedicated solution right until it feels like a point solution and then it's really, really problematic. So, you know, I think what I'm seeing increasingly in the market, you know, we have, you know, web applications, you know, protection vendors, WAP vendors, you know, building and buying API type tools because it's so important to have that platformatization of your API security so that it's not just, well, we get some visibility from our WAF, but then we have a little bit of control based on our gateway, but then we also have to have a separate observability tool. We're really looking at a market that's moving towards, you know, towards that platform as it always does, you know, in the tech space. You know, funding is that last one. What do you suggest to orgs that are trying to, you know, prove the value of, you know, of having a tool? Maybe, you know, security has already said, yes, we need this, but we've got to get, you know, funding at an exec level. How can orgs prove out this? No, really, APIs should count as infrastructure, you know, should be treated in this way. Yeah, I think there's a couple approaches to that. I mean, the ways that security seems to be going about it is tie it to compliance, right? Tie it to business risk. But in my opinion, the most effective way to go do that, again, is to partner with your business partners and talk about things that matter to them. Hey, if we have a runtime API security strategy where we understand how everything's working, we can improve release time by X and test those metrics out in your lab, right? Or maybe there's cost savings that you can look at by removing some tools that aren't giving you the value that you expect them to, or expect them to now that you're going into this new age. But the easiest way is really to tie it back to that business value add. Where can we help the business? Where can we automate a manual process? How can we improve release times? Where can we give you more visibility into which APIs are critical and what protections they have, what type of data is flowing through them, et cetera? That's the most effective way to get funding by partnering with the business that I've found. And then tying it to those compliance efforts and everything else is great as you continue to build the program. Yeah, I've definitely been on some customer calls lately where that came up as a primary theme, is this idea of, oh, we can help our execs see where revenue, where sensitive data is flowing through APIs, and that's giving us the opportunity to say, no, really, this is serious, this is why. So I think that's really important. We'll walk a little bit through how we view, I think, the API security space through the wall arm framework of discovery, of protection, of testing and governance. We've talked about discovery, but I think it's important to look at what does good look like, right? It's not just a point in time. It's gotta be discovery that's really continuous so we understand how is the API landscape changing because it's just too fast for manual processes, for spreadsheets. And then as you just mentioned, Craig, it's really about not just what APIs you have, it's really about not just what APIs are. but which of those is handling sensitive data, handling revenue, and really puts the company at greater risk. And as we talked about before, I think it's, you mentioned that companies maybe focus very heavily on official APIs, but miss out on internal APIs, shadow APIs, orphaned APIs, those sorts of things. Anything to add in discovery? Or? No, I think just to emphasize the top one, I think static point in time inspection was totally fine. But in this modern age now, we cannot just rely on that. It has to be, I guess the analogy that I use is, you remember those flip books where you draw a picture, then flip through them, and it play you a little movie, but there were scenes missing? That was good enough. And then now you want to watch it in 8K, right? So that's kind of the security posture we need is like the high def movie. We need deep understanding of what's happening and how. When we talk about protection, we're looking at blocking versus visibility. But maybe this one's one that's close to home for you, is that false positive rate, signal to noise ratio. Is that something that comes to top of mind for you? Yeah, I mean, who doesn't go to any security team? They have alert fatigue. It's insane. And then now the amount of connectivity that's happening, again, with the speed that it's happening at, it's a lot of noise. So having a way to kind of sift through that noise and get to what actually needs your attention is... And again, this isn't shocking to anybody. We dealt with this in every technology evolution. It's just kind of going through the motions right now. But the top one, I think, is really also critical because no one just puts a security solution in and then turns on blocking, right? So it is important to create a baseline, have a good understanding, and then step into this security program kind of programmatically. And that goes back to the discovery or observability side of things and needing to know which APIs to start with, which ones are critical, and which ones you can get to as the program matures. You know, I think the last point that I'll come back to is just saying that Wallarm is really focused on the idea of building security for the internet of the future in which userless workflows, userless APIs calling to APIs calling to AIs before you finally see that result, is something that's really critical. With testing, I think that we kind of split this into both testing, this is really geared towards organizations that build their own APIs in a lot of ways. We think about that testing during the development pipeline a lot, but you've also mentioned a few times the need for runtime testing. Is that something you want to break down here? It's two halves of the same coin, in my opinion. It's crude, like the earlier you can catch something, the better, but you want to have protection the entire way through, right? So I think both are very important. Yeah, it's definitely one of those pieces where we hear from some folks, well, I mean, we do a lot of testing before we publish APIs, but then after the fact we'll hear, oh, but we missed something and the way we found out was that an attacker found it for us. That can be very concerning. So definitely two sides of the same coin. Finally, we've talked about governance throughout. I think that the theming here is just around the ability to get that executive level view that helps you monitor these risk trends, helps you create and enforce consistent policies across an org. Is there anything else that you think organizations need to really specifically focus on when it comes to governance and APIs? Yeah, going to that executive visibility side of things, AI transformation is something that's on everybody's list right now. So being able to go in as a security leader and say, here's how many APIs we have in our environment today. Here's the protection that we have on them. Here's how many of them are internal only versus external only. And then kind of layering in your AI connectivity on top of that and having that base level would make me feel a lot more confident going into AI transformation versus just having an observability tool that kind of tells me what's out there, but nothing else. I think the risk trends is also another interesting one. Like our threat stats report, when Tim and I went through that, it was kind of interesting to see how everything is changing as MCP servers are being more widely adopted and rolled out. It'll be interesting to see how these things continue to change, but I would think that'd be also something that as a security leader, I'd want to be kind of bringing my SOC team, my IRT and all of that type of stuff up to speed of, hey, here's what we're seeing in the environment. Here's how we need to go talk to the dev teams about what they should be testing for and making sure that everybody's aligned. That it just, again, partnering closer together, it makes things a lot easier. Yeah, you brought up threat stats reports. Obviously, really cool to see the behind the scenes making of for Wallarm, but I'm also deeply a security nerd. So I'm a long time reader of, let's say the Verizon data breach report. One that I added to my list that I'll be reading yearly this year is actually the Postman state of API report. That was something that was introduced to through our partnership with Postman. But once I started digging in, it has a lot of that, again, the really meaty, not only just the data behind it, but also that really easy to read layout that I think is so much fun and something that I've always admired in Verizon. So, beyond just the tools, I think that there's some really cool content out there for folks to absorb as well. Speaking of content, this is just a little quick preview of the leave behind that you'll get as part of your email following this call. And it's just an API scorecard that lets you take a look at, are you right now a green check mark? Yellow caution sign or a red X when it comes to all of these different API security facets that we've discussed throughout the day. All these different pieces come together and just gives you maybe a way to start building that bridge that you talked about, Craig, in terms of partnering well across both business and security. You know, maybe fun, maybe a little bit spicy exercise is having your security team fill it out and having a business line team fill it out and then comparing where those teams think they're at in the org. So, definitely something that we just wanted to create to help start those conversations inside organizations. With that, I think we're coming into our wrap up here in terms of key takeaways for folks on the call and what to take back to the team. You know, you'll get the slide deck afterwards, so you'll have this as a summary, but is there anything here that you'd like to highlight, I mean, I think all of these are really solid points, but the key takeaway for me really is, the question isn't for me whether or not APIs are critical infrastructure, it's really how long we can afford to treat them like they're not. I mean, it's multiple headlines daily where AI connectivity is leaking API keys or oops, we leaked a bunch of data, we didn't mean for that to happen. It's incredibly relevant now. These are, they're no longer just the technical plumbing, they're the execution layer for all of the transformation businesses are about to go through. And starting with those base security practices is really going to make the transition much less stressful for everyone. You mentioned, you know, APIs in the news, and I think, you know, kind of the, one of the main things, the challenges that comes up for me when I'm building decks is the APIs in the news slide is always outdated by the very next week. Because by the very next week, there's a bigger and more interesting breach, you know, whether it's Amazon with, you know, 22,000 customers going down, do, you know, not even able to access the app, you know, or it's any of the ones that we spoke about during the webinar today. I think that, like you said, it's top of mind and it's only gonna become more so. With that, I'll bump us over to Q&A. I know we saw several come in in the chat and then I had a few come in direct as well. Let's start out with, oh gosh, scrolling, scrolling, scrolling, scrolling through so many here. Okay. This is, okay, this is with regards to WAF. I saw several comments, WAF, and we have a question coming in here from Florida. We already have web application firewall and do API and testing internally. Where do you see gaps that still exist in organizations that are already doing that? So for me, the gaps are where the risk is now. So WAF is not API security. They're not the same. Some WAFs may offer some API protection, but it's limited, I would say. Testing is a fantastic start, but it's not the same thing as runtime protection, which is again, kind of going to be more and more relevant as we connect more AI tools to execute on our behalf. But for me, kind of even in the way that the question was phrased is exactly where the risk is. The risk exists in the gaps between these solutions that have been tied together for human-paced API access, maybe is a good way to say that. But that's a great question. Yeah, I think that, to add on there, I think it can be incredibly frustrating, right? Because like you mentioned, security teams consistently under-budgeted, under-resourced, really constrained. And when markets are evolving like this so quickly, it can be incredibly frustrating to already be doing so much, right? We're already doing so much and there's still a gap. How do we solve that? How do we plug that in? And it's, I think again, that convergence that we were talking about in the market earlier of looking for solutions that are doing more than one thing that are not just coming in and saying, all right, well, we got a little bit here and a little bit there and we're going to try to tape them together, but this isn't a time to MacGyver. This is a time to have the right tools for the job. So another question that came in here, watching this webinar was great, but also made me feel a little scared because I don't think we know how many APIs we actually have today. What's the first step that you would recommend? Well, first of all, that's okay. It's a, don't need to be leading with the scary side of things. I would say, I would say number one, it's fine. You probably have a better idea than you think. You could start with looking at your existing ingress, egress security solutions and seeing if you can get an idea there for at least your external facing. But then the internal side of things is a little bit more, a little bit trickier. Because again, it's a lot of tribal knowledge. I would say go out and get a good observability tool. If it's something that you might already have in your infrastructure security team that you can go out and start looking at traffic and tying all of these things together, talk to your various development communities and see how they're tracking APIs that they're rolling out, including the identities associated with them. And then it's just kind of starting to put the puzzle together. Yeah, I think it's another place for that partnership that you mentioned since there's almost certainly, it is scary to go, oh, I don't know what we have, but there's almost certainly folks within your org who are managing some of that already. So starting to piece the puzzle together and of course being in the product team for Wallarm, I'd be remiss if I didn't say, reach out to Wallarm, since that's definitely, I think, one of the specialties that we focus on in-house. That does bring us up right to the hour. So if we did not get to your question online, please know that we will follow up following the webinar with recording, with the recording and leave behind assessment and a great recommendation, great reminder to check out our next webinar upcoming in April. where we're gonna take a deeper dive into the AI piece of this, really going beyond APIs as infrastructure and looking much more closely at how APIs and AIs are interacting.
