Latest / Code Story | Startup Podcast for CTOs, CEOs and Technical Founders / S13 Bonus: The AI SAST Shift: Eliminating Vulnerability Backlogs with Santiago Castiñeira, Co-Founder & CTO of Maze

Transcript

S13 Bonus: The AI SAST Shift: Eliminating Vulnerability Backlogs with Santiago Castiñeira, Co-Founder & CTO of Maze · Code Story | Startup Podcast for CTOs, CEOs and Technical Founders

• 0:00
  [SPEAKER_02]: I work very closely with a very big public tech company from the US and I was working very closely with their security team and we were building this data lake of cybersecurity data mainly, vulnerability data and asset inventory and what this thing was doing was using that data in order to inform and to drive basically all the internal vulnerability radiation processes.
• 0:22
  [SPEAKER_02]: And a few things from my perspective were odd, so these things were generally heavy with security engineers, but they had a fundamentally data problem, a very deep data problem.
• 0:33
  [SPEAKER_02]: That was basically what are the advantages that we should be fixing today and which are the ones that can't wait or which are the ones that don't apply to us.
• 0:40
  [SPEAKER_02]: My name is Santiago Castñera and they
• 0:49
  [SPEAKER_03]: a podcast bringing you interviews with tech visionaries six, six months moonlighting goes last and on the bedcats who share what it takes to change an industry I don't exactly know what to do it doesn't go to get right
• 1:02
  [SPEAKER_01]: Who built the teams that have their back company, is it's that teams help each other achieve this proud of her team.
• 1:09
  [SPEAKER_03]: Keeping scalability top of mind, all that infrastructure was that hasn't been fighting it as we grew.
• 1:14
  [SPEAKER_03]: Total waste of time.
• 1:16
  [SPEAKER_03]: The stories you don't read in the headlines.
• 1:18
  [SPEAKER_03]: It's not an easy thing to achieve, to get yourself interested in off and try to begin.
• 1:22
  [SPEAKER_03]: To ride the ups and downs of the start-up line, need to really want it, not just about technology.
• 1:29
  [SPEAKER_03]: All this and more, on code story.
• 1:32
  [SPEAKER_03]: I'm your host, Noah Labpart, and today, how Santiago Castagnara has built AI agents for your code and cloud that investigates every vulnerability and helps you get them fixed.
• 1:49
  [SPEAKER_03]: Santiago Castañera has quite the background in international living.
• 1:53
  [SPEAKER_03]: He was born in Argentina, Berkurup and Spain, then moved to Sweden, San Francisco, and now lives in Germany.
• 1:59
  [SPEAKER_03]: He did his great school on university in Spain, but his master's program across Sweden, San Francisco, and Germany.
• 2:06
  [SPEAKER_03]: He's worked in startups, bigger companies, and eventually founded and is leading his own.
• 2:11
  [SPEAKER_03]: But outside of tech he's a dad of three kids so he stays quite busy when he isn't working.
• 2:15
  [SPEAKER_03]: He loves endurance sports running half marathons and long distance biking.
• 2:22
  [SPEAKER_03]: Tantiago and his team were well aware of the fact that tens of thousands of new vulnerabilities are published every year.
• 2:28
  [SPEAKER_03]: While security teams are drowning, the rise of automated coding agents were starting to ship code faster and faster.
• 2:35
  [SPEAKER_03]: He and his team realized that they're needed to be an agent-driven platform designed to evaluate and secure your system like a senior security engineer.
• 2:46
  [SPEAKER_03]: This is a creation story of maze.
• 2:53
  [SPEAKER_02]: With May's basically a triage on Rmd8 cloud and code unabilities for companies of very different sizes.
• 3:01
  [SPEAKER_02]: The story comes basically from my last job before May's, so in that company what I saw, I worked very closely with a very big public tech company from the U.S. And I was working very closely with their security team and we were building this data lake of cybersecurity data mainly when I read the data and asset inventory.
• 3:20
  [SPEAKER_02]: And what this thing was doing was using that data in order to inform and to drive basically all the internal punitive radiation processes.
• 3:28
  [SPEAKER_02]: When working with this team, I got to understand really the problem and how they are solving it internally.
