The Elephant in AppSec Podcast⎥Lack of effective DAST tools⎥Aleksandr Krasnov (Meta, Thinkific, Dropbox)

Welcome to the Elephant in AppSec, the podcast to explore, challenge, and boldly face the AppSec Elephants in the room.

The idea for this podcast came about during a casual coffee chat among our team (you don't want to know how many coffees our team consumes each day...)
We realized that in the world of Application Security, there are often unspoken challenges and issues that need attention – the "elephants in the room." We wanted to create a space where we could dive into these topics, ask the tough questions, and bring in experts who aren't afraid to challenge the status quo.

Today, we're revealing our first episode with Aleksandr Krasnov, the principal security engineer at Meta, who challenges the effectiveness of existing DAST tools with us.

In the upcoming weeks, we'll share even more interviews with world-class security experts that address concrete appsec issues, allowing you to reflect on your approach to security practices. Can you guess who our next guests will be?

Stay tuned, and dive into our first discussion straight away!

Our guest : Aleksandr Krasnov

Aleksandr Krasnov is the principal security engineer at Meta, responsible for all things security at Instagram and WhatsApp. Previously, he was responsible for AppSec and offensive security at Thinkific and served as a product security engineer at Dropbox, Palo Alto Networks, and other companies. Aleksandr is an expert in helping companies increase their efficiency and become more security aware by implementing DevSecOps practices. 

Throughout his career, Alek used multiple security tools, including Dynamic Application Security Testing (DAST) tools. As we began discussing this podcast with him, he immediately raised a topic we strongly agree with: the scarcity of effective DAST tools in the market.

In our conversation, Alek shares:

• Why organizations shouldn't only focus on shift left
• The value of defending left, but attacking right, and why DAST is a part of this strategy
• Why he thinks Nuclei stands out in open-source dynamic testing tools
• The criteria he considers when evaluating DAST tools and what would elevate a tool to the status of a dominant player
• His recommendations to AppSec engineers on how they should deal with the current limitations of the DAST
• How to drive efficient collaboration between engineers and the security team when it comes to dynamic testing
• Whether DAST is adapted to smaller or larger orgs and what's impact when security sits within engineering or finance
• What to do when SAST or SCA are not enough, why he considers Semgrep among the next generation of vendors, and why custom rules must become an essential part of DAST
• What the future of DAST tools look like

Referenced:

• Nuclei: GitHub Repo
• Scanning Live Web Applications with Nuclei
• Burp Dastardly
• Snyk
• Semgrep
• CodeQL
• DeepCode AI
• OWASP ZAP
  
• Backstage: GitHub repo, Spotify Engineering article

Find the full transcript below:

Introduction

Alexandra
Welcome to the Elephant in AppSec, the podcast to explore, challenge, and boldly face the AppSec Elephants in the Room. So it's one of our first episodes and we'll be diving into the topics that are often avoided in application security. Welcome! I'm Alexandra, your host, and here with my co-host Tristan, a former security engineer and the founder of Escape. And today we're joined by an amazing guest, Aleksandr Krasnov, ex-product security engineer at Dropbox, Thinkific, and currently principal security engineer at Meta. Aleksandr is really an expert in helping companies increase their efficiency and become more security aware by implementing DevSecOps practices. Throughout his career, Alek used multiple security tools, including dynamic application security tools.

He immediately brought up a topic that we really share a strong opinion together and the scarcity of effective DAST tools in the market. And that's going to be our focus today. Hi, Alek, thanks for joining us. Can you introduce a little bit of yourself and your experience to our listeners?

Alek's background

Aleksandr
Yeah, for sure. Happy to be here. Thank you. Alek, currently the principal security engineer at Meta, responsible for all things security. Right now, currently responsible for Instagram and WhatsApp. Before that was Thinkific, was doing all things security at Thinkific, but primarily responsible for the AppSec and offensive security. Before that was Dropbox, before that was Palo Alto Networks, before that was a bunch of other companies.

Alexandra
Thanks a lot!

Why organizations shouldn't only focus on shift left

Tristan
Excellent. Well, Alek, I got a question for you, actually. When we started discussing this podcast, we discussed together the different topics that we could cover together. And you actually came up with the topic of DAST tools, which is a pretty controversial topic in AppSec. So why did you decide to pick this topic first?

Aleksandr
Yeah, it's very interesting to see the trend that is growing right now, which is shift left. And a lot of times people tend to overly focus on the left side of the SDLC and not enough on the right-hand side of the SDLC. And you can see it in the vendors. So the DAST tools usually tend to be very inefficient and they tend to not produce anything that is useful neither for the organization nor for security engineers. So, and a lot of times folks just tend to say, let's put SAST in place, let's put all the security guardrails on the left-hand side and not worry about the right-hand side.

Tristan
Yes. And do you think like you said, very interestingly, organizations are everything about shift left, right? Everything about DevSecOps, about security for engineering. So you think we went too far in this direction?

Aleksandr
I would say so. I think the nature is healing, so to speak. So we have a lot of folks that are pushing back and saying, OK, shifting left is good, but it's not good enough. So the approach that I like to take is you do defend left, but attack right. So in other words, put a lot of guardrails in place for the left-hand side of SDLC and be as defensive as possible. And on the right-hand side, you do as offensive as possible. So try to break it first instead of the bad guys.

Tristan
And DAST is a part of this strategy of protecting left, then attacking right. Is that right?

Aleksandr
Exactly, yes.

Open Source vs Commercial DAST

Tristan
And about specifically the DAST tools, well, because there are many, many DAST tools. A lot of them are pretty generic. For instance, let's speak about open-source as a start. Have you found something very outstanding in terms of dynamic testing among the open-source tools?

Aleksandr
Yep. I would say one that is really good is Nuclei. And that's the one that's standing out. And yeah, and like the main reason for it, and it's actually, I feel like that's the future for security vendors is that when you can write security as a code, so to speak, when you can write customizations for the scans and customize it as much as you want to, as much as you need to, and Nuclei provides you just that.

Tristan
I love this one.

Aleksandr
You write a bunch of YAML files, you create it just as much as you need it to be for your web application. And that makes all the difference. And as far as other open source tools, everything else is so different and the same as Nuclei. So I think Nuclei is the one that stands out.

Tristan
Yeah, I totally agree with that. So I've used the Nuclei when I was a security engineer, and I really loved it. Like the YAML file configuration, super easy, super straightforward. It scales like crazy. It's written in Go or Rust or something, so it scales like crazy. It's really a very great tool for dynamic testing. And when it comes to the commercial vendors, have you seen things that really stand out? When it comes to innovation in the field of DAST?

Aleksandr
Right now, as far as the tools that I've tried overall, I mean, other than Escape, I guess. All the other tools are still lacking, I think, in a lot of areas. There are quite a few tools that are lacking in a lot of areas. I do see that, you know, Port Swigger, for instance, they used to have the Burp Suite Enterprise, and now they have released the Dasdartly, which is, I think it's a good attempt forward to try to kind of dictate the new standards for what that has to be. But I don't think they are there yet.

Tristan
So there is room for innovation and improvement in the field. That's an exciting place to be in, right?

Aleksandr
Absolutely. There is an uncharted territory at the moment. I feel like, there's a fight for who's going to be the dominant player in the DAST space. And you know, when, when you come to be a dominant player, then that's where you can start dictating the rules and best practices. And that's when you lead the industry.

Common criteria when evaluating DAST tools

Alexandra
Makes sense. And what are the common criteria that you look at those tools and you think are missing that would actually make someone a dominant player in the field?

Aleksandr
Yes, I think the main one and the most important one is how the tool exactly works.
Like, is it actually going to be able to go through the complex authentication flow of the common and modern web apps? Is it able to perform all the things you need for the web app as an external entity in a correct fashion? Is that architecture scalable? Can it be integrated well into your SDLC?

We don't need to worry too much about how easy or hard it could be integrated as long as there's some sort of API provided to you. But at the same time, if it's just a jar file that you have to spin up your own infrastructure and create additional maintenance, KTLO so to speak, or like work about work, then it becomes a problem. But if you have a very robust architecture that can scale up or scale down as needed, it can act as an external entity just as much as like the real human being, then it's great. And I think like the other thing is how easy or difficult it is to customize the scans based on your web app needs. Because every single web app is gonna be different and you have a different context.

So you want to be able to customize it to your web app needs. And that's going to be the responsibility of security engineer to figure out how much code they need to write on top of the tool itself to make it friendly to the web app that they're trying to protect.

How to address the current limitations of DAST

Alexandra
Okay, makes total sense. And like for now, I mean, these are the ideal world, you know, but we have to deal also with now. So now would you give any recommendations to AppSec engineers on how they should deal with the current limitations of the DAST?

Aleksandr
Yeah, absolutely. I think as a security engineer, it's your responsibility to understand the web app needs and kind of treat security not as an external metric, but more of a code hygiene, app hygiene. And if you treat it as part of the engineering quality, then that's where you can say: this is where we can prioritize, this is where we shouldn't prioritize as much. And once you get the overarching context in the engineering team, you can say, well, maybe we shouldn't worry too much about the DAST because we, you know, maybe we have a good tool that is good enough at the current moment to give us enough metrics and give us enough actionable results.

And let's not spend too much time on this because we were lacking a bunch of, you know, controls around like precomit hooks or something like that.

It's the responsibility of the security engineer to identify and prioritize what's needed. But it takes a security engineer to be somewhat of a software developer, so to speak, to get the idea of what's needed, be able to do the risk assessment, and being able to do and call out the specific actions. So it's not really about how to make DAST more efficient. It's more about how to make the engineering team to succeed.

Managing collaboration between engineers and security teams

Tristan
And how do you efficiently, I'm getting a bit away from the topic, but I believe this is super interesting. Especially in the case of DAST, because contrary to SAST tools or SCA tools, which are very easily actionable for engineers, even if they hate the fact that it generates thousands of alerts, it's easily actionable for engineers. DAST is a bit further away from them. How do you manage this collaboration efficiently between engineers and the security team when it comes to dynamic testing? Because dynamic testing happens late in the development process.

Aleksandr
For sure, yeah. I think there are two main things to understand once you need to talk to the engineer about it. One is it's not your responsibility just to create an alert and tell engineers to fix it. It's your responsibility to provide contextualized information and drive the engineering towards better code hygiene and better engineering practices. Let's like, that's goal number one. And the DAST findings are just one way to help this.

So number two is trying to figure out how you make the DAST tool work for you and for the developers in a way that it's succinct. Nobody needs to know the generic explanation of like, here's your XSS, the top of XSS, and here's like five paragraphs to read about it. Engineers want to see, you know, you have cross-site scripting for this parameter.

One sentence, maybe two sentences, right? And then when it comes down to that, ideally you want to figure out - okay, I'll look at this finding, I'll look at this parameter, either I know the context of the web app well enough to say that I can dig into the code and find the issue into the line of code and suggest the fix and create there, you know, an alert to a developer or just notify the developer where exactly it needs to be fixed.

Or it's good enough of a description of the alert or finding that the developer knows exactly where to go to fix it because ultimately they're always going to have much bigger context than me when it comes down to the code itself, right? Because they're going to be working on it 24-7 versus me working in it, you know, far less because that's not the primary responsibility.

Alexandra
Sure.

Aleksandr
So, yeah, just one, again, make sure that this is not a part of the security metric and you kind of have to offload your responsibility to developers, but rather you have to figure out how that fits into their workflow because security becomes less right now. It's becoming less and less of security analytical work, more of security engineering, which is good. That's why I kind of said before, like nature's healing.

And two is trying to identify how you can make actionable descriptions to developers that are not just generic enough because you know, you have a bunch of different vendors that will tell you, you know, here's all the issues with it and they'll give you like paragraphs over paragraphs and paragraphs of generic description of like, here's your SQL injection. Here's how it maps to OWASP Top 10 and like developers will just skip it. They'll be like, I don't care about it. What do I need to fix? You know, so just make it more understandable, make it more actionable to developers, and make it short because nobody got time.

Tristan
This is super interesting what you're seeing, because this is exactly something we had to take into account when doing Escape as a product. Because there is a part for remediation. We auto-generate code snippets for developers to help them remediate the findings. At some point, we decided to even hide the OWASP Top 10 classification and all the security wording from the remediation to let the developers focus on what is interesting for them, which is fixing the bug, and letting the security do the analytics and the matching with the frameworks. Because otherwise, if you overload them with information, the developers, they will be actually less efficient at fixing the bugs. This is what we discovered.

Aleksandr
Exactly, yeah. 100% agree.

Checkbox compliance: The implications of integrating the security team into the engineering or finance

Tristan
Another thing as well is the scale. Do you think, considering the fact that dynamic scanning happens in pre-production environments, and you don't need necessarily to have access to the repository, to the source code to run it, do you think it's perhaps more adapted to large organizations? And less adapted to small organizations? Or is there a specific type of organization that should focus on dust and less on static analysis?

Aleksandr
Good point, good question. I think it really depends on the maturity of the engineering work because I've seen smaller startups under 100 employees that have DAST in a very mature way, have SAST in a very mature way and I've seen thousand plus employees that don't have it together.

I think it all really depends on the engineering cork. And if they see security as a separate metric, like one thing to probably notice when you look into engineering work structure is to ask a question where the security fit: if it fits and reports under engineering, or if it reports under finance.

So in one way, security could be considered a part of the engineering process. Therefore, all security projects will be part of improving the engineering quality.

Now, if it's part of the finance, it's operational costs, right? So it's more of a friction and usually it's a way to... It's a great area where you can navigate what you can do, what you cannot do, but usually that's where you have friction with engineering and that's why you usually just want to abide by whatever attestations you have in place. If you want to go through SOC type 1, type 2, then you're going to showcase that you have some sort of SAST, some sort of DAST. And you don't really worry about if it's a good one or bad one necessarily. So you just have some sort of scanner that you can just turn on and turn off with a click of a button.

Tristan
Yeah, it's like "checkbox" compliance.

Aleksandr
Exactly. Yes, exactly. Yeah. But if you have a very strong engineering culture where security is taken into consideration not as a fraction but more of a speed up towards more of engineering confidence, then people will start asking, like developers will start asking questions of, should we put SAST in place here? Should we put some linting rules here? Should we figure out is our DAST good enough?

So it really depends on how engineering is structured and how the leaders in the organization look at security and that, you know, it depends. It doesn't really matter if it's a large size. I think it matters what the maturity of the leaders.

Alexandra
In most organizations, did you see the differences between like a bottom-up approach and a top-down approach? And like, what are the actual differences you've seen?

Aleksandr
Yeah, the majority of the time it's, you know, you have leaders overall driving the milestones, so to speak. So like, here's the big milestone strategy of like, you know, let's say we need to characterize the traffic. And then they decide to let the ICs, usually like senior ICs decide to say: OK, you know, if we need to characterize the traffic, what kind of apex we need to work on or what kind of projects we need to work on? What does it actually mean?

And then from senior ICs, like other ICs, take a look at what does it mean for each subcategory. So the example of character is the traffic. You can say, well, we need to understand all of our ingress rules, egress rules. And then the ICs would work onto all the ingress rules on our net boxes or all of our egress rules in the cloud. And then they start drilling it down to specifics. So in a way, it's top to bottom, where leadership usually communicates to you big areas of what needs to be done in one coherent sentence and nothing else. And then that's when you have the flexibility of deciding what you want to be done exactly under this strategy. And you're the one who is coming up with metrics to quantify and qualify the progress.
What does it mean to have success in this matter?

SAST and SCA are in place, but it's not enough

Tristan
And so if we are considering an organization, let's say they have the basics. They did SCA. They did SAST. They have Snyk, for instance, or something else. And they want to continue improving their security because they believe this is not enough for their status. They're, for instance, handling sensitive data or something. What advice would you give to only one security engineer in this company, or the two security engineers that must handle all of their APIs, all of their applications, and let's say 100 developers or 200 developers?

Aleksandr
Okay, so the situation is you have one or two people and SAST and SCA are in place, but it's not enough. Yeah. I would do two things. One is to talk to the leadership and ask what's exactly not enough. Because not enough may mean from the leadership perspective we just don't have enough tools for kind of checkbox compliance, you know? And that thing is easy to solve. It's not the right thing to solve, but it's easy to solve.

Or the other thing could be, you know, if it's not checkbox compliance, but it's just, we don't, we don't know what we don't know, then focus really hard on the inventory, so to speak. Like the traditional stance on vulnerability management is usually, do you see all of your assets? Do you know the number of all of your assets that you have? And based on that, do you see the number of your vulnerabilities? So focus on, can you actually see everything that you have? And then can you actually scan everything that you have? And then once you get to the point of like, okay, you know, we have everything, we scan everything. Now we have the problem of, you know, we have 10,000 plus criticals, 100 plus, 100,000 plus highs and bajillion, you know, medium and lows.

That's where you start to think about maybe we need to prioritize some areas and not so much others. And that's where the security engineers have to step in place: how does our business work? And this is what I think is crucial for security engineers to kind of step away a little bit from engineering and look into the business. Because that's gonna help you to do more thorough and more contextualized to risk assessment and say, like, you know, if it's a financial institution and a business like that, then you kind of focus very hard on, I would say, like the left-hand side and looking into do you have all the data in place? Do you have all the data security strategies in place? Do you have PII detection in place? You know, if it's a traditional SaaS company, you kind of have to look more holistically and say, you know, you see everything on the left-hand side, you see everything on the right-hand side. Do you, over time, do you tend to see the same kind of things, and they not, they just keep popping up without any sort of resolution? You know, and if that's the case, maybe you need to talk to developers and figure out maybe developers just not following the best practices. Maybe there's not enough of advocacy around security, secure coding practices.

Maybe, and just maybe it could be that the SAST and SCA are not very efficient and they produce a bunch of false positives. That's a very common case, right?

Tristan
Yeah. That's what I heard.

Aleksandr
Right, and you know, with SAST and SCA, it's very easy to just, just plug something in and be merry because it's like, oh, you know, we have the metrics, right? We have all the tools, but I think this is where I'm going to bring up Semgrep. Cause like I said, like I said, the next generation of vendors where you can write your own policies in place. This is where the Semgrep comes in place for SAST and SCA where you can write your own, you know, Semgrep policies. You can write your own Semgrep rules and you can really just turn it on at the organizational level for all the repos, for instance.
For all of your code places where you're using it for the development and being like, well, this is not useful. There are so many false positives, like why did I even sign up for this? But you gotta like to go through the pain of contextualizing everything, making sure that your rules in place are good, maybe creating some more rules. And over time, you're gonna mature the usage of Semgrep to the point where it's gonna be like, oh my gosh, you know, we have false positives, but it's not a ginormous amount. It's, you know, I can count maybe 10, 20 false positives, but all of our findings are high confidence. And we can actually come back to developers and say, this is not a false positive. We actually need to prioritize it, right?

So for the security engineer, it's really important to figure out, if it's the problem with the tool, if it's the problem with over-emphasis on one of the areas of SDLC, if it's lack of context of what the business does, or if it's a problem with the leadership. Now, the later one is a harder one to solve because... And we're not going to go into the details because that's a lot of like, how do you navigate the leadership desire for the checkbox compliance or, you know, something else when you as a security engineer disagree with their leadership moves. But, you know, there were four common problems and there are different solutions for it.

Tristan
Do you think there is a huge difference when, for instance, the CISO is a technical person or has been in application security before versus compliance security in terms of how it organizes the strategy, like the application security strategy of a company?

Aleksandr
Oh, like the difference between security and compliance, like how would they approach it? Yeah.

Tristan
Yeah, like for instance, if you're in a company where imagine the CISO comes from a compliance background versus a company where the CISO comes from an application security background, is there a completely different approach or at the end it all ends up the same way of managing the AppSec process?

Aleksandr
I would say totally different. It's an interesting question, very interesting question. So it ends up totally different. And it doesn't mean that one is better and one is worse. It just means that you kind of really need to know both sides of the story to kind of come up with a more holistic approach, right? If you do fully like security engineering background, the full engineering background, you're just gonna start fixing stuff all the time. And you may waste lots of time fixing stuff that is not important. Right. And if you come from compliance, then you're going to start fixing stuff, not really fixing stuff, but like looking into the stuff that needs to be fixed and driving right. And you end up not really fixing anything, but from compliance perspective, you're better off. So you have this false sense of security, which is probably one of the most dangerous parts.

Tristan
Checkboxes

Aleksandr
Where you don't want to be. But take into consideration, you know, I think you need to figure out what the compliance folks are telling you what needs to be prioritized. And taking that as, I guess, the lens that you look into your security engineering and let those lenses paint you the picture of what you actually need to be doing. And that's where you can achieve the most results. You can actually make compliance useful. Because you're going to contextualize it from the engineering perspective. And you're not going to waste too much time doing something that you feel like it's important, but it's not.

The significance of customization and actionable insights in shaping the future of DAST

Tristan
And coming back to the topic of this podcast today, when it comes to DAST, so you mentioned the interesting thing about two of the tools that you mentioned, which are Nuclei and Semgrep, is the importance of custom rules in these tools, like the ability for security engineers to create custom tests and custom rules, to personalize and customize the tool for the need of their company and their company's business. Nuclei is a specific tool because it has been designed to scan everything, not only APIs or applications, but basically third-party apps, front-end apps, back-end apps, everything. And it has not really been designed to test the business logic of applications, like the business processes with sequence of requests. Do you think there is a room in dynamic application security testing for something more able to test the real business processes of applications? With, for instance, something custom like Semgrep and Nuclei would do, but specifically for business logic?

Aleksandr
Yeah, absolutely. I mean, there's definitely room for this. There's definitely a niche that needs to be filled. It's, you know, like as simple, but also as complicated as it sounds. Like if you can feed the API of your web app, and then based on this, create the rules of what you want to be tested for. You know, like, let's say in a declarative style where you say your API, here's your method that you want to achieve this. And you declare the custom rule to scan this. And then if you see something that is off, you know, that's how you get the business logic errors, right? Like if you can create the rules like this in a DAST tool, then that's going to be, I would say in a way revolutionary because you don't really have a lot of those DAST tools that would attempt to understand your API and then based on that API, create specific custom actions on it, right? So, there is definitely room for that.

Tristan
Yeah, super interesting. So this is not just about the research at Escape. So I can't disclose any information now, but we will have news. OK, and so to take a step further, if we take a look at the future of DAST, apart from this specific thing that I mentioned, what does the future of DAST tools look like? Like, what will be?

Aleksandr
Yeah, I think that one of the most important features would be engineering first DAST tools. So, meaning that all the results from the DAST tool will somehow be digestible and easily digestible by developers, and developers will easily be notified of the findings, as well as the DAST findings will be able to tell security engineers on what they need to focus on, you know, within the next quarter, within the next couple of quarters a year or two.

It definitely needs to be something that is smart, so to speak, like the next generation test where, like we talked, like we just talked about, like being able to create something custom, create custom rules so that you can scan it based on that. And essentially, if you can customize the rules and scans in such a way where you can achieve continuously improving the efficiency of a tool, that's gonna be great.

Obviously, that could be achieved with some sort of AI integration in place where you can just feed into the API and based on some sort of algorithms, you can definitely create the rule sets, I believe, that we'd be able to crawl through and create the in a way declarative scans. And I think like the other thing is, DAST almost needs to be in the future, a good context, subject matter expert of the context of the web app. You really need to understand what the web app is doing as a security engineer, but if you have the DAST that can be a subject matter expert of the web app from the, I guess, black box perspective, so to speak, because it's always gonna be the black box if you wanna do a truly DAST then I think that would be the future:
- Digestible communication with developers
- Subject matter expert of the context of the web app
- And just being able to crawl through and continuously learn about the web app through the APIs that you're being fed to.

Tristan
That is super interesting and I totally agree with you. I think those are really priorities and especially the current tools are very bad at those capabilities. And I think it's an interesting complementary capabilities to what the static tools can produce. Like a lot of alerts, but very early in the development, very engineering focused, but less aware perhaps of the business logic of applications, less aware of the execution context of the apps. Because sometimes, availability comes from some app components not talking well to each other, which must be found at the execution level. So I entirely agree with that. I think those are definitely the capabilities that should come in the future of DAST.

Aleksandr
Yeah, for sure. Yeah. And I'm curious to see how that would all play out because, you know, I feel like, I feel like in the SaaS space, Semgrep was kind of trying to aggressively dominate it, not from the business perspective, so to speak, but from the novelty perspective. So I'm curious from the dev perspective, how do you target and tackle the novelty of it?

Tristan
Yeah, from the community as well, with the community rules and all the sharing of knowledge among the engineers that are discussing over custom Semgrep roles. Yeah, I think the advantage is that there is way less innovation in DAST currently than there was in static tools. For instance, Semgrep has CodeQL as a competitor, which is GitHub, which is ultimately Microsoft. It's not a tiny competitor, right? I've personally tested CodeQL. I think it's a bit super complicated to use compared to Semgrep. I love the easiness and the zen attitude of Semgrep compared to CodeQL personally. And there were other startups that got acquired, like DeepCode from Snyk. I've worked myself like four years ago in a startup called Sourced that was studying the analysis of source code with machine learning techniques. So there is a lot of innovation in startups trying to improve the understanding of source code and the static analysis of source code. On the dynamic side, on the other hand, I felt, and this is one of the reasons why I started Escape, that there was not so much innovation.

Most of the tooling was based on OWASP Zap, which is a great tool, open-source, and very nice. But it has been created in the early 2000s for testing PHP applications. And there was not even like, not really like new kind of approaches that were designed for dynamic testing. So this is, yeah, this is obviously one of the reasons and the things that you mentioned that made me work on a new kind of dynamic.

Aleksandr
Yeah, nice, nice.I totally was interested in the GraphQL at first, right, the GraphQL testing, because that one has been very much silent. Like there are a lot of open source tools that do some sort of basic GraphQL testing, but not so much of trying to understand your graphs and stuff more, so.

Tristan
Yeah, GraphQL, the very hard thing with testing GraphQL dynamically is, since it's a graph, if you want to test it, you have to test it recursively, very deep in all the graph schema. And this is obviously something all the classic DAST tools are very bad at, because they have been designed for linear sequence of requests or even single requests, single SQL injection in a single request. So they are super bad at understanding how an API can actually be a tree or a graph, which is like a super specific kind of data structure. And so this was one of the reasons we started with GraphQL. And the other one was the fact that with using GraphQL, we would start working with modern companies. And this is the kind of company that we wanted to build like someone like a company that would work with modern companies. And also that obviously nobody was doing it. Like nobody was doing it yet. And companies were adopting GraphQL like crazy. So yeah, the focus was initially in GraphQL, but as you know, we have opened more kind of APIs. Uh, we have REST support now. Uh, we have support for gRPC and we have like even SOAP support incoming if people are still using it somewhere, like the big banking companies and so on are still using this kind of APIs.

Aleksandr
Ah, nice, nice. That's awesome. gRPC is the interesting one for me, because that's, I've just worked with it for the first time at Dropbox and that was very interesting to me how it works. And after that I realized like, oh, from a security standpoint, It's very cool and it's very bad because there are so many areas where things can go wrong and it's very cool in the way how it works. So it's very interesting to see how Escape is tackling gRPC because I don't see too many companies using gRPC and those that are using it, usually the ones that either adopting and moving it from like some other way of handling the requests or bigger companies that need to build something in-house. Right? Like if you wanna build the tools in-house, but then as a business, you come into the challenge of: Okay, if the company is building lots of things in-house, why would they want to buy a vendor where they can try to also build something in-house on top of it? You know, that's kind of like a constant challenge of, I think, bigger companies. Like build versus buy, right?

Tristan
Yeah, obviously. I've heard, and I was surprised about that, because when companies reach a certain size, they actually start having their own internally developed handmade security tools, which is crazy if you think about it, considering the amount of work that it is to build a security tool. So it always starts the same way, right? Scripts made by security engineers. And then it ends up being an internal framework. And then they want to connect the framework to the reporting system, aggregate the data with other security tools. And it ends up being like a full security platform that is developed internally to companies.

Aleksandr
Yeah, exactly. And then you have re-work, and then you have some software engineers jumping into that, and then you have a dedicated team supporting that tool.

Tristan
Yeah, this is crazy. Have you heard of Backstage?

Aleksandr
Sounds familiar, but remind me.

Tristan
So Backstage is an interesting story. It's actually, it's like the inventory and application security posture management software of Spotify that they started developing internally. Believe it or not, but it started growing so huge inside of the company that they decided others could use it and they open-sourced it. And now it's becoming so big that they're thinking about making it a second, like revenue stream for Spotify. So imagine that Spotify is actually becoming a security company like without telling anyone. They're doing music and cyber security.

Aleksandr
Oh wow. Right on. Those two combine well, right?

Tristan
Yeah, this is crazy if you think about it.

Alexandra
Okay, I think we're almost at the end of our episode, guys. So thanks a lot for joining us today. Aleck, it was very insightful. Very, I think we all learned a lot. Thanks for taking the time and thank you all for listening to us today. So if you have any specific thoughts on the topic of this podcast or in dust, feel free to drop it in the comments and we're always listening to the new elephants in the room, so feel free to bring that up to us.