API Security Testing In DevOps with Oli Moradov

Welcome to the Test Guild Security Podcast where we all get together to learn more about security testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Security Podcast. Today we'll be talking with Oliver all about API security testing and DevOps, and I think it's a really hot topic lately, especially as more and more folks go towards microservices. So you don't want to miss this episode. Check it out.

It's no secret that the number and complexity of applications are growing, but what is alarming is that 90% of security incidents result from exploits against defects in software. The need for better application security has never been higher and Micro Focus Fortify is here to help. Fortify is the recognized market leader in application security and it is the most comprehensive and scalable application security solution that works with your current development tools and processes. With Fortify, you can start security applications in a single day, including custom code, open source or commercial components and scale as your needs grow with an on premise as a service or hybrid implementation. Check them out. Head on over to micro focus.com app security.

Hey Ali, welcome to the Guild.

Thank you for having me Joe. Good to be here.

Great. I guess before we get into the topic itself, could you just tell us a little bit more about yourself?

Yeah, sure. I'm VP, Biz Dev and Strategic Alliances here at Neuralgion, so assisting both our end clients and indeed our DevOps consulting partners on their journey at delivering AppSec testing automation across their pipelines. So I suppose a little bit about neuraligion itself. We're really a company that provides a developer focused fuzzer and DAST olution enabling runtime AppSec compliance on every build. So I suppose similar to the way that SNYK may have revolutionized SCA or perhaps sonarqube has transformed dast, we really try to simplify that process and making it work for developers, empowering them to and organizations to actually incorporate automated accurate DAST and fuzzing technology into every pull request so they can resolve security concerns as part of their development process.

Perfect. So Ali, my audience I think is mainly beginners. I could be wrong. So I just want to make sure everyone understands what some of this means. So can you just explain what is a DAS and what is a fuzzer before we dive into that a little bit more?

Yeah, absolutely. So DAST is dynamic application security testing. So it's almost like an automated black box test where you can run comprehensive security tests against your applications to look for security issues or security bugs so that obviously they're not being pushed out into production to ensure your cybersecurity posture. And obviously the earlier that you can do this in the process, the better. Ideally, organizations should really be striving to incorporate a DAST solution into their development pipelines to be secure by design and actually to be able to fix and remediate these issues as early as possible in order to be secure, as I mentioned.

Perfect. So I know there's a push towards getting things shift left and more and more developers get involved in testing their software, but it seems to be mostly done on like the web front end type of activities. And APIs have been around for a long time now and for some reason I still see that a lot of, maybe I'm wrong, a lot of companies, a lot of developers still aren't really focusing in on API or API testing. Do you know why that might be?

Well, I think that when you look at the DAST market and you know, it's a very well established technology, but APIs are, you know, relatively new in comparison to web apps and the way that these applications are being now architected is shifting and there's a very, very heavy reliance on APIs. And I think that where there is a massive gap is that typically these automated tools just didn't really have the ability to test APIs or perhaps looking at single page applications that rely obviously very heavily on, on API calls and it's that sort of left the market with a heavy reliance on manual testing. And I think that perhaps is the main issue and one that really, really needs to be addressed, particularly when you're looking at DevOps and when you're looking at DevSecOps where you need that automation and you need to remove the manual human bottlenecks that are so synonymous with not only application security testing, but specifically in relation to API security testing too.

Absolutely. And I guess you mentioned two reasons why it seems to be more prevalent now than before APIs, microservices and single page applications. Is that what you see also as a vendor? I love talking to vendors because you speak to a bunch of different clients and customers, more and more companies building applications that really have a foundation of microservices single page applications. And maybe that's why we're seeing more and more interest, I guess, in API testing.

Yeah, absolutely. I mean we're seeing, there has been a massive shift, but now we're really seeing digital transformation, business transformation, really, really leading the way. I mean when you look at, you know, financial services, banking, with all the sort of the startups that are being over the top banking. When you look at the Open Banking Directive, for example.

