How Dam Secure Puts Guardrails on AI Generated Code

00:00 Trailer
01:01 Chainguard ad
01:28 Meet Patrick Collins and Simon Harloff from Dam Secure
03:00 Why existing AppSec tooling never worked for developers
05:30 The artisanal vs factory model of software development
08:30 Hacker News, polarisation and the AI sentiment shift
11:00 Agile, standups and processes that no longer make sense
14:00 Bigger PRs, higher velocity and workflows without an IDE
17:00 Skills, agents.md and the limits of deterministic guardrails
20:00 The AppSec to developer ratio problem
23:00 The SaaSpocalypse and why rebuilding tools is a side quest
27:00 React, digital certificates and security through business incentives
30:00 How Dam Secure works: secure spec and plan time enforcement
34:00 Vibe coders, Lovable and the risk beyond professional developers
36:00 Where to find Dam Secure and closing remarks

Simon Harloff:
You know, we’ve all talked about the SaaS-pocalypse, but it’s a bit paradoxical because if 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 going to be hyped for the next three to six months and then people will realize, “Well, actually I’m running a side quest when everyone’s concentrating on their main quest.”

Patrick Collins:
This idea around SaaSpocalypse, that all of a sudden I can build my own CRM, what are people talking about?

Cole Cornford:
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 CV reduction report at day1.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 and Simon. How you guys going?

Patrick Collins:
Good. How are you, Cole?

Cole Cornford:
It’s been an interesting day. Had breakfast up at Newcastle really early in the morning and I ate Moroccan eggs.

Patrick Collins:
Okay.

Simon Harloff:
Moroccan eggs. How would you describe those?

Cole Cornford:
Look, I feel like anytime we do fusion Australian culture, it’s just completely ruining whatever the original food was. So I’m just going to say it’s a bunch of nuts and avocado on eggs.

Patrick Collins:
Smashed avo. Smashed Avo just with a Moroccan tint.

Simon Harloff:
Smashed avo with a couple of nuts sprinkled on.

Cole Cornford:
See, that’s not going away, us making decisions about other things’ cultures. But it is homogenizing a bit because of artificial intelligence, right? 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 any guardrails in place to make it secure. So did you guys want to just talk a bit about why I brought you onto the podcast and what kind of problem you’re solving for my listeners?

Patrick Collins:
I don’t know why you brought me onto the podcast, Cole, but I’ll take a swipe at it.

Cole Cornford:
Oh, I just thought that you’re both handsome. So I just like bringing handsome men and ladies on my podcast so I can put them on YouTube.

Simon Harloff:
Patrick sent me a link and I said, “All right, I’m coming on.”

Cole Cornford:
I like it.

Patrick Collins:
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, Cole and I were talking even back then. I’ve been in AppSec now for 10 years, sometimes on the vendor side, sometimes as CISO, but always have found in my time that devs do care about cybersecurity. Not all of them. I’d say 70% of them care about cybersecurity and 20% of them 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 this industry around AppSec where they’re kind of putting it into various tooling and trying to stay out of the developer’s way. And Simon and my insight was just like, “This is not right. If 70% of developers actually do care about cyber and there’s no tooling for them, there’s an opportunity there.” And so that’s where Dam Secure started. And yes, it was triggered by us seeing a shift and 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.

Cole Cornford:
It’s the ultimate shift left really, isn’t it? Because making the developers produce secure code so you never need to identify, interrogate, fix it or 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 are 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.

Simon Harloff:
Well, I mean, I think particularly what’s been interesting to me is this shift of almost like your CICD 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 eight-hour coding session and it’s built this really big faulty tower of logic, it’s too late. You’ve burned a bunch of tokens, you’ve waited eight 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 six months.

Cole Cornford:
Oh, I don’t even know what to do anymore. 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, well, I guess this is it.” So …

Patrick Collins:
What’s the orange website?

Cole Cornford:
No, can’t say it.

Patrick Collins:
I don’t even know what you’re referring to.

Cole Cornford:
Oh, really? Okay.

Simon Harloff:
I think you’re talking about Claude. I thought … Claude’s website is a bit orange. Are you talking about Claude?

Cole Cornford:
Nah, no.

Patrick Collins:
No, we promised we were not going to make any political comments, and so …

Cole Cornford:
No, there’s no political comments here. No, it’s just Hacker News, so …

Simon Harloff:
Oh yeah, yeah, okay.

Patrick Collins:
Oh!

Simon Harloff:
It’s Hacker News.

Patrick Collins:
Oh, that’s not political.

Cole Cornford:
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 [inaudible 00:06:11] AI.”

