82. Automating app security for modern dev teams (with Rejah Rehim)

I'm Amreja, one of the co-founder of Beagle Security. We are into penetration testing automation, human-like automation for penetration testing. Oh, thank you. Welcome to the show.

This is the security podcast of Silicon Valley. I'm one of the hosts, Joe McLaughlin, and joined today with the other host, Sasha Sinkovich. And Reja, thank you so much for joining. Thanks for having me.

You're the co-founder and CEO of Beagle Security. Yes. Amazing. Spectacular.

It's a great honor and pleasure to meet co-founders and founders and people doing the zero-to-one thing and building new things in this world, especially in the security space. Yep. Yep. Thanks for having me in the show.

We're always super interested to understand, like, what inspires, like, these journeys that founders embark on. What inspired your journey? I'm basically a penetration tester or an offensive security side of things. Like, early in my career, I did penetration testing, reteaming, and saw the same problems repeated across organizations.

Security was often treated as an afterthought. It came in too late, and the results were rarely actionable. Development teams were moving fast, but the security team wasn't keeping that pace with them. So, I realized that the traditional approach couldn't scale in fast-paced environments like the newly transformed development environments.

That's when the idea of Beagle Security started taking shape. I wanted to build a platform that makes application security proactive, developer-friendly, and scalable across the platforms. It wasn't about starting a company for the sake of it. It was about fixing something that clearly needed to change.

And what needed to change? Like, shifting penetration testing or application security in the early stages of development, software development lifecycle. And so, shifting left for those who are maybe not as technical, it means getting closer to the problem itself? Like, normally, what happens on the penetration testing side or security testing side is it happens after the development.

So, when we give a report or when we provide with the report, the time to fix it or the cost for fixing those issues will be huge in the waterfall model or when we consider security at the end of the development lifecycle or after releasing something in the production or staging. But testing it in the early stages, integrating with the development lifecycle easily. That will reduce the cost of fixing also the time to fix issues. So, how long have you guys been building Beagle Security?

We've been building the platform since 2018. But we published it in a private beta in 2020. And we registered the company at that time. In 2021, we ran a lifetime deal to accommodate maximum users.

Or we need to run as much tests we could in the platform so that we can make the platform better or improve the system as such. Because ours is a supervised learning system in the backend. And in 2022, we made it a SaaS platform, a recurring subscription-based platform as of now. When you say supervised, do you mean you had red team members that are part of your organization and they were essentially leading the pen test remotely?

And then you transitioned into more software? No, it's a security testing engine in the backend. It's like a system that learns by itself about the new vulnerabilities. Even though we do have a R&D team, which feed the newly found vulnerabilities and the business logic testing use cases and improve the system by its own.

But it's learned the application and choose the test cases and the payloads on the go. That system is an AI engine in the backend. That's why I mentioned it as a supervised learning system. Okay.

So the supervised learning in the context of AI. And this is one of the approaches where you can dynamically adjust the pattern or the methodology that is applied to the problems. Yeah. Yeah.

Like it's choose the test cases based on this tech stack, the application build with. It will identify these are the possible test cases need to be tested. And also the payloads based on the response from the system. It adjusts the payloads, everything on the go.

Based on all of the feedback that you get from your customers, what is the biggest pinpoint that your product addresses? Where does it make their life easier? Yeah. Like for the customers who follow a rigorous development lifecycle or rigorous development flow, they release on a daily basis or on a weekly basis.

But they have to wait for another three months or even if the test is on a quarterly basis. The test is not happening on that frequency. And there is a huge gap in between the tests. So projects that run on a rigorous manner, the gap between the tests is very huge.

The main thing they can't automate is that it happens in a manual way and it will take around 20 to 25 days to complete a end-to-end penetration testing in the platform. So what we are doing is like automating that to happen in within two to three days so that it can be indicated within the time period of the functional testing itself. Also, it can be integrated with the development workforce. Like they can trigger the tests from the CICD pipelines and get their reports directly onto the bug tracking systems.

