Developer-First DAST: Fix Security Issues Before They Reach Production

Developers today are shipping more code than ever, but also more vulnerabilities than ever. What if security could fix itself without slowing you down? Hey, I'm Joe and in this episode we're digging deep into how AI is completely changing application security with Gotti Bashwitz, the CEO of Bright Security. If you ever felt that security testing slows development down or floods teams with false positives, you'll learn what actually is working now and how teams are fixing vulnerabilities automatically and what developer focused security really looks like in the age of AI. Stick around because this conversation will change how you think about security testing and modern DevOps. You don't want to miss it. Check it out. Hey, welcome to the Guild.

Hey Joe, thanks for having me.

Great to have you. Really excited about this conversation. You know, a lot of times when people think about security, I think still today when I talk to developers, DAAS has been around for about a decade, but they still tend to avoid it. I know in the age of AI, I think things are going to change that. What are your thoughts on DaaS and maybe where we're going in the age of AI?

Yeah, I completely agree with you. I think it's actually been around for a couple of decades now and people, not just developers, everybody tends to avoid it, unfortunately. So we've seen, if I look historically right, we've been around for eight years now. If I look historically, I'd say 20 to 30% of organizations that we talk to, mainly large financial institutions, insurance, etc. Have a real need and have a real interest and are able to implement it. Everybody else struggles because there are real challenges with deploying a dynamic solution. One is figuring out the authentication, two is figuring out access to the application. So it's more complex to deploy than a static solution is to deploy. But if done right, it can be way more effective for your business because it doesn't have the noise of the false positives, et cetera, et cetera. Now to your specific question of where do I see this going in the age of AI? For the last seven years our focus was on what we call dev centric dast. So we looked at dynamic and we broke it down to each of the components. What does it mean to run discovery? What does it mean to run scans? What does it mean to authenticate? What does it mean to get access to your APIs and to your web applications, etc. And how can we change that from a solution for AppSec people to a solution for developers? And what do we need to do technology wise, in order to provide an engineering solution for an AppSec problem. And that's the journey we've been on. And that journey with AI is significantly accelerated because suddenly instead of doing the discovery in a pre production environment, we're running that same discovery directly on your code base. Instead of doing scanning that happens late in the development lifecycle and takes a long time, we're running incremental scans. We have customers that are running 55, 60,000 scans a month, which is completely unheard of because we are able to map and target and break out their applications into much smaller chunks because of an integration into their code base. Due to AI, we can automatically create authentication objects, so that big complex issue of authentication with dynamic is no longer an issue. We automatically generate the authentication directly from the code base. We can automatically find shadow APIs and automatically create schemas for APIs that fill in default parameters and things like that. So all this stuff that you couldn't do in the past suddenly is enabled because of AI, because of mcps, because of tools that we have. And that is a big change in this industry and it enables 100% of organizations to deploy these solutions.

All right, so this sounds awesome, but I know developers have been burned in the past a lot of times, a lot of false positives. Like you said, it's slow. So maybe talk a little bit more about your approach. A little bit different. Like I think you mentioned a few times, right? You're more developer focused, das, and especially if you're vibe coding, you just submit, you know, upload, you know, build, go to, you know, whatever your environment, it's even quicker, it's even faster now, like you said. So how. And you kind of alluded to it, but maybe explain a little bit more. I'm a developer, I'm in my ide. What am I doing that I'm getting the security, yet it's not going to impede my speed as well. I know that has to be a balance.

Yeah, let's start with. I'll absolutely get to that, but let's start with the current state. You used to have a developer that generated 100% of code and say 100% of vulnerabilities. Where are we today? These same developers are creating 150 to 200% of code, but 500 to 600% of vulnerabilities. Because no matter what you're using, if you're using cursor or anthropic or cloud code or copilot or lovable or base 44 or OpenAI and a million Others that I could name, you are generating a lot more vulnerabilities because none of those models were trained on secure code. They were all trained on open source and that means that they don't know how to write secure code. Actually, my co founder Barr just released a blog post where he showed step by step how he's telling I don't want to shame so selling one of these tools to actually create a secure application. And he's telling it, I want it to be secure in this way and this way and this way. And still it has had a ton of vulnerabilities.