There are many ways that organizations can now interact with each other and APIs is obviously driving that as well. Microservices, Absolutely. With organizations re architecting their legacy applications, migrating them into the cloud as part of that digital transformation project, you're seeing more and more heavy reliance on on APIs. It's a much more effective way of being able to support that agile development when you have multiple different microservices that you can work on individually and scale your development processes with that methodology.

Perfect. I think this, maybe it's just what I see is, I think there's a misperception almost about API security in that when you see a web app you can see it and there's a user interface and you know, well, a hacker probably can attack it this way, but for some reason I think maybe we get a false sense of security when we create headless type technology because we think oh, no one's going to be able to see this API or know how to interact. Is that a common misconception? Is like how common is API security breaches?

Well, API security breaches are common and we've seen some very, very well established renowned organizations have what have been some pretty severe breaches or where they've been lucky, some API breaches that perhaps have been detected with bug bounties, et cetera. The rise of the API really has been on. The writing's been on the wall for a very, very long time. Gartner, you know, very, very recently, did you know there's multiple surveys but they say that actually it's, you know, 90% of web enabled applications will have more of an attack surface area in the form of exposed APIs rather than user interfaces. And that's only going to grow exponentially as more and more organizations are pushing forward with their digital transformation and will rely very, very heavily on microservices based architectures and subsequently obviously their heavy reliance on APIs, whether that's still using the old Soap API. Of course the vast majority of organizations will be pushing towards rest APIs, but we're also seeing a very marked increase in the number of organizations that are going to be relying on GraphQL. And I think that's a very, very interesting API methodology that I think we'll see grow exponentially over the next few years. And we've certainly seen an increase in demand for GraphQL testing over recent months.

So this might be a dumb question. Is there one method that's less secure than others like say Soap or Rest or Graph SQL GraphQL they equally can be attacked or is one more prone to attacks a security hacks?

Well, I think looking at security in that way is actually the wrong way of looking at it. Everything has the ability to be hacked unless you're putting the right efforts in in the right places. Ultimately, every organization needs to take security testing very, very seriously. And in order to do that, in order to keep up with the agile development methods. With DevOps, it's all really about automation. And we're seeing so, so many times when I'm speaking to clients, whether that's younger startups or indeed enterprise organizations with hundreds if not thousands of developers, there's a heavy reliance on manual testing. And when you look at the number of iterations the organizations, the number of concurrent builds that organizations have, it's very, very hard to maintain a good security posture, regardless if one is going to be more secure than the other, because the technical debt that accumulates without the ability to automate that process is unsurmountable. And that's where you have your issues. Everyone talks about whether it's right or wrong. The gulf in terms of the job space in the cybersecurity industry, there are a million cybersecurity jobs. I think the last count that I checked in the US alone, I believe in order to keep up, automation really, really is key in order to achieve that. And I think it's not which one is perhaps more secure. I'm not sure there's going to be much in it. I think the focus really is how can we ensure that whether we're still relying on soap, where lots of organizations don't, or are very much moving away from that rest, or indeed GraphQL how can we ensure that regardless of which ones of those we're using, we can be secure by design? We can detect these security vulnerabilities as early as possible as part of our DevOps methodology to shift that security left. And some organizations, it really depends on their maturity level, whether they're immature organizations talk about, okay, let's start right in order to shift left. I think organizations have an issue where perhaps they're striving for perfection at the cost of actually making any progress. And I think that's where organizations need to say, okay, how can we start? Culture, the people and the processes are very, very important. But then comes, okay, what tooling can assist us to drive that forward? Or what tooling can enable us to achieve some form of progress whilst we then mature then gives us the ability to scale as we mature those processes as well.

Absolutely. I know once again with web development there's a high reliance now on open source components that basically developers are just taking all these open source components, stringing them together and coming out with a solution. I don't know if that's the same with API and if so, I know there's a rise with security breaches for open source packages, but are there any known API type libraries that people may be using that could be have exploits in them? So they may be focusing on their own code as being secure, but now looking at third party components they may be using that actually are causing security issues?