It's highly tailored for the developers so they can use it in their workflow to get the things fixed early in the development lifecycle. Are you completely replacing the human involvement into the pen test or red team and exercises? Or are you augmenting the process of vulnerability discovery? Are you working on all of the layers of the product or is it only the source code?

No, no. We are not working on the source code side. It's a DAST side of it, like dynamic application security testing. But it's not just scanning.

We'll be doing in-depth penetration testing. So we are trying to replace the application penetration testing side of the manual part. But there are some complex business logics attached to each application. So we are trying to automate that part.

But universal automation for all applications with its business logic is too complex. So we are trying to achieve that. But there will be some gap. That's why we ask, even if a team have a penetration test, he can focus more on the complex side or the business logic side of it.

And all the other things we'll be able to automate by the platform itself. So unlike the human, we will not skip any test cases. And it will accommodate as much test cases as it could. So the error percentage will be less.

But some part yet need to be addressed that we are trying to achieve on the go. No, that's super interesting. Thank you for sharing all of that. I love trying to use AI and thinking about AI, uses of AI to take care of the tedious parts of work.

And I think in terms of red teaming and penetration testing, there's definitely like lots of tedious aspects to that. I'm super curious, though. I've played with some LLMs. I've played with some AI, some Anthropic, and they seem to build in their solutions pretty good guardrails.

I've tried to use AI to poke into systems and to break systems and to, hey, find the vulnerabilities in these systems. And oftentimes, like, I bump into these guardrails that come back with vanilla responses like, oh, thank you so much, but you were not allowed to use this for nefarious purposes or for breaking into systems. So did you bump into those same sorts of things when you were building Beagle security or? Yeah, of course.

Like, we are not using the public LLMs anyway. And it's not a single LLM asking something in the LLMs and getting the results and use that in the platform. It's not like that. We do have multiple areas which we use AI modules or maybe it's maybe LLM and something it will be maybe decision makings.

So what it does is like take the decision like a human in every stage of the testing. So we are using LLM in the report generation side. Our report will be highly tailored and actionable in size for the developers. So it will be based on the text stack that's used in the platform in the application.

So it will be step-by-step reports, a recommendation provided for the developer. So for that itself, we are not using any public LLMs because as it's a security product, we do have limitations to use in the public LLMs because of the data leak. We do have our own models, which we trained internally with the data we have, with the recommendations we provide, with the test cases and payload generation engines we have. Where do you get the data that you train your models on?

That's what I mentioned the first time. We do run a LTD. Initially, we do have around 1, 700 plus users signed up for that. And they ran tests on their web applications.

We use those details to train our platform in an anonymous way. How many users are on the system today? Around 2, 000. We do have 10, 000 plus users, but we have around 1, 700 plus customers who are paid at least once and around 200 plus customers who are recurring as of now.

Do you tend to see like B2B customers or these like individuals within the company? Is it bottom up go to market? So anyone can just, like if someone's listening to this podcast and is interested to try it out or see what it is, they could go to beaglesecurity. com and just sign up and start running these automated pen tests against a domain.

Yes, yes. But it's mostly B2B customers. But what we try to do is a do-it-yourself kind of security platform for web applications and APIs. So if you have a product or if you have a company, you have a web application to be tested, you can sign up easily and subscribe to a platform and subscribe to a plan and do the testing from your end.

Only thing we need it, you need to verify the domain ownership that we have to make sure that the owner of the domain is doing the testing. So we do have some verification method, let's file verification or DNS verification. After that, we'll be triggering the test from our end. Anybody can do the test, but a subscription base, mostly B2B customers as of now.

And we do have an enterprise option as well. How is enterprise option different? And why do you need to have enterprise tier for the product? Like, even though we don't tend the elephant hunting, like we didn't any sales or marketing for the enterprises, but we do have inbound customers who are asking for the product.

So what we do is like a different kind of pricing model. Mostly for the other plans, we do the pricing based on the number of tests they do on a month. But for enterprise, it's the pricing is different from the number of tests and it's count only the number of tests that runs at a time, like five concurrent tests or 10 concurrent tests at a time. So also we do have some features for enterprise like user integrations, XML, SAML integrations, kind of integration for enterprises.