• 3:34
  [SPEAKER_02]: And a few things from my perspective were not, so these things were generally heavy with security engineers, but they had a fundamentally data problem, very big data problem.
• 3:46
  [SPEAKER_02]: that was basically what are the vulnerabilities that we should be fixing today and which are the ones that can wait or which are the ones that don't apply to us.
• 3:53
  [SPEAKER_02]: So this company was highly regulated, had a lot of compliance requirements, so there was a very strict process, very strict time events, right?
• 4:00
  [SPEAKER_02]: So they were really, really doing their best.
• 4:03
  [SPEAKER_02]: But I found that there was a lot of context missing for all the decisions, there was skills missing that I think that basically stuffing these teams of health in and with all those skills like data engineering or machine learning could really get them too much better play.
• 4:15
  [SPEAKER_02]: So, that was basic that experience and eventually that started up pivoted away, into a different direction and then at that point I decided to go explore this idea.
• 4:24
  [SPEAKER_02]: So, I went out with security professionals to see if what I was seeing
• 4:32
  [SPEAKER_02]: I had some experience with other customers or other prospects from that for my last job, so I was fairly certain but I just wanted to double check that externally this all the companies would have the same.
• 4:42
  [SPEAKER_02]: And then I went basically talking with investors and seeing, hey, there's a million companies doing this one thing but I still see that this is broken.
• 4:50
  [SPEAKER_02]: And it must have worked very happy to hear new takes on this ADS, and especially from outside of service security.
• 4:56
  [SPEAKER_02]: So yeah, eventually, when looking for co-founders and that's how I met Harin Adrienne, we worked for a few weeks together where we were basically trying to validate the problem, trying to talk with companies and understand how big of a paper new world is and so on.
• 5:09
  [SPEAKER_02]: And then eventually yeah it all makes sense together.
• 5:12
  [SPEAKER_02]: So I invited two of my engineers for my last job That were some of my did the direct reports basically within my GN team and they joined us So we're five people and that's how it got to Let's do this we're doing a file.
• 5:25
  [SPEAKER_02]: We understand the problem well Let's go from here.
• 5:27
  [SPEAKER_02]: So at that point we had I think salary like funding for two months or something like that So we couldn't pay salaries for a long time, but it was just like let's give it a shot That's how we do really started
• 5:39
  [SPEAKER_03]: Okay, let's dive into what you would consider the MVP for May's, the first version of the product you built, how long it takes to build and what sort of tools we're using to bring it to life.
• 5:49
  [SPEAKER_02]: Given our background for the 3 engineers that were, we had a few things that we wanted to have in place that was basically bringing a lot more contextual data.
• 5:56
  [SPEAKER_02]: So in our minds, the NDP was like, can we bring a lot more data and connect it to the vulnerabilities and then to a better informed decision on which one should be handled first?
• 6:09
  [SPEAKER_02]: And that was basically our initial very, very raw idea of the MEP, and then we're very open-minded around technology.
• 6:15
  [SPEAKER_02]: So we didn't have anything setting our minds, which just had the idea that we wanted to get.
• 6:20
  [SPEAKER_02]: And, basically, this was mid-2024, and the first version of Landcraft were coming out.
• 6:28
  [SPEAKER_02]: They were very bad if, every way they were broken for something different, but what we managed to prove with land graph is that basically all the lamps could understand, configuration and metadata from places like AWS, all your code repositories and from there basically produce how can I say like a judgment or an assessment on aspects of the vulnerability.
• 6:51
  [SPEAKER_02]: that's really what accelerated this.
• 6:53
  [SPEAKER_02]: So when we got that technology we realized that this is transformational, this is going to bring a lot of new benefits to the solution.
• 7:01
  [SPEAKER_02]: So we went forward with it, trying many different frameworks and different types of LLMs.
• 7:06
  [SPEAKER_02]: And it took us from around mid June or early July to November of that year to basically get the first actual MVP.
• 7:16
  [SPEAKER_02]: But this was really an NDP of the engine itself, so basically the decision making the algorithm that will actually rank, let's say, your own abilities.
• 7:24
  [SPEAKER_02]: And once we got that piece, for us it always felt like the hardest.
• 7:29
  [SPEAKER_02]: We validated it with the security engineers that we hire a few consultants and with our design partners.