That's interesting because a lot of people, I think there's a misconception that if you tell it, if you give it context to be secure, it will be secure. It sounds like that's not true.

That is absolutely not true. And if you want, go to our LinkedIn page, Bright AppSec and you will see that post and it has like screenshots of going through that whole process. But so that's the current state and that's where we are today. Now fast forward to your question of, well, what is the developer experience? And in the world of AI and AI generated coding, we are moving from a world of I need to find the vulnerabilities, do I have to have a closed loop cycle of finding and fixing the vulnerabilities? Because the developers don't have time to fix the vulnerabilities. So we need to make sure that we're working with their AI, the exact same AI tool that they're already working with and fixing those vulnerabilities as part of their cycle. How does it work today with the solution that we call star, Security testing and auto remediation, that's what it stands for. Plus it sounds nice with Bright, but it actually stands for. By the way, you didn't ask about my jacket. These are the bright jackets.

I love the jacket. Oh, all right, I get it now. I love it.

Any conference you go to, you will see our team with jackets like this or even way worse colors. These are one of the OG ones, so I still get to have a slightly bearable color.

But.

When we look at the implementation of star, right, the rules were we co developed it with a bunch of our customers. So you're looking at some of the world's largest banks, companies like Blackstone, so very large financial institutions, insurance companies. And they came to us and said, we've got this problem of we're using vibe coding, we're using AI assisted coding, whatever you want to call it. And we are seeing a lot more vulnerabilities. How can we get to a point where these vulnerabilities are automatically fixed as part of the development life cycle? So the solution we came up with was one they told us, do not introduce your own AI into our environment. If you try to introduce your own AI into our environment, you're now going to three years of regulatory work. So don't go there. So work with the AI that we already have. Okay, great. And then whatever tools we're using, it's all the lists from earlier, right? If it's cursor, if it's cloud code, if it's GitHub, Copilot, we want you to integrate into that, make sure that you're working directly with our cli. So it's right in our development environment. We said, great. They give us very clear guidelines on what needs to happen. The cycle is conceptually very simple. We integrate directly into the code base. If you're using GitHub, or if you're using BitBucket, or if you're using GitLab, doesn't matter. We integrate directly into the code base. We can already run the discovery and find all of the entry points, all the parameters, all the APIs, all the shadow APIs, which is very important, directly from the code base. So we run that discovery while the developers are just starting to code the net. Yeah, go ahead. You have a question?

I'm in cursor, I'm typing away, Enter, blah, blah, blah. Yeah. And in the background you have a CLI that's running. Does it pop up and say, whoa, whoa, whoa, there, that line of code you just wrote.