And also some group reporting features as well. That's what different from other features. So you have a co-founder? Yeah, I have a co-founder who mainly into development side of it.

So you're a little bit more on the business side. Co-founder is a little bit more on the development side. No, I'm into business and also into the security side of it. On the security side?

My area is into the security part of it. And my co-founder is into the development side. You guys have been doing this for a long time since 2018, if I remember. Yeah, 2018.

Did you raise money? No, we haven't. We are bootstrapped. You bootstrapped?

Yes. Wow, that's unheard of. Well, that means like you're doing something right because you're able to sustain the business and sustain salaries and give it the love that it deserves. And you've been doing it for quite some time.

Yes, yes. We are break-even in the sense we are as our development team is in India. So we were able to meet the requirements as of now. But to expand, we plan to raise.

As most of our customers are from U. S. region, so we plan to move the major part to U. S.

and improve their sales and marketing in that side as well. What's been the proudest day along your entrepreneurial journey? Getting the first customer itself. As me and my co-founder, as I mentioned, we bought from the technical side of it.

So at the beginning, we were not aware of the marketing side of the platform. So from 2018, two years we took to build the basic, build the MVP. And after that, when we released, it was on private beta. We invited on some customer, but it was a premium based.

And when we released GLTD and when we got the first customer and the amount that from the product, that was the greatest achievement at that time. How long did it take to land your first customer? Two years. What's been the most challenging day along your journey so far?

Currently, we are working on the next release of the product. Because as I mentioned, we do a lot of things in the backend with AI and ML and algorithms. But customers are not that much aware. They just provide the URL and we provide the report.

It's just like another scanner when they compare. So convincing the customers was very challenging throughout the years. But what made us proud is like when the AI hype is in place and all at once, everybody's ready to believe that AI system can provide proper reports, proper PT reports kind of things. And we got a lot of customers and then a lot of improvements in last one year.

And our next release is in progress regarding like which intelligent reports or responses in the dashboard itself so that customers can measure the progress in their application testing or the AI testing. So before this year was very challenging in the sense of convincing the customers that we could provide a report, completely automated penetration testing report without much human intervention. You were at the right place at the right time. Who is your ideal customer profile?

Mostly VP of tech or CTOs for the small and medium customers and CISOs when it's come to the big companies. Is it usually organization that has a security team or a red team? Or are you trying to replace and help with that function that may not exist in-house? No, no, no.

Like we are not trying to replace the complete security team. Like I mentioned, for a big company, they will be having a lot of applications and they are doing development on a daily basis. So testing them on a regular basis without any delays with a small security team, that won't be possible. So they can automate a huge chunk of the testing just by automating it with the tools so that they can focus more on the complex business logic or complex vulnerabilities that only can be identified by the human penetration gesture.

But we are trying to automate as much as we could. Even they could record the scenarios if they believe, if the customer believes that this is a complex scenario in the application and any automated system can't do the automation in that area. They can record that area and upload to our system. And our system learns it on the go during the testing.

So we are not replacing the entire security team, but we can co-work together so that improve the coverage, also make sure everything is tested at least once before they release into the production. Yeah, there are a lot of manual functions that security team has to execute on a daily basis. But there has to be someone in the organization who recognizes that, hey, we can introduce a DAS system that will automate a lot of the spin points that we have to go through manually today. Yes.

Also, for a team without any security team, our report will be understood by the developer. So the thing is, even if they don't have any security team, they can use our platform. Also, what we do is like, we do a bit of hand-holding after releasing the report as well. If they do have any clarification needed in the report, they can connect us back.

One of our security engineers will be helping them to understand that report and fix us in the application. Why we do that is, if we do have any glitches in the report, we could identify and we could improve that in our system by adjusting the system by itself. Or if the customer or if the developer don't understand it properly, we could help them to fix it as well. So that's where we are today.

How do you think the future of red teaming will look like in 10 years? It's kind of far from now, but still. You are asking about the future of application security and red teaming. Like, it should be more automated or it should be more independent of manual work.