Yeah, absolutely. And you know, I think that will always be the case whether it's APIs or indeed web apps. You know, speaking with organizations. Absolutely. A good, you know, SCA is going to be very important, particularly as you mentioned, that it's very easy to bundle up a few of those and get a functioning application and you need to ensure that those vulnerabilities are patched, as it were. But you will always need the, you know, a full pen test, let's say. I think anyone that says you're going to fully automate that process is going to be wrong. You always need to do a sort of final check. And you know, we have many clients that will say, you know, what we've implemented, you know, a sneak for example, and actually now we want to then over the top of that add a very, very comprehensive dastard. And where is it in the process that you're going to be doing that? So whether I'm talking to the security architect that wants to deliver automation so that they're not relying on either in house VA or very expensive outsourced third party va, that's going to be done periodically, they want to be able to automate that process either for their own teams, either putting a tool in the hands of their QA or to deliver security assurance when they're delivering their QA or the functional testing ultimately with a view to being able to put a security tool into the hands of those that are not security experts, such as your developers to as I mentioned previously in the opening paragraph, to be able to run a security test on every build, every commit or every pull request that they're making.

Great. And you know, you mentioned before the, there still seems to be a high reliance on manual testing and I'm not sure why that would be with API testing since it seems they'd be a lot more automatable because you're not dealing with the UI front end. But a lot of pushback I get with folks is, well, our customers are using our UI, so we test through the UI, then we have all the APIs covered because the APIs are being called from the front end. So there's extra overhead. So are there any pushback to testing APIs is an education issue or why do you think people are still relying on manual testing for these type of activities? Testing activities?

Well, I think the main problem that organizations face is actually with the inability of their automated tools at truly being able to capture or detect the attack surface. So it's really a coverage issue. Typically relying on crawling, you know, that's just, it's just not going to cut it. I'm afraid to put it quite bluntly. You know, APIs are a different beast to just having a web application. And I think that's where the sort of focus I suppose would need to be the majority of processing. And perhaps the logic is at the client sending the API requests, getting raw data back and then the processing is carried out on the client side. And it's this that's led to sort of fundamental changes to the security threat model. It's now the client that has a lot of the access to the data, the raw data, and the backend is relying on the client side. And if the hackers can, then if they're able to intercept that data and to exploit and use the API directly, you know, that's where they can really get change a lot of that data. And that's obviously been made worse by the decomposition of applications into microservices. And that's what's led in this attack surface growing exponentially. So, you know, when testing an API, for example, the crawl is not going to work actually. You need different discovery methods. So whether that's utilizing or leveraging a half file, a recorded interaction with the target application, if you wanted to integrate it into your development pipelines, does your tooling enable you to upload a swagger or an open API specification? Organizations use Postman, for example. Can the tooling leverage and consume your Postman collections? And typically what you find is the answer to that is no. So you have to have that reliance on manual testing. And I like to differentiate manual testing and the testing carried out by your developers as part of their pipeline because the security personnel can also perhaps either with some tooling, with different proxies, test an API in a semi automated way. But the notion of DevOps is really trying to shift that security testing left to put These capabilities into the hands of your developers, your engineering team, or your qa. If you're not at that stage, to be able to run a comprehensive security test on each of those, build on a specific entry point with a set range of parameters to test for security vulnerabilities. And I think that needs to be the focus for organizations as opposed to constantly shifting out, shifting it right and saying it's not our responsibility. And my mother always said Carpenter never blames his tools, but I think in the DevOps world, once you've got the culture and once you've got the processes in place, the tooling does play a fundamental role and ultimately a lot of blame in inverted commas, if I can say that can be placed on the tooling. They're slow, they're perhaps complicated to use. One major issue with, perhaps not so much with API testing, but certainly with web application security testing, is the inaccuracy of the results you get, the false positives. That actually leads to even more bottlenecks downstream. You know, how can you effectively deal with this? And you need a DAS tool that perhaps gives you that single pane of glass where you can test your web applications, your single page applications, your APIs, with one specific tool that's going to give you the detection and more importantly, the coverage that you need.