So you have multiple ways of doing this, right? One option is saying, I want you to just sit over my shoulder actively and periodically run scans. The more common way to do it is when they actually run some kind of commit, right? So they're doing some kind of commit. At that point, we will initiate the scan. The first step of initiating the scan. So we're constantly mapping in the background, but the first step of initiating the scan is actually looking at what we've already discovered and deciding what are the relevant unit tests. So we automatically generate the correct unit tests to understand which vulnerabilities could exist. Because we have a very broad set of security vulnerabilities that we could test for. There's more than 15,000 payloads that we can run across web applications and APIs and business logic vulnerabilities and LLM vulnerabilities, etc. If we try to run all 15,000 every time somebody does a commit. That's never going to work because these scans have to run in seconds or minutes at the most. Otherwise developers won't wait for them. We have to do something that will integrate into their flow. So based on understanding the code base, we decide which unit tests are the most applicable and have to run at this point, run those unit tests. So on the side we compile, we do our own compile of the application. We run the scan because it is still a dynamic scan, even though it's running as part of the unit testing phase. Unique technology. A lot of investment went into doing this. Find the vulnerabilities and then once we know what the vulnerabilities are, we go back to whatever LLM that customer is using and tell it, okay, this is the vulnerability. Here's all the context, here's the dynamic proof of that vulnerability, and here's guidelines on how you can fix it. So we're not relying on AI to fix AI, we are guiding the AI. And I'm sure you've had this experience, right, where you just tell AI to do something and it does something random and surprises you. We're not trusting that. We're giving it all the context and all the information and, and then telling it to fix it. We still don't trust it even after that. We run a validation scan. So we rerun the exact same unit test that we've already run and we make sure that the vulnerability is gone. Once we've confirmed that, then we give the developer the pull request and tell them, here's the vulnerability that we found, here's proof that that was a vulnerability, here's the fix that we provided, here's proof that this fix works. Here, go ahead and deploy it. So that's the star cycle. There's some permutations on this. For example, if we can't fix the vulnerability in the first iteration, we will run up to six iterations because we've seen that after six, there's diminishing returns. And if in that case today we're seeing that we're able to auto remediate in a validated way. And this is an extremely important point, that validation, validation piece is something that I'm not aware of any other company that is able to do. Because if you look at all the, like starting with Aardvark and all the other tools that are automatically remediating code, they're all doing it on the static way. They're all doing it directly from the code. So it's AI fixing AI right. We are taking all that context from the code, but giving it external context and external information and running that validation. And that is very unique because you know for sure that the vulnerability was fixed. The result is amazing because now a developer doesn't have to waste any time on finding the vulnerability, on trying to fix the vulnerability, on trying to figure out if it's a true positive or false positive. We're seeing static tools that are at 60, 70% false positives. That's just not acceptable in today's day and age. That reduces the time very significantly in the unique cases. So about 10% of the cases so far were not able to solve the vulnerability. Will tell the developer, hey, here's everything we did. This is the vulnerability, this is what we tried. Take it from here. But in 90% of the cases, all the developer has to do is review a pull request and deploy it while they're in the same development environment. That's a very long answer to the short question you asked around. What's the developer productivity? How does this integrate with developers, et cetera? One more small thing I will say, and then I will stop, is it's very important that the AppSec team has visibility into all this as well. So while they're not part of the cycle, they're not looking at this day to day. They are definitely getting all the reports so they can see, hey, we found 100 vulnerabilities in this application or 10 vulnerabilities. Nine of them were remediated, right within the development lifecycle. One was not remediated and there's a comment from the developer. Why? By the way, we also ran scans later in the development process, right? This is part of our broader olution because sometimes LLM vulnerabilities, business logic vulnerabilities, more complex vulnerabilities will not manifest early in the development life cycle. So you need to still run scans in the CI as part of pre production, as part of QA to, to find the things that didn't pop up early. And the AppSec team has visibility across everything. What was found, what was remediated, when was it found, how much time did we save? How much more efficient are developers? How much more, how much risk did we reduce by finding and fixing things early?

This is great. I can assume if you're in like, in a regulated environment like banking or healthcare, you need proof of certain things. This sounds like it's doing it all automatically for you as well. So it's not like you're doing some sort of black box like magic it's actually you're telling exactly what's happening, you're auditing it, and you have files that you can then use for audits, probably, I would assume.

Yeah. So we look at that in three different ways. And number one is obviously there's an audit log in the system that shows you everything. Number two, there's reporting in the system where you can see all the information of what was found, when it was found, when it was generated. We have all these dashboards in the tool. But number three, which is critical especially for larger organizations, we have. Everything that I just talked about can be run through either MCPS or through our cli. Sorry, through our API. What that means is that if they already have an overarching system, either it's an ASPM they that they use. No matter which ASPM it is, we're integrated with all of them, basically. Or if they have some kind of other reporting tool like a ServiceNow or something they're doing in GitHub with Sarif or anything like that, they can get all of the data through our API into those tools so they have full visibility. And now that correlates that information with any other tools that they have so they can get all of that data. Again, it's an enterprise tool. Right. So it has to have those. Those requirements. The reason I started laughing is that we. We did a short campaign and I hope we get to get back to it at some point, but we called it AI compliance in 30 minutes or it's free. We built on those of us who love pizza, but it really was that we enabled some of our customers with this AI tool to deploy a full dynamic solution. And we actually did it 60 minutes, not 30 minutes, but within 60 minutes, they were up and running and testing vulnerabilities for their AI applications.

Nice. Yeah. I was going to ask how hard would it be to integrate? So it sounds like you have really good API and MCP server. So I guess it doesn't really matter what technology that you're using for the IDE or language. Is it that bridge is going to take care of the communication back and forth for you automatically?