• 7:35
  [SPEAKER_02]: And then from there it took us another...
• 7:38
  [SPEAKER_02]: Yeah, I would say on a 6, 7, 8 months, while growing the team at the same time, until we got to an MVP version that we could actually put in front of a customer and they could use it, 100%.
• 7:50
  [SPEAKER_03]: Let's stay on that engine for a minute.
• 7:53
  [SPEAKER_03]: In building that engine and approaching the problem, you've got to make certain trade-offs, right?
• 7:57
  [SPEAKER_03]: Make certain tough decisions, and maybe how you're going to limit functionality, or how you're going to approach the problem, or all the sorts of things, tell me about, let me one of those core decisions you had to make, and how you cope with it.
• 8:10
  [SPEAKER_02]: I think one of the biggest decisions we had to make that early on was deciding basically what data sources do we want to use.
• 8:18
  [SPEAKER_02]: Because when you're thinking about it, it's basically contextualizing a problem.
• 8:22
  [SPEAKER_02]: As we were in that place, basically this vulnerability is irrelevant or not.
• 8:26
  [SPEAKER_02]: You can bring easily, like 20 different, basically data sources into the picture.
• 8:31
  [SPEAKER_02]: But that will make it's hard to know which are the minimum set, right?
• 8:35
  [SPEAKER_02]: One of the early decisions that we did was that we were going to go purely with the cloud context.
• 8:41
  [SPEAKER_02]: So, metadata about the environments we're running, some grant and configuration, but that was about it, so we will not be looking into the codebase, so we will not be looking into the GitHub of our customers initially.
• 8:52
  [SPEAKER_02]: So,
• 8:53
  [SPEAKER_02]: That's how we started at the beginning, and that's how does simplify the problem a lot?
• 8:57
  [SPEAKER_02]: Because still, don't let me wrong with any of you guys, there's so many data sets that you can use for these kind of things.
• 9:03
  [SPEAKER_02]: But just not thinking about, for example, an architectural response or any other sub-security tool data set.
• 9:11
  [SPEAKER_02]: That already simplified it.
• 9:15
  [SPEAKER_03]: Let's move forward then, so you've got the MVP, you've got the engine, working right, the rules engine, the core of what you're building, how did you progress it and mature it from that point?
• 9:24
  [SPEAKER_03]: I think inside that question, or within that question, is how do you build your roadmap?
• 9:28
  [SPEAKER_03]: How do you decide it?
• 9:29
  [SPEAKER_03]: Okay, this is the next most important thing to build, or to address with Maze.
• 9:34
  [SPEAKER_02]: A lot of talking with our design partners, so it's been the last time getting their feedback understanding how our solution would fit within the landscape of solutions or the search gauge products or talking with them about how they would use the outcome of our tool or will they use it directly in our tool or process it further somewhere else.
• 9:53
  [SPEAKER_02]: Basically, through those conversations, we managed to drive the roll map a little bit.
• 10:00
  [SPEAKER_02]: We had some ideas already, but I would thought it was a security or the management should be done.
• 10:05
  [SPEAKER_02]: So we drove a lot of, let's say, first principles that we had, but it was in combination with a lot of feedback from our customers, and basically what would give them the most value for a product.
• 10:18
  [SPEAKER_03]: I'm curious about teams on Tiago, so to build something like maze, you gotta have the right team.
• 10:22
  [SPEAKER_03]: And I know how your founding team sort of came together, but you can tell me about that as well.
• 10:26
  [SPEAKER_03]: But I'm curious about what you look for in the people that you hire to tell you that they are the winning horses to join you.
• 10:33
  [SPEAKER_02]: I read this somewhere, there doesn't come for me, but I read a very good phrase regarding things that are looking people and I did practice in this for quite a few years, so until now.
• 10:43
  [SPEAKER_02]: And this is basically high energy, high intelligence and high integrity.
• 10:48
  [SPEAKER_02]: So if you look for candidates that have high energy, they generally will not sit still, they will always want to do something and say we could board and they would just find something to do.
• 10:59
  [SPEAKER_02]: If they are high, highly intelligent, they actually will find really smart things to do, that actually move into the needle.