Absolutely. And I think you have a webinar on this and you had like four main areas you think I think a tool should help you with, and one of them was the single pane of glass type of activity. But you also had three other ones like coverage, analysis, payload, and detection and speed. Now, it sounds like almost a lot of these DAS tools probably have been in the market for a long time. So what you're saying is APIs are kind of newer. And even if you look at OWASP, I think there's a different OWASP top 10 for APIs compared to web. So maybe they don't have some of these newer areas to be focusing on. So for a newer tool, what makes your tool different in these areas compared to maybe another solution that someone may be using? And is your solution complementary to what they already have invested in?

Yeah, that's a good question. So, yes, OWASP have the OWASP top 10 for APIs. And a lot of the list is very similar to your standard OWASP top 10, perhaps in a different order. But I think that what you need to ensure DevOps, I mentioned before that you need the culture and the processes. It's about collaboration between security teams, breaking down Those silos creating champions in each of them to spearhead that change to sell, but also manage security testing automation with your developers, to be a sort of go between that speaks to different languages across the pipeline. But then I think it's being able to empower these different teams in order so that you can actually scale your testing, but also to ensure that you're doing it at speed. DevOps is all about automation and speed. And the last thing you want to do is add delays into that processes. So with shifting left, it means ultimately that putting security testing into the hands of your developers, they need to be your first line of defense, as it were. So to enable them to detect, to prioritize and treat the security defects like they do with their functional defects, to fix them early, that's going to be the cheapest time possible. It's going to mean that you're not then going to be accumulating that technical debt that I mentioned already. But in order to do that, you need a tool that a developer can actually use, not a tool that's built for security professionals that is going to be probably disabled by the developers and join shelfware. The amount of times I speak to clients where, you know, they have licenses with other tech that's just not being utilized, they're complicated to use and they're complicated to configure. So a tool that can test both web apps and APIs, that single pane of glass that you mentioned of course is going to get additional buy in from the teams. But I think that you hit the nail on the head in terms of how attacks and payloads. So developers aren't expected to understand. Okay, well I'm testing my web app now and then I'm going to be testing my API by leveraging my schema. Which tests should I be utilizing here? And that's where our technology really differentiates itself. So we have very, very smart engine. You know, we have reinforcement learning, machine learning. Some of some organizations and people love to hear that, others don't. But actually what it enables us to do is to automate the process of maximizing or optimizing scan speeds to complement DevOps as much as you can. So our technology has the ability of a smart scanning functionality where we can look at the target and understand which attacks and which payloads are going to be more relevant, which parameters are going to be static parameters that perhaps if we didn't understand what they were, we would then carry out these tests against parameters that perhaps wouldn't have an effect on the target application. So we have the ability of removing the noise, as it were, and carrying out very specific targeted tests against parts of the target that are going to be relevant. And all that's really about maximizing all, optimizing the scan speed without relying on the developers to know what they're doing. So it's really trying to simplify AppSec testing so that you can put the trust into the developers integrated across their pipeline so they have that security feedback loop to raise a ticket in GitHub or Jira, but also ensuring that the CISO or the Security team have full visibility of where are the vulnerabilities being made with which team on which project then can actually aid in understanding where do we need to apply some security awareness training? Which teams are making which common mistake? Actually, it's nipping it in the bud. It's enabling your developers to realize, okay, I've made a mistake, I'm being caught up on it or brought up on it now as I'm doing it not three months down the line, particularly when it comes down to API testing, which is very much periodic, quarterly, biannually or indeed annually. And it's the accuracy of the tools that I think is also plays a very, very big part in that. So if we're looking at DevOps or we're looking at CICD, that's completely counterintuitive, or it's the antithesis of being able to achieve that methodology when you're getting inaccurate results that need a manual validation of the vulnerabilities. So one key fundamental differentiator of Neuralgion's technology is the ability to, in a fully automated way, validate every vulnerability that we're able to exploit. Which means that there's no need for the triaging of false positives. There's not a heavy drain on the security team to manually validate those. So every vulnerability that's detected, developers can, knowing full well that it's been exploited with a proof of concept that it's a true positive to fix it immediately. And I think those three or four key features are what organizations need to put together a robust security program, but one that's actually going to keep up with or maintain the speed of DevOps and not cause that drag.