Yeah. So it's dynamic, so it's completely language agnostic. That's not an issue on the MCP front. Yeah, we basically support all of them. And this is a race against time. Right. So we have, I can tell you, we have four customers right now and two prospects that are all waiting for a new MCP implementation or a new integration into a code repository. But they all have commitments that it'll be done in the next six weeks. So it's very quick.

Nice. So I don't know if you did address it, how do you actually get by false positives though? Do you have a strict kind of way? You can say, I'll go ultra strict, I don't care what it is. Or do you learn over time? Is it adaptive in this environment? I know these people always do this thing with security, so flag that as high priority. I don't know. How does that work?

Yeah, like any good thing in the military, it's divided into three parts for validating false positives. One is we actually, because we're a dynamic tool, we try to find proof of exploitation. So we're actually able to dynamically run the application and see if it could be exploited or not. We don't actually exploit it, we stop right before exploiting it. But we are able to run this dynamic proof and show proof of exploitation. That's number one, which is something we invested a lot in and you touched on it. Right? It learns over time. It improves over time. Number two, the way, and our approach has been for say, six years now is if we have a false positive, we don't just chuck it to, oh, yeah, that's a false positive. It's okay for us. It's a bug. We actually treat false positives just like you should treat security vulnerabilities as bugs. We treat false positives in our tool as bugs. That means that we are constantly monitoring of did we find a false positive? If yes, how do we eliminate it? And we're looking at that from three different parts. One is our customers sometimes report false positives and we treat it as a bug. Two is we have MSSP partners that we work with closely and they're constantly running scans with our tool and whenever they find something, they raise it. And three, we have our own team that reports to our ciso. That team not only provides services for our customers, they also are constantly testing to find new vulnerabilities, new types of attacks that can be added, and if there is any false positives. And then last is, we do acknowledge that there is a difference between technical vulnerabilities and business logic vulnerabilities. Business logic vulnerabilities could have false positives based on context, and we're okay with that. In those cases, we just let the customers tag something as a false positive and we learn from it and we manage their system accordingly going forward. And sometimes we can actually eliminate those false positives and we treat them as bugs as well. But Our commitment is, look, we're going to have less than 3% false positives for, for technical vulnerabilities. Sometimes business logic vulnerabilities might have more, but it's important that you know about them.

Great, great. So you said you're not replacing AppSec experts, but if I'm a developer, like do I have to even care now? All right, it says I need to do this. Yes, commit. I don't care. Whatever it says, like how much of a security expert does a developer need to be like, are they going to be lulled into like, oh, you're secure now? Because how does that all work? Does that make sense?

It's actually an interesting journey. One of the things that we did when we started deploying to larger and larger organizations and today we have companies with 15, 16, 20,000 developers using the solution. We actually had people on our team go into the customer environments and do sessions with them around, around secure development. So to teach their developers and help their developers didn't make any money of it. That wasn't the goal. The goal was to actually educate our customers because they were not there. As things evolved, we learned that we could really. You can lead a horse to water, but you can't make a drink. You can lead a developer to vulnerabilities, you can't make them fix them. So having the auto remediation is very, very important. But you still want to have developer advocates, you still want to have secure coding awareness because if you have people that are aware, they will at least look at the information and validate that it's real and that it's true and the vulnerability that was found was real and the proof that they got was real and that the fix that they got was real and not just push, yes, accept the pr, accept the pr, which by the way is a terrible, terrible phenomenon that's happening with a lot of tools now, right? They're getting non validated remediation and they're just saying accept, accept and that's not healthy.

So can you use this almost as an education tool? Like over time it knows your team and knows the type of vulnerabilities it may try to check in and maybe you could flag it to an executive like they don't have to be an expert. Hey, by the way, you may want to get training for, I don't know, this exploit or something. I don't know.

Yeah. So again we look at it in a number of different ways. One is we have integrations with tools like Secure Code Warrior where we automatically trigger training for people based on or we send them the information and they will automatically trigger training based on things that are found. Two is we have reports around hotspots, so we will tell the organization, hey, this team is more prone to vulnerabilities, or your entire organization is more prone to these types of vulnerabilities. So you might want to run some training. The other interesting discussion of looking at it in a completely different way is we have been talking to some of the AI coding assistant companies of how can they better train their models based on our tool finding vulnerabilities and training their model on how to not generate those vulnerabilities. Those discussions are in various degrees of progress.