• 11:06
  [SPEAKER_02]: And if they have high integrity, you know they are going to have very good judgment and they are going to make sure that if something is not according to how we want to build a company, they are going to raise it up.
• 11:16
  [SPEAKER_02]: These together with a very strong vision of what we want to go and basically people that buy into that vision.
• 11:22
  [SPEAKER_02]: I think builds a very, a very strong team, so some of the earliest signals that we saw in the team was that we had built a team with a lot of autonomy So generally a lot of engineers in the team find their own problems to solve They come up with the next projects to do, they come and suggest either things that they've seen working better somewhere else And then in one of our system they say, hey, I've seen a much better version of this kind of building
• 11:48
  [SPEAKER_02]: And if we hire well, their suggestions are going to just be very good.
• 11:52
  [SPEAKER_02]: So, I would say those are some of the things that we look very early on, and that to this day, we keep driving towards.
• 12:03
  [SPEAKER_03]: let's talk about scale and scale is obviously baked into the bread and butter of how you build this product and given what you're solving.
• 12:12
  [SPEAKER_03]: But I'm curious about how you approached it in the beginning and then also I'm curious about how there have been interesting areas where we've had to fight
• 12:22
  [SPEAKER_02]: So, very early on, one of the key decisions that we did was thinking about the scale we were building this product.
• 12:30
  [SPEAKER_02]: So, I wanted to serve customers that would have basically infrastructures that will have wouldn't have really this in the tens of millions of open-boons at a time.
• 12:39
  [SPEAKER_02]: That was our goal, from the very beginning.
• 12:43
  [SPEAKER_02]: So we knew that we've built it for that scale, pretty much everyone would fall at that category.
• 12:48
  [SPEAKER_02]: So that scale that we've been building.
• 12:51
  [SPEAKER_02]: And what this has meant on our side is that there's a lot of data that we ingest.
• 12:56
  [SPEAKER_02]: So we need to have a very scalable and horizontal and scalable data pipeline for summation engine.
• 13:02
  [SPEAKER_02]: And basically all of the data that the agent are going to be looking at.
• 13:06
  [SPEAKER_02]: Since we're going to be running in a certain scale, we cannot just be collecting the data as the agents are running because it's just going to be too much.
• 13:13
  [SPEAKER_02]: Too many API calls that we're going to be doing externally.
• 13:16
  [SPEAKER_02]: So we're going to be throttle very quickly.
• 13:18
  [SPEAKER_02]: So, for more side was always very big scale, like enterprise customers.
• 13:22
  [SPEAKER_02]: Because of that, we need to load the data upfront.
• 13:24
  [SPEAKER_02]: So we can really just make tons as we want that we don't have to be doing API calls.
• 13:29
  [SPEAKER_02]: And then on the agent side, that meant we need to be able to run thousands and thousands of concurrent agents for each one of our customers.
• 13:37
  [SPEAKER_02]: So those are some of the key metrics on our scale journey.
• 13:42
  [SPEAKER_02]: The way that we have, that we have basically driven this, was across across the, let's say, Detecture design, we always thought about how we're going to scale, how we're going to spam the architecture.
• 13:54
  [SPEAKER_02]: And at some key decision points where we saw that we might be hitting the limits in some area, then we tried to be ahead of the curve and then build sort of the next generation of that part of the architecture that we'll allow us to handle more and more.
• 14:08
  [SPEAKER_03]: Ok Santiago, as you step out on the balcony and you look across all that you've built thus far with maze in particular.
• 14:15
  [SPEAKER_03]: What do you most proud of?
• 14:17
  [SPEAKER_03]: That's a very good question.
• 14:19
  [SPEAKER_02]: So from the very beginning, we wanted to a side of solving this vulnerability management problem, we wanted to build like an underlying platform that we can reuse for many different use cases.
• 14:31
  [SPEAKER_02]: And I think that's one of the things that we've got to thoroughly write.
• 14:34
  [SPEAKER_02]: So the ability to ingest data is very generic.
• 14:38
  [SPEAKER_02]: So we can ingest almost any type of data.
• 14:40
  [SPEAKER_02]: And it's very scalable.
• 14:41
  [SPEAKER_02]: So that those picture decisions around ingestion of data
• 14:47
  [SPEAKER_02]: Even though they cost us quite a bit of effort at the beginning, I think they had paid very well.