I 100% agree. I come from a functional testing background. So the same issues you're talking about here are the same issues with functional testing or when people check in code, developers checking code, they have unit tests, a lot of false positives, they start turning flags off so that it doesn't run, or if it doesn't meet a certain threshold, it gets kicked back. So they start doing weird things to work around that. And also it takes up a lot of time and so they get mad when you add more and more of these scanners. So I guess the biggest thing I want to dive into here is the machine learning AI piece that seems to be a buzzword in functional testing. So can you just explain a little bit more? Like it finds a defect, a developer checks in code, it finds an exploit in one of their APIs, and you're saying it's a true issue because you have some technology that's able to determine it's a real issue, not a false positive. Then what happens? Does the developer have enough information to know from the tool that okay, not only do I know it's a real issue, but now I know how to fix it? Or do they still need to work with the security team to say, hey, what do I do here? I have no idea what this is doing here, what this means.

Yeah, and you raise a very, very good point there. So everyone talks about web app scanners and I think that really gives you the best understanding of the difference between other DAST tools and our dast. We don't scan, we communicate with, we interact with the target application. So we go through a process of browser automation. So we are communicating with the target application as if a human would. And that enables us to go through an automatic validation process. And a nice example of that would be with a reflective xss, for example, where we will almost render the page and look for that reflection showcase with an automated screenshot, the reflection as a proof of concept. And of course every vulnerability that's detected is provided with all the response, the request with a diff like view. So developers can really understand where the issue is. All the response in the body is all provided. We can give you details of remediation advice, links to additional resources, whether that's with our own knowledge base on how to remediate so that developers can understand where you've gone wrong, so that they can read up about it. They can then go away and try and remediate and fix. And then the technology also provides the developer with the ability to execute that same attack, execute that same payload, post remediation to see if it's been remediated successfully without the need to then suddenly go and recall a new scan. So absolutely, the key focus really is enabling developers to be able to, you know, mark their own homework, but also when they get back a vulnerability that it's been verified and it's been validated as a true positive. Here's the proof of concept and this is what you need to do to remediate. And by the way, probably if you're doing it now, not three months later, when perhaps that developer has moved on to a new project, working on a different microservices or working at a different company, they're learning on the go and I think that's where organizations need to go. It's really about ensuring that your developers are not going to be routinely making the same mistakes again and again and again. And the best way of educating them is, is by putting them up on their mistakes as early as possible. But from a business perspective, you know, I think I always mention, you know, for the number crunches out there, it's going to be the cheapest, most efficient time for you to remediate those fixes. Whilst from a security perspective, it's going to ensure that you are intrinsically secure by design so that less is being pushed out into production that's going to be vulnerable and you're going to have some automation orchestration for your CI CD pipelines. One thing you can't categorically have is builds failing for no reason because that's when you suddenly need to start monetizing your risk. Okay, well, we've done a test. We know where our problems are. We've got 250 vulnerabilities here. We know that probably 80% of them are going to be false positives. What do we do? The needs of the business say that we need to release. The security guards are saying, come on, don't do that. You've got an agile entrepreneurial engineering team that's probably headed up by a CEO for a new tech startup that says, come on guys, we need to deliver these new features to our clients. But then security is always going to be that friction in between. So we've removed the false positives, we've made it very, very easy for developers to use. We've removed the complicated configuration of not only the scans, but also configuring the scans so that the results are going to be relevant to minimize. Most tools talk about minimizing false positives. We remove them, remove the noise, remove the alert, fatigue or exhaustion so that, yeah, you can put security testing into the hands of your engineering team.

Great. And you know, I don't know if this is a cultural thing or if you see this as well with functional testing. A lot of times developers like, oh, we have a suite of automation tests we run. So I don't really need to test my code. So if you have a solution like you're explaining here, how much testing does a developer still need to do? Or can someone have overconfidence in the tooling to think, oh, we're covered, we have a scanner, uses AI machine learning, so we're good to go. Don't really need to focus in on security as much because it'll be caught by the tooling.