Patrick Collins:
You know, talking about Hacker News, it’s always fascinating to me to watch the polarization in hacker news. You’ve got the principal engineering types who are like, “This is terrible. It’s destroying the craft of engineering.” And I even see people in the comment 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 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 comment section on the daily. But what I would say is that until four 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 and I think I’ve seen the shift occur. And you’re also seeing it play out in the open source community as well. So you see 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.

Cole Cornford:
I think a lot of engineers, the principles are probably the people working at big tech for a number of years and they’ve already made their money, and so they can go retire to their cattle ranches or to 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.

Patrick Collins:
I think it’s partly that. Yeah, I think it’s partly that. I think there’s also … And some people do engineering because of 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 going to walk out and I’m going to buy a piece of Ikea because I don’t want to pay $10,000 on a piece of Japanese woodworking. I need a functional piece of furniture. And 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.

Cole Cornford:
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 it’s funny you say the Japanese woodworking model. I actually used a very similar approach. I said there’s a difference between artisanal versus factory, and I referred to sourdough at Kohl’s and Woolies. So you can go to Kohl’s 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 two or $3 on a small sourdough bread, but 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 chunky sourdough cube or whatever they’re doing. So I still think there’s a lot of value and room for those 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 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 I think there’s room for both.

Simon Harloff:
Yeah, definitely. I mean, it’s also just interesting to see people … I mean, we feel this when we do engineering is the shift of like, “Well, do you do bigger pull requests? Do you do lots of smaller pull requests?” Even just the tooling around what developers are using, you know, something like GitHub, we are 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 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 your whole life?” You know, how hard do you review every line of code? I don’t know whether you saw, but there was a massive debate amongst the Linux maintainers about like, “Do I declare whether something was AI assisted or not?”, and then something slipped through the gates and they’re like, “Oh, if I’d known that it was AI assisted, I would’ve reviewed it harder.” And I think most organizations we are speaking to are already kind of past that in the sense that-

Patrick Collins:
Way past that. Yeah, this is …

Simon Harloff:
Yeah. So I just …

Patrick Collins:
The ship has proverbially sailed.

Simon Harloff:
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.

Cole Cornford:
And I think there’s just such a different … Like we have to go back and look at what we’ve traditionally done and say that all of those kind of approaches that we’ve built our 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.” Like one I’m grasping with at the moment is just agile software development, where the intention was T-skilled people and having different release trains, and then having rituals to help communicate and 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 have AI giving you almost instant status updates? Do you need to have different release trains when you can actually be setting out different agents with like harnesses to solve specific types of challenges? Like do you need to be having a backlog and grooming issues when, you know, by 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.

Simon Harloff:
I mean, there’s also a calibration that has to happen with a lot of these processes, because I think you take a four or five person engineering team and they used to be able to get their arms around a surface area that was A big and now it’s Ax3 big. So what does that mean, you know? I know I have one team that can do more. And so, yeah, I think it’s a real challenge in terms of orchestrating those bigger release trains like you would have in Scaled Agile, for example. I think it’s tricky.

Patrick Collins:
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 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, even conventional practices of reviewing a pull request, you know, we’re all working within those constraints, but also somewhat rubber-stamping reviews and … I’m not talking about us. I mean, we’re talking about the way we’re seeing [inaudible 00:15:25]-

Cole Cornford:
Oh, you’re just talking about me. That’s all I do. I just rub a stamp on it.

Patrick Collins:
I’m talking about you, Cole.

Cole Cornford:
[inaudible 00:15:30].

Patrick Collins:
I was looking at your code. I’m like, “Okay. All right. I see.”

Simon Harloff:
So, sorry, Cole. You did a code review of this app. What was it? 99% AI generated. Cool. Thumps up. Sounds good. Trust Anthropic. It’ll be fine.

Patrick Collins:
I know there’s some different companies working on even newer versions, like different varieties of GitHub, for instance, trying to reimagine what the software development life cycle’s 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 five years. So we’ll see.

Cole Cornford:
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 I think that it’s going to stick around for a while because it’s the community around GitHub that’s there. So that’s hard to replicate with AI agents the same as it’s hard to replicate Reddit and it’s hard to replicate Hacker News, right? 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?”

Patrick Collins:
Yeah. That’s a really good point. It is a marketplace as well at the end of the day.

Cole Cornford:
I hate marketplace businesses. They’re too bloody hard. I would never do it. It’s impossible.