All right, so you have a really interesting background. I think you were an elite unit in military with cybersecurity. So upfront, how can we even keep up with AI in the sense that AI, I would think, is able to make your attack space so much bigger than what you can keep up with. How do you keep up then with as the different attacks probably AI can come up with, how do you defend against that? Constantly.

Yeah. I think, again, divide that into a number of different parts. First of all, you need to have awareness. You need to understand what's actually happening. And the fact that we have moved from a world in which attacks are happening periodically to a world where attacks are constant. There's no such thing of, oh, yeah, somebody attacked us last week, somebody will attack us. No, you are constantly being bombarded because AI agents are running rampart and just doing their own thing. And in many cases, people just set them and completely forgot that they even exist and they're out there. So once you change your mindset, that also changes your mindset around. Well, I can't just run my scans periodically. I have to continuously be scanning and I have to continuously try to find vulnerabilities. But I also have to evolve my solution continuously. And what that means is that there's two types of LLM concepts that we're dealing with. Number one is exactly the one you touched on, which is there are new LLM vulnerabilities and new attacks that are LLM generated that we have to block for. And if you look, OWASP released the OSPLM top 10, and then they released the second version of it. They're still learning. Some of them are absolutely correct, some are less relevant, but at least we're doing something about it and we're progressing in that area. So that's one area where you need to make sure that the tools that you have and the tools that you're deploying are up to date and have the ability to scan for the latest vulnerabilities and are constantly adding more tool, more vulnerabilities and more signatures that they can find. That's one critical aspect. The other aspect, though, is not just LLM vulnerabilities, but it's vulnerabilities that could exist in LLM generated code. And that's where we get into everything that we talked about. There are legacy vulnerabilities that exist in LLM generated code and they're happening at a much higher pace. So you need to make sure that the practices that you're deploying enable you to keep up with that pace.

And using Bright Star, it's updated constantly, I assume. So it's almost like a best practices database that, you know, something comes up, you're going to be updated, you're covered. In a sense.

One of the advantages of a SaaS solution, right, is that releases are not happening once every three months or six months, they're happening every couple of weeks. But there's. If new stuff comes up, it's added immediately.

All right, so if A team has zero DAs in place today, what is the first step you would say, for them to take this quarter to actually reduce real risk?

Well, the first question I was asked is, the first two questions I would ask is, what are you actually doing today? Like, are you already doing static? Are you already doing manual pen testing? What, what are you doing to understand the environment and what are we stepping into? That's one three questions, not two that I would ask. The second one is, what is your technology footprint? Are you using AI assisted coding? Are you not a using AI assisted coding? I would be very surprised with an organization that says they're not at this point because that just means they have developers doing it and they don't even know about it. And that scares me. But really understanding their technology framework so we can understand what solutions can actually be provided to them. And the third one is, what are you actually trying to achieve? And that's a critical question because there are companies that will say, you know, I just need this for compliance. I need to provide a compliance report to a regulator. And that means that I need to run a scan once a month and that's all I need to do. And that means that I have a lot of education to educate them on. Well, why that compliance at CYA is not enough. You need to do more and you're not going to achieve your compliance if that's all you're doing. On the other hand, the company might say, I need to make sure that I'm not at risk. And then that's a completely different discussion because now I'm barging into an open door where they understand what they need to do. Now they're just open as a clean slate for the solution. So those are the three questions that we always ask our customers when we start a discussion with them. Obviously there's a lot of others and then we give them the guidance. A lot of the work we've been doing is actually with analysts and trying to educate the market. Right. And we're this small in the market and the market is huge. So you have to try to leverage analysts, you have to try to leverage webinars and your own customers. So I can tell you in the next quarter. So from January to March, we're going to be doing multiple webinars that will be open and people can join again. Everything will be posted on our LinkedIn and there's going to be a webinar with actual customers. The first one is at the end of this month. We are going to be talking about Practitioners Guide to surviving the AI Coding Apocalypse with one of our customers, a very, very well known security expert. Next month we'll do another one with one of the world's largest financial institutions. In March, there'll be another one with a bank, which is a customer. So our customers are understanding that they want to see a more secure world and they're willing to put themselves out there and talk about what they've been able to achieve so others can do better as well.

