Transcript Synced · select any line to jump ▾ 0:00 Cole Cornford: You know, we've all talked about the SaaSpocalypse. It's a bit paradoxical because if, you know, everyone can go faster and you think the right way to spend that speed gain is by, I don't know, rebuilding security tools, for example, I think that's gonna be like hype for the next, you know, 3 to 6 months. And then people will realize, well, actually I'm running a side quest when everyone's concentrating on their main quest. 0:23 Speaker B: This idea around SaaSpocalypse that all of a sudden I can build my own CRM, what are people talking about? 0:32 Speaker C: I'm Cole Cornford, founder and CEO of Galah Cyber, and you're listening to Secured, the podcast where I catch up with developers, security leaders, and innovators to talk about the real world of AppSec. Open source now powers over 90% of the software we build, but it's also where attackers increasingly strike. ChainGuard closes that trust gap with hardened, secure, production-ready open-source builds so teams can build faster, stay compliant, and eliminate risk. Get your free CVE reduction report at dayone.fm/chainguard and start shipping software with confidence. Hey everybody, welcome to another episode of Secured. Today I'm here with the founders of DAM Secure. Patrick Collins and Simon Harloff. Hey Patrick, I'm Simon. How you guys going? 1:29 Speaker B: Good. How are you, Carl? 1:30 Speaker C: It's a bit of an interesting day. I had breakfast up at Newcastle really early in the morning and I ate Moroccan eggs. 1:36 Cole Cornford: Okay, Moroccan eggs. What, how would you describe those? 1:41 Speaker C: Like, look, I'm, I feel like anytime we do like fusion Australian culture, it's just like completely ruining whatever the original food was. So I'm just going to say it's a bunch of nuts and avocado on eggs. 1:51 Speaker B: So smashed avo, smashed avo, just like with a Moroccan tint. 1:55 Cole Cornford: Smashed avo with a couple of nuts sprinkled on. 1:58 Speaker C: See, that's not going away. It's like us making decisions about other things, cultures, but it is homogenizing a bit because of artificial intelligence, right? So, which is kind of what DAM Secure is coming about with and trying to solve is the concept of people vibe coding, building applications and not really having guardrails in place to make it secure. So did you guys want to just talk a bit about you know, like why I brought you onto the podcast and what kind of problem you're solving for my listeners? 2:26 Speaker B: I don't know why you brought me onto the podcast, Cole, but I'll take a swipe at it. 2:30 Speaker C: Oh, I just thought that you're both handsome. So it's just, I just like bringing handsome men and ladies on my podcast so that we can put them on YouTube. 2:36 Cole Cornford: Patrick sent me a link and I said, all right, I've covered. 2:40 Speaker C: I like it. 2:42 Speaker B: In all seriousness, Cole and I have known each other for a couple years now. And from my time where I was an executive at Secure Code Warrior, we were, Cole and I were talking even back then. I've been in AppSec now for 10 years, sometimes on the vendor side, sometimes as the CISO, but always have found that in my time that devs do care about cybersecurity. Not all of them. I'd say 70% of them care about cybersecurity and 20% that really care about it. And there's a few that don't care. All of the cybersecurity tooling has been ditched, has historically been ditched by developers. None of it works for developers. So there's like this industry around AppSec where they're kind of putting it into various tooling, trying to stay out of the developer's way. And Simon at Mindsight was just like, this is not right. If 70% of developers actually do care about cyber and there's no tooling for them, it's like there's an opportunity there. And so that's where DAMSecure started. And yes, it was triggered by us seeing a shift in a trend occurring with AI and how AI could support developers to care more about security and kind of get into their environment and help them out. I don't want to use the words shift left, but if we were to use the words shift left, I guess it would be more like that. 4:04 Speaker C: It's the ultimate shift left really, isn't it? So, because like making the developers produce secure code so you never need to like identify, interrogate, fix it, or like look at it in production in response to a breach is like what the whole concept of shift left was back in the day. I mean, it's been fairly debunked nowadays because of the pace of software development. Like, if people are writing code and deploying it within minutes or days, then the benefits of trying to fix things earlier disappearing. But I think that that's changing, going back again to the original model because of the way that we're redesigning and reshaping how we even do software development at all. Yeah. 4:48 Cole Cornford: Well, I mean, I think particularly what's been interesting to me is this shift of obvious, like your CI/CD pipeline needs to really be on your laptop almost for you to be able to do agentic engineering at scale. Because I think by the time you're through an 8-hour coding session and it's built this really big faulty tower of logic, it's too late. You've burnt a bunch of tokens. You've, you know, waited 8 hours for a feedback cycle to close to get the feedback way too late. So, yeah, it's certainly been interesting watching the space even just evolve in the last 6 months. 5:25 Speaker C: Oh, it's like, I don't even know what to do anymore. Like, I feel like every day I open up the Orange website and have a look at it and then just something fundamentally has changed and I just have to be like, oh, I guess this is it. 5:37 Speaker B: What's the Orange website? 5:39 Speaker C: No, can't say it. 5:41 Speaker B: I don't even know what you're referring to. 5:44 Speaker C: Oh really? Okay. I think you're talking about Claude Claude? 5:46 Cole Cornford: I thought Claude's website is a bit orange. Are you talking about Claude? 5:51 Speaker C: No, no. 5:51 Speaker B: No, we promised we were not going to make any political comments. And so— 5:56 Speaker C: No, there's no political comments here. No, it's just Hacker News. 5:59 Cole Cornford: So— Oh yeah. 6:00 Speaker B: Okay. Oh, Hacker News. Oh, that's not political. 6:03 Speaker C: It's not political. No, it's like everyone goes there and you look at the first 20 links and like 98% of them are just like, I've AI'd with something to AI the AI. 6:11 Speaker B: You know, talking about Hacker News, it's always fascinating to me to watch polarization in Hacker News. You've got the principal engineering types who are like, this is terrible, you know, it's destroying the craft of engineering. And there's, I even see people in the comments section saying, I'm quitting engineering, that's it, I'm done. And then you get the other polar extreme where we're talking about all the amazing things that can be done with AI. So I think if on any particular day, if you visit Hacker News and read the comments, you see the split and polarization of engineering and how they're feeling about AI. Playing out in the comments section on the daily. But what I would say is that until 4 months ago, it was predominantly negative, and then it shifted around the time Opus 4.6 came out. Claude got a lot better in November, uh, and I think I, I've seen the shift occur. And you're also seeing it play out in the open source community as well. So you see, you know, prominent figures on, you know, even on the Linux kernel kind of saying look, I think it's flipped. I think, yeah, there was a lot of slop and now we're getting these tickets that are genuinely real issues. Let's lean in and fix them. So it's amazing to see it play out in real time. 7:33 Speaker C: I think a lot of engineers who, the principals are probably the people working at big tech for a number of years and it's like, they've already made their money and so they can go retire to their like cattle ranches or to like whatever they do in their bloody spare time and just not really care about what happens to the rest of the industry. But the rest of us plebs, me and you and Simon included, we got to kind of accept that this is the new normal, to borrow a COVID term. 7:59 Speaker B: I think it's partly that. Yeah, I think it's partly that. I think there's also, some people do engineering because the love of the craft. It's like, and you've probably heard me talk about this before, Cole, like, I love Japanese woodworking, right? I watch YouTube videos on Japanese woodworking. I love the perfection in that craft, but then I'm gonna walk out and I'm gonna buy a piece of IKEA 'cause I don't wanna pay $10,000 on a piece of Japanese woodworking. I need a functional piece of furniture. And I think it's, I tell that analogy because it's a similar thing playing out in software engineering right now. There's the perfection in the craft that people have spent years honing how to be the best TypeScript developer and they're highly opinionated, or pick your language, Zig, if you want. And that's gone. That is over. Those days are gone. Now, we will all continue to watch those people perfect their craft, but they don't have a role in a modern enterprise anymore because the modern enterprise is the IKEA of software factory where we have to get this stuff out the door as fast as possible. And so we're watching that dichotomy play out and that kind of split of craftsmanship or craftspersonship versus the factory of software development in real time play out. 9:21 Speaker C: I know a few years ago, 2022, I think it was, I did a presentation at the Australian Parliament and that presentation was talking about how our modern services, like service delivery for software development needed to be moving more towards a big tech model because that's what consumers are expecting based on their interactions with Facebook and Snapchat and TikTok and Netflix and stuff at the time. And our services are quite antiquated in a lot of ways and we need to kind of move in that direction. And so like, it's funny you say the Japanese woodworking model. I actually used to quite a very similar approach. I said there's a difference between artisanal versus factory. And I referred to. sourdough at Coles and Woolies. So you can go to Coles and Woolies and spend $2 on sourdough, or you can go to a specialist bakery or make it yourself and it costs $20 to $30, right? And so yes, the vast majority of people are going to spend $2 or $3 on a small sourdough bread, but like there's going to be people who appreciate the craft and the quality and the story and narrative around having to get that really nice like chunky sourdough cube or whatever they're doing. So I still think there's a lot of value and room for those like— artisanal practitioners who are excellent at Ruby on Rails and understand it deeply. And honestly, those people are probably going to keep maintaining and extending and thinking of things that, like, the people who are used to working in a factory, they don't actually have the big picture and they can't actually understand how everything works together. So, like, I think there's room for both. 10:50 Cole Cornford: Yeah, definitely. I mean, it's also just interesting to see, like, people— I mean, we feel this when we do engineering is like, the shift of like, well, do you do bigger pull requests? Do you do lots of smaller pull requests? You know, even just like the tooling in around what developers are using, you know, something like GitHub, like we're finding like it's fine, but it's not fit for purpose if you want to stack 10 PRs on top of each other because you're going at such a rapid pace. And so I think, I think part of the friction is like, Also, it's genuinely hard to kind of reason about like, well, where do you fit into this stack as someone who's been coding yet your whole life? You know, how hard do you review every line of code? I don't know whether you saw, but like there was a massive debate amongst the Linux maintainers about like, do I declare whether something was AI-assisted or not? And you know, then something slipped through the gates and they're like, oh, if I'd known that it was AI-assisted, I would have reviewed it harder. And I think Like most organizations we're speaking to are already kind of like past that in the sense that— 12:00 Speaker C: Way past that. Yeah, this is— 12:03 Cole Cornford: Yeah, so I just— 12:04 Speaker B: The ship has proverbially sailed. 12:07 Cole Cornford: That's right. But everyone's trying to figure out how they can fit in and how they can make engineering work in this new world. 12:14 Speaker C: And I think this is such a different, like we have to go back and look at what we've traditionally done and say that like all of those kind of approaches that we've built that craft around like designing systems that work for humans we need to just take a step back and say, maybe we should be thinking about whether that's still appropriate. And like one I'm grasping with at the moment is just agile software development where every, the intention was, you know, T-skilled people and having different release trains and then having rituals to help communicate, understand customer requirements and so on. And I think a lot of those concepts and processes are going to be relatively obsolete because, you know, do you need to have daily standups about the tasks you've done when you could actually having, have AI giving you almost instant status updates Do you need to have different release trains when you can actually be sending out different agents with harnesses to solve specific types of challenges? Do you need to be having a backlog and grooming issues when talking about where things are on a Kanban board doesn't make much sense when the agent can own it end-to-end using a combination of skills? So I know that that can be deeply uncomfortable for a lot of people. I guess I'm just reveling in the chaos like Dionysus did back in the day. 13:27 Cole Cornford: I mean, there's also calibration that has to happen with all of these processes because I think, um, you take a 4 or 5 person engineering team and they used to be able to get their arms around, you know, a surface area that was a big and now it's, you know, a times 3 big. So what does that mean? You know, I know I have one team that can do more. Um, and so yeah, I, I think that's a, it's a real challenge in terms of orchestrating those bigger, you know, release trains like you would have in scaled agile, for example. I think there's a, it's tricky. 14:01 Speaker B: We've seen a lot of companies and how they're working with modern agentic, how they're trying to grapple with all of this tooling and it's changing very fast. What we're seeing is we're working with a lot of tech companies, especially mid-market moving fairly quick. And universally we're seeing As Simon was saying, much bigger PRs, much higher velocity of code, security teams saying, why am I reviewing this code that a human didn't review yet themselves? Like an AI has generated this and what does this mean for my security practices? We're seeing processes start and end in Jira. So, like it doesn't actually happen in an IDE, it goes from Jira straight out to a cloud agent and then back again. And to Simon's point and to your point, Cole, all of our known practices don't work with those loops that I just mentioned. The conventional practices of software development don't, even like conventional practices of reviewing a pull request. And, you know, we're all working within those constraints, but— but also somewhat rubber stamping reviews. And I'm not talking about us. I mean, we're talking about the way we're seeing— 15:24 Speaker C: Are you just talking about me? That's all I do. I just rubber stamp. 15:27 Speaker B: I'm talking about you, Cole. I was looking at your code. I'm like, okay, all right. I see. 15:33 Speaker C: Is this all right, Cole? You did a code review of this app. What was it? 99% AI generated. Cool. Thumbs up. Sounds good. Trust Anthropic. You'll be fine. 15:41 Speaker B: There's, I know there's some companies that are different, different companies working on even newer version, like different world. Different varieties of GitHub, for instance, trying to reimagine what the software development lifecycle is going to look like. If I was a betting man and I had to put some money down right now, I'm not betting on GitHub and I'm not betting on those models being the dominant models when you fast forward 5 years. So we'll see. 16:08 Speaker C: GitHub's interesting because the use case it has is like, yeah, it hosts Git,, and Git may not be the way to do source control anymore. There may be a new way to do source control that's better, but the prob— I think that it's going to stick around for a while because it's the community around GitHub that's there. So, um, that's hard to replicate with AI agents, the same as it's hard to replicate Reddit. It's hard to replicate Hacker News, right? Um, even though it's probably pretty easy to build a Reddit or Hacker News clone, it's how do we get humans or community members to go there? 16:42 Speaker B: Yep. It's a really good point. It is a marketplace as well at the end of the day. 16:46 Speaker C: I hate marketplace businesses. They're too bloody hard. I would never do it. It's impossible. 16:50 Cole Cornford: They're very sticky though, to your point. So yeah. I was going to add just like, just for us, for instance, like, as we're building our platform, you know, like we've got some pieces of work that start in a linear ticket, get pushed out to a cursor., you know, cloud environment or a Claude, you know, cloud environment get built, tested, and then we go through a review cycle. Um, and in that instance, no one's opening any IDE at all. Um, and I just think that's really interesting. And we've spoken to, um, a heap of other customers that are starting to adopt, you know, similar ways of working. And so, you know, for me, it's like You had all this tooling that was developer-facing. It's actually now really becoming agent-facing. And so— 17:43 Speaker B: Too much reliance on skills though, don't you think, Simon? Like what we are noticing is like an expectation and belief that skills will keep them on track. And certainly even we fall into this trap a little bit. Skills for those who don't, I mean, you should explain what skills are, Simon, and some of the work we've been doing there. 18:05 Cole Cornford: Yeah, I mean, I think hopefully everyone's starting to work with them, but I think the first bastion in Agentic was the idea of an agents.md file, and it would be context that always got picked up. And Skills is basically like context packaged up as a Markdown file that gets invoked if and when needed. And I think that's the tricky bit, the if and when needed. I think the way Skills are marketing themselves right now is people, you know, people are probably believing that they're just sort of running in the background and I don't have to do anything. Um, whereas, uh, it's not quite working, um, that way when we do some of our internal benchmarking, for example. And the end result is that, um, you know, when you go to do— yeah, and we see companies play around with this, you know, trying to build their own kind of security review skills. Um, you know, sometimes the skill doesn't get called on at all, which is a problem. And so you do need to be really careful, and I'd say, uh, quite intentional about how you build out these workflows. 19:16 Speaker C: I think it's— we're actually in a kind of great place for product security, app security, or I guess like all of those roles, or even just normal corporate security, going to converge into just security. And, you know, AI is going to be part of it. Like, we don't have Agile software developers, you just have developers, right? So it'll probably be the same security practitioners. But I'm pretty confident that as all of these different types of people understand, build harnesses, and then with those harnesses leverage the right skills, they're going to be in a very different situation than we are now where we, A, most of the businesses that we interact with the power is concentrated typically within developers more in the product security sphere. And so that means that developers are usually subservient to the CTO, CIO kind of value chain in the business, and they're quite rarely directly in charge of revenue. And so most of the decisions are kind of made with a lens of like whatever the product wants, which is usually security is an afterthought and not really the important thing to do. And so that power of— Yeah. Balance of power is really hard to push against when the developers have so much authority. And that's why a lot of companies invested heavily in DevRel teams back in the day, because they knew if they influenced the developers, then they'd be able to influence the overall direction of just what products and stuff they could sell to leadership in the future. And the other thing we had is that typically AppSec people, you'd have like 1 or 2 per 100 developers. And that's like insane, because like how are you supposed to have 1 person scale to that many individuals? And what I'm seeing now is it's kind of converging in the middle. Where your AppSec person now has the capability to do SaaS, RASP, SCA, all of these things as agentic workflows. And then they can just focus on, you know, threat modeling and human relationships and influencing corporate culture. Then the other way is that developers have significantly less power nowadays because they're getting automated and optimized and told that they're moving into agentic flows. And so I think it's a great spot to be where we are at the moment. 21:18 Speaker B: You were talking to a company this morning that had one AppSec person per 800 developers. So. 21:24 Speaker C: That's very common, man. Very common. 21:27 Speaker B: 1 to 100 seems like a dream scenario. That's normal. Like 1 in 100 is normal, candidly. I'm not saying it's ideal. I'm just saying it's normal. You must find that as well, Cole. And so then it just becomes like, well, how do we shift this into the developer environment? You're talking about DevRel. Absolutely. That's like, that's why DAM Security exists. So it's like, well, okay, jamming tooling from the AppSec team across onto engineers is not going to work. How do we create a developer experience that developers actually enjoy, that developers get value out of, and they don't feel that the friction is so high that they're going to rip it out of their environment the first moment, the first chance they get? And let's be clear, if we're looking back on the older tools from our prior generation, and we won't use that swear word SaaS, But like that tooling was like generally pretty bad. I mean, I don't know a single developer that willingly uses that tooling. And even if they did, that is extensive customization that had to be in the champion bucket to use that tooling. That's not an aspirational place for the industry to be. That's like, be clear, that's the absolute trough of disillusionment right there. So it's all upside from there. I think there's a huge opportunity with AI to secure the code that's being developed agentially directly out of whatever tooling it is, straight out of Claude or a tool like ours. I think it's a great time to your point. And I think that, as I said at the top of the call, I think 70% of developers do genuinely care about it. We've all had that experience of as AppSec pros, where the 1 in 3 people who are just, don't care and think it's a waste of time. And that's fine. Don't target them. Target the remaining 70% who do care. But it'll catch up in the long run. 23:25 Speaker C: It's interesting that the biggest leaps and bounds that we made in security over the last, like, 2 decades have been things that have helped businesses primarily, but then have had a security side effect. And so I'm thinking things like micro frontends or frontend architectures, like being distinct from backend. And then them introducing standardized output encoding by default. So they did, like, that's what React was. It was created because Facebook just had continuous, constant cross-site scripting issues. And then the broader industry started using React. And then suddenly cross-site scripting is, like, largely eradicated. Like, it'll still come up, but it's, you know, not because we've gone out and told every developer, you should use contextualized output encoding, use static analysis to look for things, use a WAF to block XSS payloads. No, it's because React is there. And like you say the same thing about digital certificates. When Google Chrome, like, started telling websites, hey, we're going to give a big red banner telling you, if you don't get a digital certificate, no one's going to buy from your website, that's when businesses are like, wow, there's actual, you know, revenue at risk and operational outages. So we now need to introduce digital certificates. But prior to that, like no business really took it seriously. So I think that when there is significant operational or financial impact to companies, then novel solutions that can help mitigate that but also have a security benefit are the ones that are widely employed. 24:55 Cole Cornford: So yeah, yeah. 24:56 Speaker C: A lot to cover there. 24:58 Cole Cornford: No, no, no, like you're right. I think primarily businesses are picking this up because they don't want to be left behind. And the reality is, and I think this is I expect this to be the case for the next 3 to 6 months, is every team is kind of, you know, we've all talked about the SaaSpocalypse, and I think it's a, it's a bit of a, it's a bit paradoxical because if, you know, everyone can go faster and you think the right way to spend that speed gain is by, I don't know, rebuilding security tools, for example, or, um, you know, building your own Salesforce internally, I, I think that's going to be like hype for the next, you know, 3 to 6 months. And then people will realize, well, actually I'm running a side quest when everyone's concentrating on their main quest. 25:43 Speaker B: 100%. I mean, this idea around SaaS-pocalypse that all of a sudden I can build my own CRM. What are people talking about? I don't know a single CIO who's sitting around twiddling their thumbs and has ample resources to say, boy, I don't want to pay $300 grand to Salesforce. I'm going to rebuild my own CRM. It's crazy talk. It's absolute crazy talk. And it's the same for security tooling as well. I see people, you know, rolling their own security tooling. And I'm like, mate, maybe, maybe in the near term, but it's in the medium term again, it's just, it's not going to be where people spend their time. People need to spend their time on their core business always. And I don't know a company that doesn't have a roadmap of functionality that needs to be built that's 4 times greater than their capacity. So even if, you know, you've twice, you doubled your output with the help of AI or even tripled it, you're still not keeping up with the amount of demand for software generation in your business. So the idea that you would take your precious development resources and rebuild tooling internally, except for the most trivial of cases. Like there are some SaaS tools we use that are truly trivial. Yeah, maybe in those instances, if it's a single-shot prompt, I might spend some time on it, but even then I've got to host it. Do I even really want to do that? Probably not. I'll pay the $30 and get it over with. 27:19 Cole Cornford: I've got my own Pomodoro timer. So, you know, I don't know, does that count? But I haven't gone much further than that, to be honest. 27:27 Speaker B: That's it. That's the extent of your, I'm going to build my own SaaS tooling, is you built a Pomodoro timer. 27:33 Speaker C: Get your tomato timer, mate. 27:35 Cole Cornford: So that's right. Yeah. Keeps me on track. It keeps me on track. 27:40 Speaker C: I need self-discipline like that. So I'm horrible with it. But yeah, I have to say, I fully agree. I am, like, previously a lot of people in AppSec companies, AppSec positions would not get access to the fancy tools. And the reason they wouldn't get access to the fancy tools is because they usually are pretty bad at building political capital and understanding a balance sheet and how to budget and ask and write a business case to get something in, right? Because they're engineers, they know tech, they don't understand enterprises and organizations and finances. And so they go with what's comfortable, which is munging together Docker and grep and fucking who knows what. And then what happens is they say, I built this really cool thing. And then 3 months later, they say, I got a job at Canva. I'll see you guys later. 28:23 Speaker B: They leave it for the next person to manage. 28:25 Speaker C: And then suddenly the fucking enterprise tool is gone and no one knows how to use it and have to deprecate it and go, that's when one of the smart AppSec people says, ah, shit, maybe we should have done a buy versus build approach, like, and just bought it. So the other thing that also irritates me is just, they're like, yeah, we're a tech bubble, but like techies, we're just techies. I go speak to my neighbors who work in like NDIS, or there's others who work as teachers. And the thing is that the vast majority of them give literally zero fucks about AI. They just know it's there and that their biggest interaction with it is asking Copilot for help writing an email or having fun making banana images. And then, yes, asking those people to architect, design, and maintain a system is so far removed from what they actually want to do in their day-to-day lives. And we forget that because that's what our day-to-day lives actually are, is thinking through problems and building processes and solutions to solve them. Whereas a teacher wants to teach students and a doctor wants to save patients. They don't want to fuck around with AI systems. 29:28 Speaker B: My wife asks me on the daily, how much do I trust your mate Claude? 29:35 Cole Cornford: I would say he's a pretty good mate. He or she. 29:38 Speaker B: Yeah. I don't know. I don't know. I think Claude, Claude butters me up a lot. 29:44 Speaker C: You're absolutely right. I would say you're absolutely right. 29:48 Speaker B: Claude makes me feel good. I don't know how right he is. 29:52 Speaker C: So going back to the AppSec use case, so how does DAMSecure help solve those problems that like primitive SaaS tools or like primitive SCA tools that just bury teams in vulnerability? So what's DAMSecure's secret sauce? What do they do? 30:07 Speaker B: Our product's quite straightforward to describe. You define your enterprise rules in plain English language straight into, you know, straight into DAMSecure's product. It's, you know, an example of a rule might be, we always use Datadog for logging, or we only use Google Secrets Manager to store our secrets. So that's an example of some rules. And then we enforce those rules. So, but what's important is that most people think about enforcing rules like that, like way late in the pipeline. Most people would think, if I'm going to enforce a rule, like all logging must be done with Datadog, they're going to do it right at the end at CI/CD, after the 7,000 lines of code has been generated, the developers pored over it with the agent, millions of tokens have been spent. and then right at the end in the PR go, oh, it's doing console.error outputs, it needs to go to Datadog, and then back through the software development lifecycle. And so instead, we try to catch that a little earlier. We try to catch it during planning phase and code generation phase, like right up front. So we hook into all the different developer environments, whether it's Claude or Cursor or, you know, windsurf, pick your tool. And I'll give you a, like a worked example. So you're working in plan mode with, with Claude and you say, hey, develop me an API that enumerates these different objects in the database and spits them out. And it, and Claude generates a plan for you and it pops out with a plan and says, I've generated a plan. We'll immediately hook onto that plan and assess what rules should be applied. And we'll whisper into Claude's ear and say, hey, you really should think about the fact that you've got rules that say that rate limiting should be applied here. 31:51 Speaker C: Yeah. 31:51 Speaker B: We should make sure that the way the auth has been designed, it needs to call this specific middleware, and a few other examples like that. And then we actually tell Claude to adjust the plan in real time as the plan's being developed. So, we call that SecureSpec, the ability to modify a spec in real time. At that point, no code's been generated. Like, we're in design mode. So, some people have called us a, you know, like, secure-by-design solution. You define what your organizational standards are with rules, and we— Yeah. We whisper that right in at plan time. That's one use case. The dominant use case that most people use us for is once the code's been generated, we check the code that's been generated, or we can do a full scan across the code base and look for patterns. We can find vulnerabilities as well, but the dominant use case is putting guardrails around AI and helping keep it on track. And it's— I think everyone knows that LLMs Like, they're like genius-level interns with their— on their first day on the job. They turn up and they're just absolutely incredible at generating code, but they know nothing about how you do things at your company. They don't know what tools you use. And that's where people overutilize skills and try to get skills to do all the agents.md file. And it works to an extent. It's just not very deterministic. And so we bring the deterministic element to it. 33:14 Speaker C: That's really cool. I like that you're preventing. It reminds me of one of the more effective things that I like to teach is the concept of security requirements and basically mandating checklists to review versus part of product ownership and planning rather than having to come in and retrofit them with SAST or other tools. But you're basically automating that process by enforcing security requirements. Like given to, you know, the agents and making sure that they're doing that. So that's really cool. 33:46 Speaker B: Yeah, I mean, a very practical use case of that is that we have one customer who is using Lovable extensively and Lovable's a little more on the Viber side than the professional developer side. We actually think for every one developer, traditional professional developer, there's 10 Vibers right now. And those 10 vibers, I think, are as much a risk to the broader industry as the single professional developer. And if they're using Replit or Lovable or any of these other tools and any of their code gets close to production, that's where we feel like there's really, like, quite a lot of value in putting security tooling around those tools. 34:30 Cole Cornford: One of the other things that we do right at the beginning, because we're like, what we found with, you know, even traditional SaaS vendors is there's quite a lot of like default rules. But if you are a small organization, you don't necessarily know what rules you should be applying. What do they even mean? So one of the key steps in the process that Patrick described is that we also analyze the repository and we onboard it. We look through it. We break big monorepos down into smaller projects. Yeah. And then we basically go, well, what should you be caring about from a kind of, from a risk and security point of view? And you basically get a, hey, here's our take on what security means for that repository. And that's actually really important because I think everyone knows what a SQL injection looks like, but to Patrick's earlier point, an LLM isn't going to know that you need to call this specific microservice here to mint a JWT token. It might just go and reinvent like a a token minting service on its own. And so that's where we feel, you know, LLMs can fall down when they're just a naked intern, so to speak, walking in. 35:41 Speaker B: The naked intern. 35:43 Speaker C: It's easier to generate than it is to learn. So I just feel like they'll go ahead and say, I'm going to make an input validation library because it's clear I need to validate input. And you'd be like, but we've already got one. Why are you using it? Like, what's going on there? 35:55 Speaker B: We've all had that experience with LLMs where it goes and a Genius intern, like it just goes and rebuilds something like, oh, I need, I need to generate a JWT token. I'll build my own library and it'll just build something. So it's a pretty, it's a pretty common problem and, and you can put guardrails around it. 36:14 Speaker C: Speaking of guardrails, unfortunately, that's all the time that we're going to be able to have today. Look, thank you so much, Patrick and Simon, for coming onto the pod. Where would people like be able to see you guys next. Um, I know I saw your banner at CrikeyCon. Uh, where's the next AussieCon you're going to be at? 36:27 Speaker B: Next AussieCon? Uh, we're all over the place. We're looking for people to try the product. Um, please head to the website, join the waitlist. Um, we're, you know, we'll let you in and we'd love to get your feedback on it. We're, we're in the final phases of launching the product and, um, got some exciting brands using it. So that's probably the best place to start. Uh, you'll, you'll see us popping up at events all over the place over the next 6 months. 36:51 Speaker C: And that's DAMsecure, D-A-Msecure, right? 36:56 Cole Cornford: That's it. You got it. 36:59 Speaker B: No, no N. DAM without the N. Think beaver, not frustration. 37:03 Cole Cornford: You'll also find us in Sydney. So if there's some Sydney-siders listening, you know, come and send us a message on LinkedIn. We're happy to have a coffee always and show you the product, show you the platform, get your feedback. 37:17 Speaker C: Thanks guys for coming on, and I hope everyone enjoyed this episode. 37:21 Cole Cornford: Thanks for having us. 37:22 Speaker B: Thanks, Cole. Thanks for having us. 37:26 Speaker C: Thanks a lot for listening to this episode of Secured. If you've got any feedback at all, feel free to hit us up and let us know. If you'd like to learn more about how Galar Cyber can help keep your business secured, go to galarcyber.com.au.
▶ 
▶ 
▶ 
▶ 
▶ 
▶ 
▶
▶
▶