Simon Harloff:
They’re very sticky though to your point. So yeah. I was going to add just for us, for instance, as we’re building our platform, we’ve got some pieces of work that start in a linear ticket, get pushed out to a Cursor cloud environment or a Claude cloud environment, get built, tested, and then we go through a review cycle. And then that instance, no one’s opening any ID at all, and I just think that’s really interesting. And we’ve spoken to a heap of other customers that are starting to adopt similar ways of working. And so for me, it’s like you had all this tooling that was developer facing. It’s actually now really becoming agent facing. And so …

Patrick Collins:
Too much reliance on skills though, don’t you think, Simon? Like what we’re noticing is 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 … I mean, you should explain what skills are, Simon, and some of the work we’ve been doing there.

Simon Harloff:
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 are probably believing that they’re just sort of running in the background and, “I don’t have to do anything.” Whereas it’s not quite working that way when we do some of our internal benchmarking, for example. And the end result is that when you go to do … And we see companies play around with this, you know, trying to build their own kind of security review skills; 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 quite intentional about how you build out these workflows.

Cole Cornford:
I think we’re actually in a kind of great place for product security, app security, or … I guess all of those roles, even just normal corporate security, are going to converge into just security and AI is going to be part of it. Like we don’t have agile software developers, we just have developers, right? So it’ll probably be the same for 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 we are now, where A, most of the businesses that we interact with, the power is concentrated typically within developers when we’re in the product security sphere. And so that means that … And developers are usually subservient to the CTO, CIO kind of value chain of the business, and they’re quite rarely directly in charge of revenue. And so most of the decisions are kind of made of a lens of whatever the product wants, which usually security is an afterthought and not really the important thing to do. And so that 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 they had is that typically AppSec people, you have like one or two per hundred developers, and that’s insane because how are you supposed to have one 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, DaaS, RAS bias, SEA, all of these things as agentic workflows, and then they can just focus on FRET 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. So …

Patrick Collins:
Yeah, we were talking to a company this morning that had one AppSec person per 800 developers, so …

Cole Cornford:
That’s very common, man. Very common.

Patrick Collins:
One to a hundred seems like a dream scenario. That’s normal. Like one in a hundred 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 were talking about DevRel? Absolutely. That’s why Dam Secure exists. So it’s like, “Well, okay, jamming tooling from the AppSec team across [inaudible 00:21:55] 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 that tooling was generally pretty bad. I mean, I don’t know a single developer that willingly uses that tooling. And even if they did, it was 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. Let’s 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 agentically 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 as AppSec pros where [inaudible 00:23:14] one in three people who 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.

Cole Cornford:
It’s interesting that the biggest leaps and bounds that we made in security over the last two 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 front end architectures being distinct from backend, and then them introducing standardized output and coding by default. That’s what React was. It was created because Facebook just had continuous, constant cross-side scripting issues, and then the broader industry started using React and then suddenly cross-site scripting is largely eradicated. Like it’ll still come up, but it’s not because we’ve gone out and told every developer, “You should use contextualized output and coding. Use static analysis to look for things, use a WAF to block XSS payloads.” No, it’s because React is there. And you can say the same thing about digital certificates. When Google Chrome 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 were like, “Wow, there’s actual revenue at risk and operational outages. So we now need to introduce digital certificates.” But prior to that, 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. So …

Patrick Collins:
Yep.

Simon Harloff:
Yeah-

Cole Cornford:
A lot to cover there.

Simon Harloff:
Yeah. No, no, no. 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 three to six months is every team is kind of … You know, we’ve all talked about the SaaSpocalypse. And I think it’s a bit paradoxical because if 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 building your own Salesforce internally, I think that’s going to be hyped for the next three to six months and then people will realize, “Well, actually I’m running a side quest when everyone’s concentrating on their main quest.”

Patrick Collins:
100%. I mean, this idea around SaaSpocalypse 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 rolling their own security tooling, and I’m like, “Maybe.” Maybe in the near term, but in the medium term, again, it’s just 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 four times greater than their capacity. So even if you’ve 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 bucks and get it over with.

Simon Harloff:
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.

Patrick Collins:
That’s it. That’s the extent of your, “I’m going to build my own SaaS tooling” is you built a Pomodoro timer.

Cole Cornford:
Get your tomato timer, mate. So …

Simon Harloff:
That’s right. Yeah. Keeps me on track. It keeps me on track.

Cole Cornford:
I need self-discipline like that. I’m horrible with it. But yeah, I have to say, I fully agree. I am … Previously, a lot of people in AppSec companies or 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 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 three months later they say, “I’ve got a job at Canva. I’ll see you guys later.”

Patrick Collins:
Yeah, they leave it for the next person to manage.

