Hello and welcome to another KO call webinar. My name is Alexei Balaganski. I am the lead Analyst here at KO call. And our topic for today is taking the risk out of key digital business enablers, the APIs. This webinar is supported by no name security and I am joined today by the company's head of product marketing camera camera Cal. Brave. Before we begin, just a few housekeeping rules. All attendees are currently muted. You don't have to worry about the microphones. We are recording this presentation and will be made available on our website and elsewhere. And everyone will receive a link to get to the video recording and of course to the slide deck. We'll run some polls during this webinar. So if a question pops up on your screen, please choose the option, the answer you feel most comfortable with, and we will discuss the results of those polls.
And of course we'll answer your questions in the q and a session, which will be in the end of this webinar. The agenda is structured as usual for all clinical webinars. I will begin with my part outlining the Analyst view. If I, I say so of the whole API security area, explain why it's essential and yet often overlooked or even misunderstood, then I will give the stage two Cameron who will be talking about more practical things like how API security tested, and especially how doing it according to the shift left strategy can dramatically improve your overall API security posture. And as I mentioned in the end, we will have the q and a part. And let me start the actual webinar with a quote. Few years ago, the Analyst from our Gartner have said that by 2022, API text will become the most frequent attack vector.
Now we are in 2022. And yes, I can absolutely confirm and I would even argue that API techs have become the most frequent attack vectors capable of disrupting any kind of business critical process in any kind of IT environment. And some of you might ask, but what about ran somewhere web three, blockchain, any other popular cybersecurity buzzwords? Well, the whole goal of this webinar is basically to explain why you have to consider API security at least as important as all those other things. And again, we can now run our first poll question. Basically my question is, does the organization already have a clearly established API security strategy? Can we please have the poll and I will give you some time to answer. And as I mentioned, we will discuss the results somewhat later during the q and a session.
Okay. Okay. So I said that the poll has been closed and well, I will not comment on the results yet, but it'll definitely give me the reason to actually start my presentation with a really simple but important question. What are the APIs? And just a quick reminder, APIs stand for application programing interfaces and they basically just rules and standards are for communicating between different application components or applications. The only reason they have existed for over 50 or even 60 years now is to make building complicated complex software easier. And over this decades, they have evolved from pretty simple and really obs skill technical term to foundation of many enterprise grade service oriented architectures. And then with the emergence of cloud services, they basically become the backbone for cloud service management. And then sooner or later we came to the situation where APIs have basically become the logistics for all the digital products which companies are trading in now.
And back in 2017, the well known magazine fourth has proclaimed the year that 2017 is the year of API economy. Sounds good. I cannot absolutely argue, cannot absolutely argue with that. The only problem that back then, what if people actually talked about API security? I've been following this market since around 2015 and I still remember when there was just one company worldwide which actually claimed to be in the API security company. And look how many we have now. So obviously there's probably first around 2019 when multiple high profile breaches and hacker attacks utilizing vulnerability and APIs have happened and people started to take notice. Yes, you have to deal with API security. And now in 2022, as I mentioned, APIs are the top enterprise security risk. So how did come to this? What has happened? And again, I think it's important to have a quick look at what, like why our APIs have proliferated so successfully.
But despite have summarized basically what APIs to used for before they went to the cloud and then maybe 10 years ago, just recently. And finally, where are we currently with the APIs in the world? Now we can see that APIs are everywhere. They basically power entire industries and really critical industries like finance and healthcare. And automotive. We can observe that the vast majority of all traffic on the internet is actually API traffic. And we also see that the vast majority of companies exposed to to this risks have reported, yes, they already felt the consequences of API security issues and the number of those architects has increased manyfold. And what we see now is basically that API security has already become really critical for every organization. But what happens now really like today is making the future even more complicated. We have even growing even more growing demand for new interaction models between companies which are or will be powered by APIs. We have new standards ment, we have multiple new compliance regulations pop up around the world, which will make your potential losses more severe. So basically API security tools, if no longer considered a well established material market, everything changes and we have to change along with it.
Whenever people are talking about API security or they always forget that APIs, you just do not pop up like an off the shelf software product, which you will just deploy once and then youth for 10 years, APIs evolve all the time because they have to constantly be changing, reacting to new business demands, to new technology trends and risks. And the very idea why those APIs can becomes the popular that they hide the complexity of exposing your crown jewels if you will, your sensitive and valuable data to the rest of the world. But unfortunately, this hidden complexity also makes a false impression of the safety by obscurity, if you will, which is of course absolutely not a thing. And you have to understand that APIs must be protected at every stage of this of their lifecycle. Definitely not during just the operational cycle. And I've heard a lot of times a lot of people saying, But well, we already have a security tool.
We have purchased a tool a couple of years ago and the promise is to protect us from the over API top 10 security threats. And yes, that's great. My, my answer to that would be, you are doing better than a lot of companies which don't know about the API top 10. But unfortunately while these are really well known and really common threats, they are by far not the only threats you will be facing. And of course one has to, but one has to emphasize that most of these, if not all of those are top term risks, are actually consequences of bad design decisions or bad software development practices. The reason the roots for those problems, they have been growing way earlier way before those APIs actually went into production. So the real API risks, the real question you will be facing daily, or of course you are already probably facing now are much more, they are much less technical and much more business and organizational if you will.
How do you actually know? How can you be sure that you know all of your APIs, your own or third party managed or unmanaged internal or external face? How do you even keep on top of those changes? How do you know what happens across all of your API infrastructures at any time? How do you keep your compliance or satisfied? How do you actually prevent those data breaches and how do you involve every, everyone in your company including developers into the security life cycle? So yes, you still have to think about the top 10 risks, but you also have to remember hundreds of other threats as well.
And what we have observed in the recent couple of years really is this embryo explosion, if you will, the sudden third of additional complexity in this whole API economy and API security industry, we see the emergence of new completely new types of API protocols and standards like GraphQL for example. We have seen many other deployment scenarios which go way beyond the traditional API gateways. We have seen new regulatory frameworks and of course we have daily where we have new business requirements that change daily built in traditional banking industry or something more fancy and modern like web three, distributed finance and so on. Decentralized finance, sorry. So all of this are challenges basically are underlying one statement we have to repeat again and again your quote, traditional security tools like Matthias, like web application fibers are no longer usable for API security. They never were really because those tools never knew how your APIs function from the business perspective, but now they are just hopelessly outdated and no longer safe.
So when we look at the scope of modern security of modern API security, and this is the picture I've used in quite a few of my earlier presentations just because illustration API security is complicated, it has to cover many related by pretty much individual disciplines ranging from infrastructure security to data validation, to access management and control to threat protection, transport, security, analytics and so on. But one thing we have usually emitted from our discussions before is design and development. Again, the earliest stages of the API life cycle have to be protected as much, at least as much as the the API students, the operational cycle, perhaps even more. The question of why well, and the answer is really simple. I use this term, the cybersecurity funnel to illustrate the overarching principle which actually works for every area of cybersecurity.
Cybersecurity is inherently as symmetrical. There are so many threats which your infrastructure, your services are exposed to. So you have to keep so many different holes plugged, but a hacker underneath one unpatched vulnerability or or open Porwal or anything else to actually get through and breach your entire security architecture. This is why your ultimate goal to kind of is to reduce this a little critique to make sure that you only have to deal with the most important and critical incidents and filter out all the noise. And there are really several traditional steps to do that. Defense in depth applies to every area of cybersecurity intelligent automation as well. Nothing. You hear security by design, making sure that the things you actually develop and put out to the internet are built in a way that they won't break easily. And of course this means proactive harding involving the developers to make sure that your software is developed in that way, that it's secure by design. And basically when it comes to software development or this approach is called shifting left, this is the topic of our, our webinar today.
When you're looking at the traditional development life cycle of any software, this is how it's usually works. You develop first and then you test later maybe before, maybe even after you deployed your software into and shifting left simply means doing multi at the early stages. This is how it's usually illustrated and there is absolutely nothing wrong with that picture, although I would argue for more modern development scenarios, including APIs, we have to or, or reconsider the actual lifecycle as well to probably look something like that. Even before your software or your API is built and delivered to your operational team, it has to undergo this continuous lifecycle of its own of designing, coding, testing, written and repeating again.
And this basically ends my kind introduction to the topic. This is my last slide for today where I try to summarize my points that the API evolution is ongoing. We are currently in this camera explosion stage where the overall industry experiences the sudden search in complexity and of course reach some sites into sudden search in threats and risks. Your APIs are exposed to the additional tools could not keep up before and they are completely useless. Now those, the cost in complexity skyrocket and you have to deal with those issues somehow in the only sensible way to deal with it is to, to work proactively. You have to design your APIs to be secure, you have to apply security to the entire life cycle starting from development and definitely all the way down for the operations. So shifting left or shielding right, this question is meaningless.
There is not to dichotomy anymore. You have to do both. And it's up to you to understand how much effort do you have to balance between those extremes and your shifting left should not be just doing more testing earlier. That won't be enough. You actually have to do the testing proactively in an intelligent and automated way. You have to focus on security controls, which helps you the minimize the input area of your cyber security funnel, if you will. The fewer the, the earlier you identify your problems are in your, in your lifecycle, the fewer if incidents you will have at the later stage. And well, there is still not a one size fits all solution I guess, but maybe there is, and this is where I will give the stage to our guest speaker camera who will actually be talking in much more technical detail about solutions which might not have the challenge.
Awesome. Well thank you. Let move this over a bit. Really excited to be here and expand on, on what Alexei has just said. This is such a, it's a rapidly changing and evolving topic, but it's also one that really does need to be at the forefront of any security organization's plans. So just to, to give you a little intro that I, I lead our product marketing team here at Nona Security. We've grown rapidly over the last few years and what I want to talk about is go into a couple things. First of all, the, the impact of late testing. So taking some of those high level themes that Alexei has just talked about and go into what does this mean for organizations and certain verticals, what does it mean for the security organizations? And then show you what a shift left motion looks like in practice.
And then we'll get to a q and a. So if you have questions along the way, go ahead and drop those into, into the chat. So let's talk about that impact of late testing. And I think maybe the way to frame this to think about, okay, what, what is the impact of late testing is to think about what's at stake. And the reality is that today, you know, secure APIs drive really every business. There is not a critical function at an organization that is digital, that is not enabled by, and therefore dependent on APIs. And so you, you know, think pretty much any sector, whether it's in financial services where maybe you're putting out a banking mobile app to allow your customers to access their assets. You know, if you're in retail enabling omnichannel sales, protecting patient data in the healthcare, pharma, and life sciences industry, and even if you're in a professional services organization, you know, being able to handle large complex projects and find insights for your customers and the list can go on and on.
But the reality is that APIs are central to what every organization, every modern organization is doing today. But they come with a lot of challenges. You know, to, to reiterate what Alexei said, they represent a large and growing attack surface. And it really comes down to, there's a, there's a few elements here. You know, first of all they're just, they're everywhere. They're, as I said, a part of every major initiative application and their numbers are growing. In fact, the APIs themselves are often changing constantly through continuous integration delivery or even just periodic releases. And they're always operating within an ecosystem connected to other applications, connected to other APIs. And so what they are capable of is also evolving constantly. And then, you know, the third thing is just because of this explosion in their number in the complexity, it can be very hard to identify the APIs themselves, let alone the vulnerabilities that they present.
And so the reality is that's how you get this very large and growing attack surface that is not just growing but it's growing at a rate that is larger than or faster than what a traditional security organization using traditional tools would be able to handle. Even if you added more headcount, even if you focused on that more, the organization isn't scaling exponentially. But the challenge is, and so when you think about, you know, some of those traditional controls as, as Alexei mentioned, laughs and gateways, they're great, they're part of your bigger security picture, but they're not made for API security and they miss some of the more sophisticated business logic based attacks and exploits that make APIs such an attractive target for adversaries and attackers. And so, you know, by no means did you get rid of your waff or your gateway, but just know that they're part of a larger picture.
So to put some numbers behind what we've been seeing, we recently ran a couple surveys and I'll share just some, some highlights of those with you. API security really is affecting everyone in the survey that we just ran, 81% of CISOs so that they had experienced some kind of API security incident in the past 12 months. And as a sidebar you could probably argue those are just the ones that know that they had an incident, alright, they became aware that something happened. But because of the sensitive nature of APIs, you don't necessarily know if there has been an exploit, you know, if a, if an account number or a balance has been changed and one account might be a very important one, but you're not necessarily going to see that as a massive data xFi, although that is quite possible. But it's easy to see why that these problems are so prevalent because the ops teams really are in the dark three quarters said that, you know, they don't have a full inventory of their APIs.
Not just of a list of the APIs and you know, when they were developed and who developed them, but what they're capable of and not only just for that particular api, but again they're operating within an environment that allows them to access other services. So there's this sort of challenge where we don't really know what they're capable of in full detail and they're such a massive attack or target. In an earlier survey we ran this year, we focused specifically on security testing, the shift left motion. And there were a lot of really interesting findings, but one in particular I wanna bring up here is that over a third of respondents said that they had a project that was specifically delayed because of API security concerns. So they were going to go ship some product and they couldn't because they discovered some issue or they had to go recall a product they had to roll back because they found the vulnerability that made it to production. And when we ask people, okay, what is the the answer to these delays, there's a very clear alignment within the industry with 87% saying that, you know, really is that shift left motion that is the answer.
It's not a shift left or shield right or this or that or any kind of mutually exclusive choice. It really is doing both that you're having protections in place and that you're testing Azure developing product. And so that's why in our view, we think that a complete approach to API security requires a few things to begin with. You just need to understand what you've got. So there's, you know, we call it posture management, you might also call it discoverability or visibility observability. But the point is that you know what's going on in the environment, which APIs, which domains you've got today. And then of course you've gotta protect those, right? There are assets out there, APIs out there that are vulnerable. And if you know about those vulnerabilities then of course it makes sense to take care of them right away. But then there's that third piece which is the API security testing and doing that early and often.
And so I'm gonna talk now a little bit about what that looks like at a practical level and show you a bit of of our product that we've made for that. So let's talk about shifting left and what that motion looks like in practice. A bit about us before I get into our product. So we are pretty much the, the category leader in API security. We've got the largest r and d team working with, you know, a large and growing number of the Fortune 500 and particularly the top organizations in pretty much every major vertical. You know, the largest banks, the largest pharmaceutical companies, the largest healthcare providers, many of the largest retailers as well. Anybody that understands the role that APIs play in their business and to support that, we've rolled out one of the largest catalogs of integration so that we can work with your existing infrastructure with the systems that you've got already.
And we've designed the, the platform to follow those three pillars that I just talked about to provide that full life cycle security. So let's talk about the shift left piece of that, the API security testing piece of that. There's a couple major benefits to highlight. The most obvious one is OB is you know, you're going to stop vulnerabilities before production. We've been talking about the impact of having issues in in production. Obviously if you can catch those early, that's just, that alone is a huge win for reducing your risk. But that has a couple of second and third order effects that are really beneficial as well. So the most obvious one of course is that it can reduce your costs of remediation, right? If you get to identifying a vulnerability and eliminating it before you ever get to production, then instead of there being a breach and regulatory fines and cost associated with that, you know, depending on the industry that can be very costly and the amount of data that's like really you're only looking at a developer's time and while that is super valuable, it's much easier to fix an issue if it can be caught soon and therefore much faster and they are not, and their teams are not building on top of vulnerable software that then has to go back and be refactored or fixed and, and all those downstream effects.
And then of course the compliance angle. But that brings me to the next major benefit of shifting left is that it's not just about reducing risk, reducing costs, like keeping things under control. It really does allow you to move faster. Because if you think about, if you don't have to go back and do that kind of remediation refactoring, you know, all of those sorts of things, then you are able to move so much faster in response to the market. It is much easier just from a developer promotion to automate and move some of that testing into the pipeline earlier. So there's that faster iteration cycle. And the important thing too is that with automation, you can help your developers become more effective because they can build security into their products without having to become experts in security. And so that's what the automation really, really helped teams move quickly.
So let's show you what this looks like in practice. So the no name API security platform is a complete platform. If you were to log in, you would see, you know, just this regular screen here that shows the runtime and posture issues and in the upper right and we can go into active testing. Now an important thing about our platform is we can work wherever, however, in whatever deployment model our customers need. So you know, that might mean having multiple remote engines deployed in different regions to comply with data residency, but it also means in development that we can integrate into the C I C D pipeline. We'll talk about what some of those look like in a sec, but that we can be deployed essentially wherever your developers are and whatever environments they're using. So if we go into the active testing product, then you're gonna land and see a few things here and I'll walk through sort of what the, the sort of main event and then we'll talk about how that happens.
So you'll see here we're on the test suites page. So test suites are combinations of different tests that you're running simulated as different types of users on different types of APIs. And these can be done either fully automated, they can be run manually or they can be triggered by some activity. Like, you know, whenever your SAS or DA programs might run this could be slotted in right behind that. And what it'll look like is, and this by the way is just the UI we'll talk about. This is all available by via API and other systems as well. But if you were using our AI or our UI rather, you would see all these different tests and you can see that, you know, one, these run pretty fast. You know, a full test suite can take, you know, just about a a minute or two to run, but it will go through, you know, up to 150 plus different tests for your APIs that cover the O Os API top 10.
And particularly they go into testing business logic, right? Cuz that's the important thing. And the way that many APIs are exploited is it's through some business logic exploit. So that has to be built into testing as well. It's not just a matter of functional testing or fuzzing or you know, some of the other techniques that are out there that do have a lot of value, but you have to understand how the APIs are being used in their environment and then test to see if they're actually operating properly from a security context. So anyways, as I said, these can be run on lots of different intervals very frequently, and what it'll do is show the user all the different issues that it's identified, what the API was, what the severity was, what the issue is, and if we click into one of those, then you would get some information about that.
So not only, you know, the basic stuff like the api, maybe if there's any tags of what kinds of say data that it's transmitting or region, you know, these can be fully customized, but whatever, you know, variables are important to you. But there's going to be a description of the issue that comes up, some suggested remediation steps. And then if you do wanna provide some more context to the developers so that they wanna go, if they're, maybe they're not familiar with the issue that's come up or they just wanna investigate it further, then there's documentation for that. And in particular what they're gonna get is a timeline of all the, the activity related to that API as it ran during the test environment, the request, the response. So they can do that kind of investigation to see what the issue looks like. So great, how do we get here?
As I said, we're bringing together your APIs, test profiles, all this stuff. So I'm gonna walk through what that looks like. First you're gonna import your APIs and really that just means connecting to some sources, you know, repos, workspaces through a variety of different systems. But whatever it is that you wanna test, you know, you could just add an entire repo that a particular line of business is working on or a particular app and then those can get pulled in and you're gonna have a full inventory of those APIs. So you can see, see them groups by what they're capable of, if they are handling sensitive data, if they related to logins, you know, there's some automatic grouping that we apply, but you can also add some custom grouping as well. So let's say that might be a particular mobile app or a division or a region, you know, whatever your business logic in the general sense requires, you can group them according to that as well.
So it's gonna show you some information about all those APIs. And then the next key piece is the authentications, right? So once you get beyond a very simple API or a very simple app, then the reality is you're gonna have a lot of different kinds of users interacting with that api, with that application. And the authentication and the profiles are gonna matter quite a lot. So you can set up what those authentication profiles look like so that you can run a test and make sure that maybe an admin can access certain kinds of data, but you know, your average user is not able to and you know, get all those imported and configured. It's pretty easy to set that up and these can all be piped in from a source automatically as well. And then the final thing to put together are the test profiles.
So again, we provide, I think it's 160, it's up over 150 and growing number of tests that are specifically designed for API security. And those cover lots of different aspects of potential vulnerabilities, potential use cases. And so you can set up these profiles of tests that are essentially just groupings of tests of what you're gonna run. So those might be things that are, you know, specific to the web or maybe you wanna do an extensive scan and just cover everything. But you can go in there, you can customize which tests you're going to run as far as part of a particular test profile and then those factor into the test suites. An important thing too is that you have a lot of customization built into this. So if you see here on the right, you can adjust the severity of each of these tests. So depending on what your organization's risk profile is, you know, a bank might have a very different risk profile from a retailer in terms of what they're going to allow and the speed that they need to iterate at and what the consequences of a, of a potential breach are.
So not all vulnerabilities are the same across all businesses and we recognize that. So we've built this end so that you can adjust the severity of each of these. So you know, one thing might be, you know, a vulnerability might be an issue to look out for but is not necessarily a blocker, whereas in another industry it actually is a blocker and it needs to get remediated before anything gets pushed to production and it might even signal some other work that needs to get done. So again, depending on what the risk profile and the risk appetite is for your organization, you can set those.
This is all great, but of course it has to integrate with your existing environments, your existing processes, and we built it to do just that. These are some examples of some of the integrations that we offer in terms of C I C D pipelines. Even if you're doing more traditional sort of development rhythms of quarterly releases or semi-annual releases, right? You're still developing in regular sprints, you're still going through in fairly tight iterations and you wanna get that feedback very quickly. And so again, we compliment whatever existing tooling you've got, whether it's a pipeline management tool like some of these, the sast and DA solutions, we work with them and can get automated, it can be run in an automated way as part of those. Now of course there's set documentation for all these, so there's help for how to actually set these up. Excuse me.
And then the important thing too, okay, you can get this information in, you can run the tests, what do you then go do with it? So of course you can access all this through the ui, but you can also integrate with other systems. So Jira, some other ticketing system really, I mean the sky is kind of the limit, but the point is whatever your existing process is, you know, you've designed a process for, for your developers, you've designed a process to enable you to shift left, we're gonna integrate with that and we can do that through, you know, literal integrations but also supporting those workflows. So let's say that there's a particular type, let's say it's one of those high severity vulnerabilities that would be a blocker, right? That might be something that goes and triggers a ticket upon discovery of that so that maybe the team has to look at it and fix it or maybe it's just the developer.
You can, you know, adjust that level of severity, you can adjust what actions need to be taken. But the point is that that information can feed into the existing systems and processes that you've already got. And then the last thing I'll mention, of course being a an API security company and really being believers in APIs, we've made all this available through a management API as well. So you don't necessarily ever have to interact with the UI or maybe an engineering manager would go in there, you know, on a, a periodic basis. But your developers that are using this every day, you know, depending on how sophisticated your development organization is and what level of automation you want, you can pull everything from our api, put it into your systems, into your processes, and it's available however you need to consume it. And it's going to allow your organization to do that shift left motion, do that testing earlier, and stop any of those vulnerabilities from getting into production. So that's a quick overview of our product, how we think about API security. If you want more information, go ahead and visit name security.com. But I think we've got a few questions in the q and a, so I'll turn it back over to Alexei.
Thank very much Cameron. That was really kind, practical and clear presentation. I guess kind of what translates were well from my theoretical introduction, actual steps you need to follow to implement the shift left methodology. And yes, you're right, we still have quite a lot of time left for the q and a session and, but before we jump into the q and a, we actually have another short poll to run. So we have another question for our attendees to quickly reply and then we discussed our results before we actually jump into the q and a. So in just one pretty simple and practical question, whether you plan to implement anything from this fifth left approach in your company in the foreseeable timeframe, interesting. Looks like a horse race almost. The change in priorities in the mean probably could not see it are from here, but we will discuss the results just in a minute. Okay, the poll has closed and can I please have the results for the questions for our attendees to see as well?
Hmm.
I have to confess, I don't see anything myself.
Oh really? I can see the, the, the results on the little window here. So again, to the first question, does your organization have a clearly established API security strategy? Pretty interesting split. So 36% said yes, but of course then 64% said no. So almost two thirds of organizations then do not have a strategy for securing the largest attack surface and, and biggest attack factor.
Well that's, some people probably say it's a shame. I am definitely not from that camp. If you say, if I may say so, because the very fact that people are attending webinar last like hours today and that at least have a very strong understanding that they need API security strategy, even if it has not yet been properly formalized, at least they're working toward that direction, which is already great.
And I think it's a testament to just how quickly the market is, is changing and evolving and how the role of APIs has changed.
Right. What about the second one? So if I remember the, the running numbers before it was closed, there was like our people who actually are already have a clear cut and short term shifting left strategy, right?
Yeah, yeah. So, so I guess if you can't see it, so again, the question was do you plan implementing a shift left approach to API security? It is a bit of a horse race, so 30% said yes, we're actively pursuing that approach right now. And then 20% said yes, we plan on taking steps within the next year to year and a half. So about 50% are taking some motion either right now or very soon 30% said no and then they do not have, or are not currently taking steps to shift left and then only 20% said no, but we plan on doing pre-production security testing. So I think probably confirm some of the earlier surveys that, that we did that, you know, even for organizations where they're not currently doing it, that's definitely the direction that everyone is moving in,
Right? Right. Well again, at least the majority of the, of, at least our attendees already understand that this is pretty important, even if it's probably not their top priority, it's still on the, on their schedule, which is great, which is the right way to do and also do not plan it at all. Well maybe you reconsider your priorities after this webinar. Okay, great. Well thanks a lot to our attendees for the responses. Again, they kind of confirm our point, so let's jump directly to the q and a session so you can submit your questions at any time through that questions panel and I will read them aloud and we'll discuss. And in the meantime, I will just kind of show you some additional information about our upcoming events and research, just not to keep you too bored, I guess. Okay. So we actually have the first question from the audience. Let me click find the right window. The first question is, do developers actually need to directly use your platform UI or do you offer any integrations into their favorite development tools? Hmm, you mentioned API earlier, but like, do you already have any practical tools built on top of the api?
We, we do. Yeah. So it's a pretty, as I said, it's a pretty important piece of our development philosophy is that everything should work with your existing processes and your existing tool. So that's why we've got, you know, it's, it's of over 75, probably close to a hundred different integrations to lots of different systems both on the production sort of runtime protection side of things. And then also certainly on the testing side. So C I C D pipeline sort of tooling, other ticketing and workflow systems like Jira, et cetera, those are all available that can be connected to our system through integrations. And then there's that management api. So no, theoretically a, a developer doesn't ever need to really log into the ui. Maybe an admin, you know, sets it up, but we can surface that information in however it needs to be consumed by the organization in whichever system that is.
Right. Okay, great. Next question, which I believe had arrived at the moment when you were showing this user identity thing in the ui. The question is, can you actually link the API execution to AED user identity in working that call?
So the, in terms of the user identity, the way that we handle it is through whatever their, you know, we call it an authorization profile, but it's basically the, the type of access that that user should have. So, you know, not necessarily that, you know, John Doe or Jane Smith were running it as them, but as the, the profile that they, that they should have access to. So a bit of the nuance there, but yeah, the idea is that we are allowing, we're allowing you to simulate the effect of a user of, you know, a particular level in a certain area to use those APIs, try to consume them, and then what would happen relative to your desired security controls and if those are, are proper or improper. So I guess maybe the, the terms we use are a little bit different, but the effects is the same.
Okay, awesome. Okay, before I jump to the next question, I would like to kind of draw the attention of our attendees too. The research which I have brought on the slide I currently see, We actually have recently reviewed the noname APIs security platform, not too deeply technical in what we call an executive view format, but just a few pages for anyone to break through and understand what the cotton actually does. And of course if you need to know more, you can dig deeper into our related research, which again, just a few examples listed on the slide and we have many, many more on our website. So you are welcome to browse and you actually will get free trial access to our research library if you register your account now. Okay, next question. Who is actually responsible for choosing the right tests for different APIs? I believe that refers to that part of your platform where you have those test suites. So should you develop those, create those suites or the security people, or can you create those test suites for your customers?
So really it's all the above and it's gonna depend on the organization. And the reason I say that is, you know, when we see customers being really successful in implementing a a comprehensive API security strategy, it means that the developers are not operating in isolation and security's not operating in isolation, but the two of them are working together. So oftentimes the particular test suites that they're putting together, and therefore the test profiles and the individual tests that they're running are usually driven by whatever the business' needs are as decided on, you know, from a a risk profile and risk appetite view overall and then what those two teams, what their priorities are gonna be. Now, of course it could also be that there's a product manager or a product owner that is, you know, particularly keen on making sure that they're developing secure products. It could be a line of business where it's, you know, maybe you're creating a mobile app and it's dealing with sensitive account data.
And so there is a, a higher bar that applications developed in that area and that line of business have to meet. And so it could be the engineering manager, it could be the product manager. It really does depend on the, the particular use case. But yes, the, I mean it's, that's where I say it's going to reflect whatever the risk appetite of the organization is and the structure of that organization. So the particular individuals involved be it just engineering, be it security, hopefully some combination of the two. They're gonna be the ones that are setting the test that are included in those test suites.
Right. And I guess one point to first hear that your platform does not discriminate against anyone, anyone who wants to participate can, this is the whole idea.
Yeah, yeah, exactly. And, and you know, that's I think an extension of the reality that, you know, we've talked a lot about how APIs, they're critical piece of any process, they're enabling so many different use cases. And so really they're critical to the entire organization. So the entire organization in some form or another has a stake, right? Even your legal and compliance teams have a stake in making sure that the products that are being put out are gonna, you know, not put the, the business in, in jeopardy or at excess risk. And so that's why the tools that we make, as you say, like they're, they don't, don't discriminate. They are, they provide value to areas across the business.
Right. Okay, next question, which actually kind of follows up nicely the discussion you just hit. If anyone can participate, who is playing for this? Where does the budget come from?
Ah, yeah, so actually I would say very, very similar answer in that they, you know, I hate to say it depends it for a security testing tool, obviously they're usually coming from the developer side of the org. But in an ideal situation where the organization is very tightly aligned where security leaders and development leaders are working together, oftentimes some of that budget will be shared. So you might still have, you know, not necessarily like a 50 50 split, but you know, if you think about some of the key parts of API security that I showed, like posture management, runtime piece, those might be managed by the security teams. And then the development piece is contributing the budget to the security testing product. And then there's some shared services too that, that span across those. So it does depend on the organization. Obviously the testing piece skews towards the developer side, but you know, to reflect the ideal state of processes, there's a bit of bit of overlap.
Okay. And there is one or other question which we kind of already answered before, but if I may kind of expand a little bit on that. So the question itself says what's more important shifting left or should, right? If I may kind of elaborate first on that myself. Yeah, tell said that both are important, right? But one thing we have to specifically stress that it's much better if you have the same tool to do both or at least an integrated suite of tools and not just two different platforms where one is focusing on shifting left and the other one is focusing on the operational security. And my understanding is that basically your platform is one of those few vendors in the market to actually offer this integrated solution. Can you maybe elaborate a little bit on what your platform can beyond just API security testing?
Sure, yeah. Yeah, I mean the, I I think there definitely is a move towards convergence and consolidation from a product standpoint. You know, so our product again goes beyond the security testing side of things to protect your APIs in run time and hopefully, you know, even going beyond identifying a, an anomaly and attack in real time, but to find the vulnerabilities before that even happens. So in a way, even the posture management side of what we do sort of supports that shift left motion. It's not necessarily testing when talking about testing and development, but if you can find the vulnerabilities before they're exploited, that's obviously a, a major win. So yeah, we've designed the system to very tightly integrate some of our customers even, you know, look at doing our, using our testing product on APIs in production, you know, almost like a, a pen test.
You know, there's certain things you need to be careful with that and you need to set up some things just to make sure you don't get, you know, false alarms or things like that. But, but yeah, our, our belief is that it should be one coherent solution, you know, supported by one coherent set of processes and, you know, a methodology for how to run a really excellent API security program because of course the technology is only ever one piece of the puzzle. There's also the processes and the people involved and all three of those, the people process and technology need to be able to work together really well. And so that's how we've built our, our solution is to support that.
Well, I could not think of any better words to actually say that. It seems that there are no further questions from our audience at the moment, so it only remains for me to say thank you very much to all of our attendees for being with us. Thank you Cameron, for providing us deep kind of, and again, clear to the point insight into how to actually translate my Analyst both about importance of API security into practical steps actually achieving that. Have a nice day and hopefully I'll see you all at some later point at a different webinar or physical event with call. Thanks and goodbye.
Awesome, thanks Alexei. Thanks all.