• 14:52
  [SPEAKER_02]: And this same principle of adapting to different use cases, we just built it across the board.
• 14:56
  [SPEAKER_02]: In terms of how do we build our agents, how do we orchestrate our agents?
• 15:00
  [SPEAKER_02]: But do we evaluate our agents?
• 15:02
  [SPEAKER_02]: The design of generic ways of doing it for... for any type of agent?
• 15:06
  [SPEAKER_02]: So then, standing up in your engine that does a new completely different function, looking at completing new data sets is fairly straightforward, and just beginning very, very opinionated on that.
• 15:16
  [SPEAKER_02]: I'm having a really high bar into how do we want that to be working from the very beginning.
• 15:21
  [SPEAKER_02]: Looking back has paid very good dividends on our for our company with.
• 15:29
  [SPEAKER_03]: Let's flip the script a little bit, tell me about a mistake you made, and how you and your team responded to it.
• 15:35
  [SPEAKER_02]: One of the early mistakes that we did was, so one of the early prototypes that we had, we made the, let's say, the agentic decision engine.
• 15:45
  [SPEAKER_02]: We made it a multi-agent system, so we basically had multiple agents discussing with each other and then reasoned in through the auto.
• 15:54
  [SPEAKER_02]: It was very good in some ways, so it basically helped us see the depth of reasoning that they can achieve basically different type of elements.
• 16:03
  [SPEAKER_02]: But one of the things that we didn't realize early on was the cost that encouraged.
• 16:09
  [SPEAKER_02]: Later on, and he was proven, and by now, and I think in for a lot of application is proven that the single-aging cut achieved the same reasoning.
• 16:15
  [SPEAKER_02]: Levels later down the line would we end up doing was moving towards a single agent or
• 16:21
  [SPEAKER_02]: Basically agents that have expertise in different areas, and then it's more driven by a single agent, but consulting other experts in the way is necessary.
• 16:29
  [SPEAKER_02]: So that was the next iteration.
• 16:30
  [SPEAKER_02]: Now we have many iterations down the line, but I think the lesson there will learn it pretty quickly, and then we went back and started iterating into how can we simplify it, how can we move it into a single agent.
• 16:41
  [SPEAKER_02]: It was a challenging solution because we also had to do a migration of basically the framework that we were using for building the agents.
• 16:50
  [SPEAKER_02]: So we're using out the gem back then.
• 16:52
  [SPEAKER_02]: From I was an episode for Microsoft and then later on we ended up moving to land graph.
• 16:57
  [SPEAKER_02]: So it was like two migrations in one in a way.
• 17:01
  [SPEAKER_02]: But yeah, the thing was very up for the task
• 17:08
  [SPEAKER_02]: So, once we migrated to the New York architecture, it was very clear how the new version was much better, and I actually could get us much farther than I had.
• 17:21
  [SPEAKER_03]: Let's move into the future.
• 17:22
  [SPEAKER_03]: This will be exciting.
• 17:23
  [SPEAKER_03]: The industry is changing rapidly.
• 17:26
  [SPEAKER_03]: Every day, what is the future for Mays, for the product, for the company, for your team, all the things?
• 17:33
  [SPEAKER_02]: Yeah, so we are, we're growing, we have right now three products out.
• 17:37
  [SPEAKER_02]: So one is focused on Cloud Navities, one is focus on SEA, and one on Sust on Navities.
• 17:43
  [SPEAKER_02]: So the feature from our perspective is basically continue to grow this product to more use cases, to more diverse environments, to bigger and bigger customers.
• 17:53
  [SPEAKER_02]: To customers having different technology combinations in terms of the parameter which is to use the clouds they use, how do they deploy, how do they orchestrate, or how do they run containers and so on.
• 18:02
  [SPEAKER_02]: So there's many different technology flavors that are out there that we want to make sure that we cover all of them.
• 18:08
  [SPEAKER_02]: I think it's, in terms of the industry, I find it actually quite interesting how cybersecurity is changing, so if I look back two years, so it's good it has fundamentally changed thanks to other limbs and I feel we're not there at the end of the transformations I think we're still going to go through more and more transformations in the next few years.
• 18:27
  [SPEAKER_02]: So, I'm quite excited about the future.