Cole Cornford:
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 and just bought it.” So … The other thing that also irritates me is just like, yeah, we’re a tech bubble. Techies. We’re just techies. Like I go speak to my neighbors who work in 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 their biggest interaction with it is asking Copilot for help writing an email or having fun making Nano 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 that … And we forget that because that’s what our day-to-day lives actually are, is like 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.

Patrick Collins:
My wife asks me on the daily, “How much do I trust your mate Claude?”

Simon Harloff:
I would say he’s a pretty good mate. Well, he or she. Yeah. I don’t …

Patrick Collins:
I don’t know. I don’t know. I think Claude butters me up a lot. Claude makes-

Simon Harloff:
You’re absolutely right.

Patrick Collins:
Claude makes-

Simon Harloff:
I would say you’re absolutely right. Yeah.

Patrick Collins:
Claude makes me feel good. I don’t know how right he is.

Cole Cornford:
So going back to the AppSec use case, how does Dam Secure help solve those problems that primitive SaaS tools or primitive SCA tools that just bury [inaudible 00:30:04] of vulnerability? So what’s Dam Secure’s secret sauce? What do they do?

Patrick Collins:
Our product’s quite straightforward to describe. You define your enterprise rules in plain English language straight into Dam Secure’s product. An example of a rule might be we always use Datadog for logging or we only use Google Secret Manager to store our secrets. So that’s an example of some rules, and then we enforce those rules. But what’s important is that most people think about enforcing rules like that 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 CICD, after the 7,000 lines of code has been generated, the developer has poured 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 life cycle. 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 Winserve. Pick your tool. And I’ll give you a worked example. So you’re working in plan mode with Claude and you say, “Hey, develop me an API that enumerates these different objects in the database and spits them out.” 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, then 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. 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 secure spec, the ability to modify a spec in real time. At that point, no code’s been generated. We’re in design mode. So some people have called us a secure by design solution. You define what your organizational standards are with rules and we whisper that right in at plan time. That’s one use case, but 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 I think everyone knows the LLMs, they’re like genius level interns 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, or the agents.mdfile. And it works to an extent, it’s just not very deterministic. And so we bring the deterministic element to it.

Cole Cornford:
That’s really cool. I like that you’re preventing. It reminds me of … Like one of the more effective things that I like to teach is the concept of security requirements, and basically mandating checklists to review those as part of product ownership and planning rather than having to come in and retrofit them with SaaS or other tools. But you’re basically automating that process by enforcing security requirements given to the agents and making sure that they’re doing that. So that’s really cool.

Patrick Collins:
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 quite a lot of value in putting security tooling around those tools.

Simon Harloff:
Well, one of the other things that we do right at the beginning, because what we’ve found with even traditional SaaS vendors is there’s quite a lot of default rules. But if you are a smaller 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 mono repos down into smaller projects, and then we basically go, “Well, what should you be caring about from a risk and a 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 a token minting service on its own. And so that’s where we feel LLMs can fall down when they’re just the naked intern, so to speak, walking in.

Patrick Collins:
The naked intern.

Cole Cornford:
That’s it. It’s just 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, “We’ve already got one. Why aren’t you using it? What’s going on there?”

Patrick Collins:
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 to generate a JWT token. I’ll build my own library,” and it’ll just build something. So it’s a pretty common problem and you can’t put guardrails around it.

Cole Cornford:
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 the people be able to see you guys next? I know I saw your banner at CrikeyCon. Where’s the next Aussie con you’re going to be at?

Patrick Collins:
Next Aussie con? We’re all over the place. We’re looking for people to try the product. Please head to the website, join the wait list. We’ll let you in and would love to get your feedback on it. We’re in the final phases of launching the product and got some exciting brands using it. So that’s probably the best place to start. You’ll see us popping up at events all over the place over the next six months.

Cole Cornford:
And that’s Dam Secure, D-A-M Secure, right?

Simon Harloff:
That’s it. You got it. No N.

Patrick Collins:
Dam without the N. Think beaver-

Cole Cornford:
Not [inaudible 00:37:02].

Patrick Collins:
… [inaudible 00:37:03] frustration.

Simon Harloff:
You’ll also find us in Sydney. So if there’s some Sydneysiders listening, 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.

Cole Cornford:
Great. Thanks guys for coming on, and I hope everyone enjoyed this episode.

Simon Harloff:
Thanks for having us.

Patrick Collins:
Thanks, Cole. Thanks for having us.

Cole Cornford:
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 Galah Cyber can help keep your business secured, go to galahcyber.com. au.