All right, this might be a rambling question. Is there like a metric you think someone can know or use to see if their app App sec efforts are actually improving? The reason I bring this up a lot of times like, like with software quality, with finding bugs before they get into production security, it's almost like it's a cost center because they don't realize, like, how do you know, like what you did actually help the bottom line. And rather than them going, well, we don't have security issues because our app's been secure and only because they did all the upfront work using your tool to, to get there. Does that make sense?

Yeah. So we actually have a NRI model that we work on with customers to enable them to show the value of the solution that they implemented. And while there are a bunch of different metrics in it, there are three critical metrics that you always look at. Number one is the time it took to find and Fix vulnerabilities. And I can tell you, world's largest private equity company deployed our solution. They've been a customer for four, four and a half years now, but they were able to reduce the time to find fixed vulnerabilities from 12 weeks to 12 hours. That's a metric that you look at of we were able to improve that time by 98%. That is very, very significant. A derivative of that is reduced risk. And depending every organization measures risk in a different, in a different way or they apply different value to that risk. But if you're able to say, you know, for 90% of vulnerabilities, I'm finding them before I deployed to production and not finding them after they're in production, that has a significant impact on risk from our organization. And that risk has value because I can reduce my insurance costs now, I can reduce my liability costs. I can then reduce a bunch of different things. So that's the second metric that we looked at of what is the reduced risk in your environment. And the third one is developer productivity. If I looked at developers beforehand and I said out of every week that a developer spends, they're spending 60% of their time chasing false positives and chasing noise, or 40% of their time doing that, and now they're spending less than 5% on that, and they're spending much more significant time on valuable development time. How much is that worth? How much are you paying your developers? 2, 3, $400,000 a year? Depending on where you are in the world, that is a significant impact as you just made your developers 20, 30, 40% more efficient. Those are hard metrics that you can look at. And we have this structure where we call it a maturity model. We map our customers based on the maturity model and we tell them, okay, you're a level two here, you're a level three here, you're level four here. This is what you need to do to move to the next level.

Very nice. Okay, Kadi, before we go, is there one piece of actual advice you can give to someone to help them with their DevOps efforts and security efforts, and what's the best way to find and learn more about Bright Star?

Yep. I think the one piece I would give in terms of what, what do you need to do tomorrow is understand whether you're using AI assisted coding, which most organizations are, and do you have, or do you feel that you have the tools in place to make sure that you are not going to be behind the eight ball? Because I can't tell you how many times. I've had the discussion since we launched Star in May last year. So it's eight months now. How many times I've heard, oh, not yet, we're not ready, not yet, we're not ready. And then I get a phone call. Two weeks later, it's like, shit, it's too late. Pardon my french, right? Because every organization that I've talked to, right when in the past DAST was applicable for 25, 30% of organizations. No, this is applicable for 100%. If you're using AI assisted coding, you need a solution. And whether you're going with Bright or you're going with a different solution, obviously I think you should go with Bright. But it doesn't matter. You have to make sure that you put something in place because otherwise it's going to be too late and you are going to be exposed because the attacks are continuous in terms of finding bright, three easy methods that I will give our website brightsec.com so B R I G H T S e c s e c.com you can email me directly gotti g a D I brightsec.com or you can find us on LinkedIn brightupsec. That's three different ways. Or just call Joe, he knows us.

And you find links to all this awesomeness down below. And for links of everything of value we covered in this DevOps Toolchain show, head on over to testguild.com P203 so that's it for this episode of the DevOps Toolchain Show. I'm Joe. My mission is to help you succeed creating end to end full stack DevOps toolchain. Awesomest. As always, test everything and keep the good. Cheers. Hey, thank you for tuning in. It's incredible to connect with close to 400,000 followers across all our platforms and over 40,000 email subscribers who are at the forefront of automation testing and DevOps. If you haven't yet, join our vibrant community@testguild.com where you become part of our elite circle driving innovation in software testing and automation. And if you're a tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real world challenges. We're excited to Collaborate visit test guild.info to explore how we can create transformative experiences together, let's push the boundaries of what we can achieve. With lutes and lyres, the bards began their song A tune of knowledge, a melody of code through the air it spread like wildfire through the land Guiding Tester showing the secrets to behold.