• 18:28
  [SPEAKER_02]: They decide a couple of days of the frontier model are proving extremely capable, which is very dangerous on the one side, but if used for defending and to prizes, or companies in general, could be actually transformational to how to execute these done going forward.
• 18:45
  [SPEAKER_02]: So, I'm talking about self-kill and systems, auto-remediation agents that are just monitoring and just acting on behalf of humans.
• 18:53
  [SPEAKER_02]: So I think we still have quite a few years of transformation based on the rapid development and improvement of elements, and I'm very excited about it and looking after all of these trends that they are coming up and seeing how we can integrating into our products.
• 19:08
  [SPEAKER_03]: Let's wish you use Santiago who influences the way that you were.
• 19:11
  [SPEAKER_03]: The more person or many persons or something you look up to and why.
• 19:16
  [SPEAKER_02]: I follow it quite a lot of people, but I think one of the things that drives, it has gotten a lot of influence on how I work is basically using a first principle approach to a lot of the problems.
• 19:28
  [SPEAKER_02]: So just get into the root of the problem and I see these from many different people.
• 19:32
  [SPEAKER_02]: So the permitting engineers want to build that very often.
• 19:36
  [SPEAKER_02]: And I think this approach, not just for engineering, but also for business and for product, is interesting just getting to the absence of the problems.
• 19:43
  [SPEAKER_02]: I like you follow Naval, David Hunt, it's an investor and VC, but also all he has a lot of this philosophy here simplicity and just getting to the truth, but you do the true course of problems.
• 19:55
  [SPEAKER_02]: Yeah, those are some of the peoples that I follow.
• 19:58
  [SPEAKER_03]: Okay, last question, so you're getting on a plane, and you're sitting next to a young entrepreneur who's built the next big thing.
• 20:05
  [SPEAKER_03]: They're jazz about it.
• 20:06
  [SPEAKER_03]: They can't wait to show it off to the world and can't we show it off to you right there on a plane?
• 20:10
  [SPEAKER_03]: What advice do you give that person having gone down this road a bit?
• 20:14
  [SPEAKER_02]: The piece of advice that I would give is that do not listen to the common knowledge that is out there about how creating a company or running a business or getting investment works.
• 20:25
  [SPEAKER_02]: There's a lot of discussion online about how a founder should do things.
• 20:30
  [SPEAKER_02]: And I think in general what I found is that if you fundamentally have a good way of doing something that is very different to how everyone does it But it's well-founded, well thought through and has you have the good reasons for it like good novel reasons meaning for the best of the business for the best of the company for the best of the product that you're developing
• 20:48
  [SPEAKER_02]: What I found is that there's a lot of flexibility out there into how you run your business You just need to ask for it and actually have good reasons for doing so.
• 20:57
  [SPEAKER_02]: I give you just a very simple example As I mentioned, I have three kids compensation for founders of how basically you run a company
• 21:04
  [SPEAKER_02]: For someone with three kids is thinkable.
• 21:07
  [SPEAKER_02]: It's impossible.
• 21:07
  [SPEAKER_02]: You need to work a hundred hours a week You will need to live on a 50,000 yearly thousand dollar yearly salary But actually this is for it kind of kind of be far to the financials If you have reasons for how you want to run the business and how you want it to work Just need to bring them up and there's a lot of understandings out there
• 21:24
  [SPEAKER_03]: for you to run the business into weight that is right for you.
• 21:27
  [SPEAKER_03]: That's fantastic advice, Santiago.
• 21:29
  [SPEAKER_03]: Thank you for being on the show today, and thank you for telling the creation story of Maze.
• 21:34
  [SPEAKER_03]: Thank you very much for having me.
• 21:37
  [SPEAKER_03]: And this concludes another chapter of Code Story.
• 21:47
  [SPEAKER_03]: code story is hosted and produced by Noah Labhart.
• 21:50
  [SPEAKER_03]: Be sure to subscribe on Apple podcast, Spotify, or the podcasting app at your choice.
• 21:55
  [SPEAKER_03]: And when you get a chance, leave us a review.
• 21:58
  [SPEAKER_03]: Both things help us out tremendously.
• 22:03
  [SPEAKER_03]: And thanks again for listening.