Well, no, I think, look, no developer wants to put security bugs or even functional bugs into their products, and ultimately they're still going to be picked up on it, whether it's now or whether it's later. Speaking with teams, speaking with our clients, you want it done as soon as possible, you want to be brought up on these issues as early as possible, and ultimately you don't want to then make that same mistake again. No one wants to go back and redo work they've already done. So I think it depends on the team. There's always going to be, perhaps some people, a cultural thing, like you say, but I think in one office you might have many different cultures where there may be a heavy reliance on saying, well, I'm not going to worry about that. I'm going to, you know, I'll just let the scanner pick it up and then I'll fix it. But, you know, ultimately, you know, if you're the one that's going to be coming back at the end of the day or the end of the month or, you know, the week with multiple different fixes, then it's not going to look good on you and you're the one that's going to be the bottleneck. So, you know, I don't think that's really an issue. I think people want to be, want to ensure that they're doing the right thing. And in an ideal situation, organizations, regardless whether that's the development, the engineering team, right up through to the ciso, to the CEO, just want to ensure that they're being as efficient as possible, as dynamic and agile as they possibly can, without adding more work. So, no, I think most organizations and most teams in my experience anyway, don't mind the notion of being pulled up on issues or fixes. But by the same token, you know, there are subjects to the, to the size of teams. Yes, I won't be naming any names, but, you know, there are organizations that say, you know, sometimes what you don't know, you don't know, and suddenly you know, and what are you going to do about it is perhaps what you're alluding To Joe, tell me if I'm wrong, but I think now organizations are realizing that I don't really think you can take that stance anymore. There's so much at stake. You know, recently I think it was a psychology department in Finland that got breached and there's a hacker, you know, exploiting people that had psychological assessments, you know, from their, from their early teens right up through to adulthood that are now being, that are now being, you know, exploited for money. Otherwise they'll release their records. That's just one recent example of the last few days. So security is really, really so important. There's so much data now that attackers can exploit and leverage that people are waking up and taking security testing seriously and they're realizing that APIs now really is the key to that data. And you need to make sure that they are intrinsically secure, not relying on manual testing that's going to be periodic unless you've got very, very deep pockets that you're able to run those manual tests on a daily basis. But Whether organizations have 50, 100, 1000 different APIs, it's really a scalability issue.

So you mentioned about communication a lot. Culture you are using AI, machine learning. What other insights can be bubbled up? I mean, over time? Is it smart enough to say our team B that checks and code always has SQL injection issues? So maybe we need to invest in some more education here, I guess. What other insights are being bubbled up to the teams security wise with your tool over time?

Yeah, well, I think that's going to be the main one. You know, there's a very big focus now on code, coding, education, security awareness, and I think trying to understand not only your internal teams, but a lot of organizations also outsource development to third parties. And I think you also need to be in a position to be able to validate what they're doing, you know, assigning them as a specific project or a group like you can with, with our technology to say, okay, well are you delivering us secure software? Are you delivering us secure APIs? And if you're not, you go back and make the fix and do it now before you deliver it to us. That's for external players. But of course, regardless of whether you're a technology company or whether you're a supermarket or Walmart, you want to ensure that anything that you're doing is going to be efficient and that your team have the requisite training to ensure that they're delivering maximum effect. So the CISO dashboard that we call it on our technology enables you to have that full visibility. So not only is it, okay, where's our risk immediately? I want a snapshot now of our top 20 assets. I want to be able to run a DAST tool now. Let's come back to the results. I want to know where I am now. So we've removed the false positive, which means that actually you know where your risks are. Because we don't need to wait seven or 10 days for the reports to be manually filtered or triaged.

And that way you can then understand.

Where your risk is. And then if you can then go a little bit granular, you can say, okay, well we've got this risk here. And actually we've noticed that, yeah, the SQL injection issue seems to be quite prominent in Team E and Team E are working on this asset. This is our holy grail. This is the one that as a trading platform, this is the one where all of our clients are transacting. Let's give them specific training, specifically in dealing with SQL Injection. What are they doing wrong? Let's try and nip it in the bud.

And we're seeing a lot of that.