Because the development team is moving forward with wipe coding, with AI driven development, and a lot of integrations and intelligence in the platform. Also, attackers are in the adversaries, they are doing the same. They are using, like you mentioned, a lot of LLMs to generate payloads to do the attacks. So if the red teaming or application security side do the same improvements in their site, other than seeking the manual model or the legacy methods, it will be very heavily risked in that site.

Mostly in the coming years, there will be a lot of AI based systems in all areas, like in the SaaS to identify the security issues in the code level. Currently in the wipe coding, that's where the developers struggle. And also in the automated application security testing. Also in syncing those issues with other platforms.

So there will be more AI enabled system in the coming years to attend of bridge the gap between the development and security. You mentioned something, and I would like to double click into that statement, which is the attackers are using AI empowered systems today in order to find weak spots in the existing infrastructure or applications. That is true. Do you feel the scale is skewered towards favoring attackers versus the blue teams that are trying to defend the systems from being exploited?

The creativity in the attacker side is always exceptional. That's why they are attackers or in the adversary side. So they will be using the current system. So every innovation has another side or a black side.

Like dark web has great use as a system, but many are using it in the bad way, right? Likewise in the internet, likewise for the AI. So adversaries or attackers can generate good and attacking or converting payload, converting attack vectors with the LLMs currently available. Like John mentioned, some of the LLMs won't provide enough details, but they can run their own in the local and do the same thing and do generate complex attack scenarios.

It will help them to automate it in a better way or help them to achieve the attacks or do the attacks in lesser time. So most cases, the blue teams that's funded by the company, if they are not using the innovation in that level, it will be a problem and attackers will win always. You've been thinking about this a long time. You're a security guy.

I feel the passion for security. Where did that start? What's the story about how Reja got into security? I was a developer first and I used to contribute a lot to the open source community.

I was with the Mozilla Foundation and Adon developer. So always breaking something or finding a way to break something is always curious or it's very interesting for me. And that's why I started contributing to open web application security project or WASP. I did a development in browser, like it's a browser bundle to do the complete penetration testing from inside a browser.

That was my first open source project. And later I changed my designation to a security tester as such, even though I do consulting in DevOps and other areas, but more completely into the penetration testing side of it. And later on, when we used to develop, when we used to do the testing, I used to write a lot of codes to automate some parts of the development, some parts of the testing. So later on, when we used those scripts and other websites as well.

So we thought of combining that and providing us a platform. That's how we thought of building a platform for penetration testing automation. At that time, AI was not that much popular. So we started with machine learning algorithms and decision-making algorithms in the early stages.

I later on that moved to a complete full-fledged system that can automate anything in the security side. Let me ask you a question. It's been on my mind our entire show. Like, how did you come up with a name?

It's just a dog name. Like, what we thought of is putting some name that's not related to security and making it a success. But surprisingly, when we named Beagle, the name was a sniffing dog, which was highly curious and used in hunting. Ah, so it could find, like, bombs and luggage or, like, drugs being transported.

Okay. Okay, I get it. All right, I like it. Yeah, Beagles are good at that.

If you could go back in time and meet your younger self, would you? And if you could take your younger self out for a coffee, like, would you have any advice? What would you tell your younger self? First thing, as a founder, what we did wrong in the first time is spending too much to make the perfect product before it released.

So, it's like, fail fast or release fast as much as we could and get the feedback from the customers. And I'd rate, don't wait long enough to make the perfect product in our mind that may not be the perfect one in the customer side. That's spectacular advice. Sometimes that's a very hard lesson to learn.

Okay. Well, thank you so much for joining for an episode of the Security Podcast of Silicon Valley. Today, we've had the honor and the privilege to have Rajah Rahim, the co-founder and CEO of Beagle Security, on with us. And just as a friendly reminder, I'm John McLaughlin, one of the hosts.

I was joined with Sasha Sienkiewicz, the other host. And a huge thank you to all of our listeners for tuning in to another episode of the Security Podcast of Silicon Valley. This has been a Y Security production. It's awesome having you, Rajah.

Thanks for having me. A lot of gratitude in the world. Thank you. Thank you.