And that really is a main focus for organizations. They want to ensure that their teams are working not only effectively, maintaining that agile DevOps methodology and the speed that comes with it, but also to ensure that they can always improve. And I think us neuralgion, as an organization, we're very, very in everything we.

Do, we look back and we learn.

From it, from positives, how can we be even better? But also we always take any negatives so that we can improve to ensure that we're delivering better technology and a better service to our clients. And I think any serious business would want to do the same.

Oh yeah. I mean, what I really love about that it also is you could test everything and everything all the time, but it almost sounds like this helps you focus. Not, not on everything, but you could, but mostly on risk. And so people in my experience have really bad at risk assessment. So it almost sounds like not only are you testing more, but you also can focus in on the areas of risk within your business. Like this module is critical to all our customers. So we here's the risks that have been bubbled up to us as an issue. So we, this is where we want to focus a lot of our testing efforts going forward probably.

Yeah, absolutely. And I think, you know, I can give, you know, sort of two examples. So if you're looking at a younger, let's just say a startup and you know, they want to integrate security testing as part of their pipeline. Great start. Now you know, try and shift security testing left and actually what you find is that, you know, you haven't got that accumulating debt of remediating fixes and you can be, you know, sort of generate that more secure by design approach when you're looking at a large enterprise client. So let's say one of the big multinational banks where the amount of technical debt that they have has been accumulating perhaps for years and they know where their risk is, but they just haven't got the resource to be able to remediate it. Their development and engineering teams are going like the clappers and it's spiraling out of, out of control. So you need to be able to take a snapshot of okay, where are we, where are we now? And it's the issue of one, the detection of the, of the coverage. If you're going to have coverage issues, you need to then always go back and rely on the manual testing. So you know, APIs is always going to have that issue because you don't have the automated tools that are going to provide you with the automation to test and the coverage. But you also then have the issue of okay, well great, we've done all these tests, but we've got a massive pile of vulnerabilities here that we need to fix. So okay, now let's start segmenting them. Let's look at either a CBSS scoring or let's look at the issue type or the severity and let's now go and fragment that into let's take our thousand assets and now let's look at our top 50 for the moment. And suddenly you find yourself having to forget about a vast majority of your assets to focus on the ones that are most paramount to your organization. So where enterprise organizations are trying to go and trying to move to is with automation and ultimately try and remove the backlog that they have. But from a CISO's perspective, to be able to take a snapshot in time to say where are we at? Where's my risk? I need to feed back to the board to say this is, these are the issues, these are the resources that I need. We've now don't need to rely heavily on our security team. And I don't know if you know, there's a really interesting statistic, the number of developers to security. The ratio is 50 to 1 respectively. So you know, it's always going to be an uphill struggle when you've got that ratio. If you imagine the number of iterations the number of builds, they're really, really working towards business transformation and generating new products and new features. Security just can't keep up. And that's why automation is really, really so important. And you have to have that automation in order to understand where your risk is. You know, GRC is so important to organizations, but it's very, very difficult to understand where you are unless you've got that accuracy and you know, the scalability to be able to test ideally as early as possible. And when our co founders started with Neuralgion, that was really one of the main focus. Coming from a CTO and a CISO perspective. They understand the needs of one, ensuring that AppSec can keep up with the pace of development. But then from a CISO's perspective, with his other hat understanding that I need to know where I'm at, I need to know where my risks are. And at the moment I'm just looking at so much noise and it's very, very difficult for me to prioritize the remediation to try and prioritize the risks that I want to try and remediate now and then start clearing up the backlog.

Salvar, I know I mentioned earlier that you actually have a really great webinar I'll have it in the show notes kind of around this topic as well. And I think you did a few polls around people's maturity around API testing. Just curious to know if you could share some of those results with us.

Yeah, sure. So yeah, in the webinar, rest assured, DevSecOps for APIs, I ran a poll that asked the attendees how they would describe their API security testing processes and I actually also put that on LinkedIn, put that on Twitter as well. And the results were surprising on the one hand, but really, really not surprising on the other. So an overwhelming 80% or thereabouts, I think it was. 79% of respondents carried out their API security testing manually, 50% of which I think was internal and the other was done by a third party. It's not surprising given that historically the available tooling is very ineffective at best at automating the process purely from a detection coverage perspective, for example, but with almost 50% outsourcing their manual testing to a third party, that's a very expensive problem that compounds these issues, I think even further. Speaking with one client recently, more of their or one of their main problems was actually how long it took to simply book the testing in with their supplier, let alone having to wait for the test and the reports of their annual scan. So not Only is it manual, but it's so periodic. And how many iterations were there prior to that? You know, some organizations are lucky to have internal testing teams, but as I've alluded to before, you know, with the ratio of security to developers, you know, 50 to 1, it's just not scalable, especially with the sheer number of iterations that we've mentioned, that compounds the issues. And you know, very few companies I think have the requisite maturity or indeed the experience in their security teams to develop their own, you know, convoluted automation with custom scripts, for example, you know, and that's, that's going completely against the notion of DevOps. So I think there were some in the region of 8%, 8, 9% of those that.

I'm being probably quite cynical about this.

But those that claim to have it fully automated. But I think in my experience those conversations I've had where they said, yes, you've got our API security testing automated, it's very much later in the process and you know, you don't get that immediate feedback loop to developers that you really, really need to achieve that shift left methodology that comes hand in hand with DevOps.

Wow, awesome, awesome results. Okay, Ali, before we go, is there one piece of actual advice you can give to someone to help them with their API DevOps security testing efforts and what's the best way to find or contact you or learn more about your solution?

I think, look, first and foremost I think you need to have buy in, you need to have that culture, you need to have someone from, you know, security sat with your developers or someone from your development team that is going to be pro security. And then I think when once you have that, then the rest should really follow. But you know, I mentioned before that in order to really achieve that, in order to, to maintain that agile entrepreneurial spirit that a lot of organizations and engineering teams have, you need to have automation of your security testing and keeping this relevant to APIs. You need a tool that has the ability to test whether you know multiple different API methodologies or architectures. Sorry, so if you're using REST or SOAP or maybe more, or if you want to perhaps shift to using GraphQL in the future, make sure that your tooling has the ability to do that. You need to find a tool that provides you with multiple different discovery methods of the attack surface. So whether that's generating HAR files in an automated way right from the developer's dashboard with a CLI tool that consume or leverage, whether it's open API, so SWAGGER files, for example, are you using your postman collections? Are you using other QA automation tools like Selenium or Cypress IO? Why carry out more work? Why don't you leverage the work that you're doing already and make your security testing tool work with you to get your compliance test with The OWASP API top 10, for example, if your appetite's more if you're more hungry for more sophisticated testing Fuzz Testing your APIs is something that organizations are really really looking at at the moment, and we've seen a big increase in that. But really importantly, it's about seamlessly integrating it across your pipelines via either a REST API I mentioned with the CLI tool, how can it integrate into other common CI CD tools whether it's Circleci or Jenkins Jira Fuel Ticketing to ensure that you get that automation enabling you to bake it across your security pipelines? And this is really what New Religion's technology has been built from the ground up to try and achieve. We're a security testing tool that has been built with a dev first approach. We enable organizations to put security testing into the hands of the developers, into the hands of your qa governed by and managed by your security team and your ciso to get full visibility of where your vulnerabilities are, to deliver accurate, actionable results to developers, to remediate as early as possible to be secure by design and for any additional information, please feel free to reach out to me. Joe, I'm sure you'll put my contact details at the bottom. We have a very very extensive blog and resource page. Please read up about us and obviously if you have any questions, we're here to help.

Thank you Ali for your security testing awesomeness. For links to have Dinner value we covered in this episode, head on over to testskill.com S39 and while you're there, make sure to click on the Try It Today link under the Exclusive Sponsor section to learn all about Micro Focus Fortify, which is the recognized market leader in application security. So that's it this episode of the Test Guild Security Podcast. I'm Joe. My mission is to help you succeed creating end to end full stack security testing awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Security Podcast. Head on over to testguild.com for full show notes, amazing blog articles and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.