Building Security Culture With Dustin Lehr

“Danny Allan: Do you see LLM usage, or AI usage having any impact on things like champions programs, or do you think, “No, this is truly a cultural phenomenon, not a technology phenomenon.”

“Dustin Lehr: I do you think, you know, technology can help with culture quite a bit and the company that I created, Katilyst, is sort of built around this concept as well. How do we automate a lot of this, how do we motivate individuals by reinforcing their actions and so forth, in a way that’s easy to manage, and as automated as possible? When it comes specifically to AI, let me just say this, that I do think when it comes to culture and building relationships and so forth, we’re still forever going to desire the human connection.”

[INTRODUCTION]

[0:00:50.7] ANNOUNCER: You are listening to The Secure Developer, where we speak to industry leaders and experts about the past, present, and future of DevSecOps and AI security. We aim to help you bring developers and security together to build secure applications while moving fast and having fun.

This podcast is brought to by Snyk. Snyk’s developer security platform helps developers build secure applications without slowing down. Snyk makes it easy to find and fix vulnerabilities in code, open-source dependencies containers, and infrastructure as code, all while providing actionable security insights, and administration capabilities. To learn more, visit snyk.io/tsd.

[INTERVIEW]

[0:01:30.9] Danny Allan: Hello and welcome to another episode of The Secure Developer. I’m Danny Allan, the CTO at Snyk Software, and I’m very excited to be with you today. I have an extremely special guest, which is Dustin Lehr. Dustin, welcome to the show, how are you?

[0:01:43.5] Dustin Lehr: Hey, great. Glad to be here, I’m excited for this.

[0:01:46.5] Danny Allan: Now, Dustin, I know that you have a tremendous background that spans everything from writing software to being an architect, to application security, to building security programs, so maybe we can start there. If you can just give a background of your experience in the industry.

[0:02:02.5] Dustin Lehr: Yeah, happy to share. So, like you mentioned, I did start as a software engineer, studied computer science in school, wrote a lot of code for over a decade, and got into sort of the app architect side as well. Always had a focus on quality, this was so much more than just, “Let’s just make this work and write the code that’s going to work.” I always had this attraction to, “How do we improve our process?”

“How do we build good high-quality software that included, you know, things like performance and maintainability?” And then security was just always part of that conversation. So, for me, it was a pretty natural move into cyber security, and then I was a tech leader at a couple of different companies now, Staples, Fivetran, and then I even started my own company around this space as well, and I’m sure we’ll get into that more but that’s a little bit of my background.

[0:02:55.0] Danny Allan: That’s fantastic. I started in the engineering space as well and moved over to security, and I always liked to think that security more is just an extension of quality, good quality practices with engineering, and it sounds like you would agree with that principle.

[0:03:11.3] Dustin Lehr: I would a hundred per cent agree, and I would actually add to that, in that, I think that, and I’ve been successful using security to drive quality initiatives. So, the way that I’ve thought about it is like, not, “Let’s just do security for security’s sake,” but a little bit more of, “How do we have, you know, high-quality engineering practices that security can help us get there?”

So, an example would be, “Okay, we want to implement a secure SCLC." Great. Well, first, we need an SDLC to do that, you know? So, how can we get everyone aligned on the importance and the benefit of having a consistent development process? In my view, is part of the path to implementing a secure SDLC, as an example. The other example would be inventory, you know, an asset inventory system.

This has come up a lot, very valuable for the security team. Also, very valuable for the engineering side too, to know what all is out there, what are all the services that we’ve created, where do they live, where are they deployed, who owns them, right? That’s a big piece, is who owns them. So, that’s another example I think of security sort of driving overall engineering quality.

[0:04:28.7] Danny Allan: Yeah, let’s put a pin in that because I think there are amazing parallels between the two but I guess I’m interested in how you see the engineering space evolving, first of all, over your career because quality used to be that you did it during – when you talk about SDLC, there used to be defining the SDLCs where you would design and then build, and then test and publish, and that whole model has changed drastically.

And I’m interested whether you think that’s for the good or for the bad, or neutral impact over the last 10 years because software development has changed.

[0:05:06.1] Dustin Lehr: It has. Yeah, I mean, one of the ways that I think it’s changed drastically is we have to think a little bit more about the infrastructure side, especially with cloud, you know, sort of rising into prominence to some degree because I do think developers are not just thinking, “Okay, let’s write this app and make this work. Who cares where it’s deployed?” It’s almost the first thing they think of, you know what I mean?

Like, think of a hobby project, right? It’s like, “Okay, let me just spin this up, you know, in AWS or something to get myself started.” But to go back to kind of what you're saying around, you know, what has changed over the years and has there been, you know, a bad change almost when it comes to the way that we deploy and build software today, I think it’s a bit of a tradeoff. You know, I think there’s a lot of good things that we’re doing, especially in the automation side.

I do very much believe in releasing quickly, and sort of shorter cycle times and you know, releasing daily ideally, as supposed to more of like a waterfall approach but I also think there are best practices that still need to be followed. It’s just maybe you do them a little bit quicker or in a little bit of a different way, right? So, instead of dragging out like an SDLC process across months, having that mostly all those steps still there but you know, doing them in the span of days instead, I still think makes a lot of sense.
So, I also think, you know, people are kind of looking for shortcuts in a lot of cases too, they’re, you know, like AI emerges in our own and it’s like, “Cool, I don’t have to write any more code, right? I’ll just have the bots do it for me.” For some reason, people latch on to that stuff and I don’t think that’s necessarily the right way to go about it. I think that these things can enhance our lives, you know, CICD, DevOps, DevSecOps.

But the fundamentals still need to be followed and the other thing that comes to mind to sort of demonstrate that is, you know, being proactive. In my view and with everything I’ve done, when it comes to, you know, focusing on tech debt and doing better designs and having sort of a quality focus upfront and so forth, I think saves you time in the long run, and I think that was true then and that is very much true now as well.

You know, you could easily deploy something maybe quicker, that is a bad architecture that will eventually bite you, and if you had just taken a little bit of time upfront to make sure that it was secure and all of that, you're going to save yourself time in the long run. So, those are some of my thoughts on that.

[0:07:53.7] Danny Allan: Yeah, it’s interesting, the way that you frame that, and I agree with you, there are things that are better. In other words, releasing faster but you can’t throw the baby out with the bath water. So, maybe it’s just a neutral, we continuously evolve, and change as we adopt new systems. I do agree with you, by the way, that we’re looking, we always look for ways to do things more effectively and faster.

Like, open source is a good example of this 20 years ago, open source wasn’t a thing. Now, it’s 80% of our software. Ten years ago, AI wasn’t a thing. Now, it’s writing a lot of our software. So, if we can make things easy for the engineer, presumably that’s a good thing in your books, is that right?

[0:08:36.4] Dustin Lehr: Yeah, I definitely think – and a lot of these just comes from my experience as a software engineer but software engineers are busy. They have a lot on their minds already, they have to think about so many things. So, whatever we can do to make it a little bit easier for them I think it’s important. I also think that the work that software engineers in terms of creating value for their companies, for a software company especially, is number one.
Like, whatever you can do to make your engineers more efficient is going to help your business overall, right? So, when it comes to a lot of the things that I see when I, you know, with security and requirements and all that stuff, I’m not sure there’s enough being done to really think about the developer experience. It’s a lot more of, in a lot of cases, the security experience. You know, how can the security meet their own goals?

And “Hey, devs just need to get on board with this.” Or “Why can’t developers just do more of this?” you know? And there’s a lack of empathy there and I really think that’s important to consider, you know, when you’re designing a security program.

[0:09:55.1] Danny Allan: Do you think, and I want to come back to the security program because I think that is a key point and I know you’ve been instrumental in building many of these programs. Do you think engineers though, have a fundamental interest in security or in the developing fast? If they were to prioritize those two things, would they put the better productivity, developing fast ahead of security, or, of course, the answer is, “It depends.” But in a generalized statement.

[0:10:23.5] Dustin Lehr: There is a spectrum there, of course, and I’ve certainly run across plenty of engineers where you know, they’ve just kind of want to get this done. They don’t care about the quality of the code base and so forth. I won’t name any names out there but I think the majority of us devs care about the quality of the code that they’re writing. I think any pressure to move quickly and so forth comes from their leadership.

You know, product, trying to make sure that they are providing value to the company, whatever other incentives are sort of being used, right? To increase their productivity, that’s where I think it comes from because I do think, in general, and I’d be curious to get your thoughts here too. I think, in general, engineers have a certain amount of pride around the code that they built, and that certainly comes with it, you know, a lot of a quality focus.

I actually have a thought here and sort of a call to action almost and that’s, you know, you’re product folks who are designing the features that you're implementing, they don’t necessarily know the impacts of what they’re asking. So, in my view, it’s your responsibility as an engineer, especially as an engineering leader, to provide that feedback, back to them and to give them, you know, estimates and so forth that have an emphasis on setting yourself up for success in the future, which means building quality, and from the beginning.

It can’t be a, “Yes sir, yes ma’am” type of thing. “Sure, I’ll get that done in a week because you asked me to.” I think it needs to be a little bit more of a, “Okay, well, yes, I could get that done in a week but it’s going to take this long, two weeks perhaps, to build it the right way, which will save us X amount of time in the future,” and so forth, and that’s the conversation I just love to have, I’d love to see more engineers having with their product folks.

[0:12:30.6] Danny Allan: I think it’s an important cultural discussion to have. I do agree with you, 95 plus per cent of the engineers that I speak with, and I’m a former engineer myself, I still write code, although I try not to, have pride in what they’re writing. They want to write good code, it’s the pressures of the business that are pushing them sometimes to go faster than they would even like as they’re writing the code.

I suppose it’s a bit like an artist, you can do it fast or you can do it well, and there’s a tradeoff between those two things, sometimes that happens. Do you think it is unreasonable? There’s been a movement, first of all, towards “shift left,” shift the quality analysis and the security analysis left of the production systems. In other words, give it to the developers. Do you think it’s reasonable to put that on engineering and development teams?

Do you think “shift left” is a thing or it’s not a thing, it’s going to go away? It was very hot a few years ago, it’s less hot now.

[0:13:30.0] Dustin Lehr: Boy, that’s a hot topic. This is going to be maybe a spicy conversation now. Yeah, shift left. I personally think that that term is used in a way that certainly I don’t intend to use it when it comes to building products around the concept, and I think you accurately defined it in terms of how a lot of people are thinking about it. Shift left to many is moving a lot of that work to the developer, and I don‘t buy that, okay?

So, when I talk about shift left, what I’m talking about is if you look at the SDLC traditionally, it’s putting focus on security best practices, earlier in the cycle, okay? So, instead of like, the very right side would be in production, you have controls, right? You have monitoring controls, and so forth. You are doing pen tests, you know, you’re sort of analyzing your production environment for issues. That’s the right side, okay?

Any of those best practices on the right I think are very important but I also think that it’s important to like we were talking about, be proactive and get ahead of those things by putting best practices more on the left side of the process doing design reviews, doing code reviews, doing scanning, pre-prod, and so forth. To me, that’s shifting left is just doing those practices. In my mind as well that doesn’t mean that the developers are doing it all.

It just means that you have best practices earlier in the cycle. Now, that could be a combination of ownership, right? Developers do some of that but the security team does some of that, and also really like, you know, we were talking about earlier, trying to find ways to make those left side activities easier for developers I think is a focus that we need to have.

[0:15:38.6] Danny Allan: Yeah, I always think of shift left as shifting the controls and the guard rails left, not the actual analysis itself, and then also shifting the awareness left, so that developers are aware of the things, the best practices as you put it, that they should do, and I know a major part of that has been around suggesting and building programs, like security champions programs, which you have very much been involved with.

How have you seen the emergence of champions programs and similar come into its own, and I’m interested in exploring what you think the best practices are around champions programs, maybe we’ll just start with have you seen them emerge in the last decade?

[0:16:18.9] Dustin Lehr: Yeah, I think what people are realizing is that we need to have some sort of ability to scale and also to induce what I would describe as sort of a culture change across a company. The way that I like to think about security champions is in terms of finding early allies or early adapters across your company. These are the folks who get it. You know, you’re trying to make a change.

Actually, let’s step back a second because I think a big realization for me, when it comes to cyber and AppSec is we’re in the business of change, okay? You show up as a new security leader, whatever, your job is not to sit idly by and offer a few pieces of advice and so forth. It’s literally, in my view, to help the dev process improve, okay? Quality or otherwise, and that means change.

That means people will have to change, your process has to change and so forth. Now, when it comes to change, I think that what you’ll find when you start down this journey is some people are going to get it, some people are going to be grateful for you. You know, “Hey, I’m glad you’re here, I’ve been talking to people about AppSec and the importance of it and so forth, how can I help? How can I get involved?” Right?

In my view, those are your champions, those are your initial allies that you should work more closely with, who can become a voice for the change you’re trying to make beyond just yourself, and I think that’s very important because it’s different when the security team says something, like, we’re so easy to ignore. I don’t want to offend anyone here but it’s so true. “You’re a security person, whatever. You know, of course, you’re supposed to talk about security, that’s your job.”

It’s so different if their peer, their fellow architect or their fellow developer starts to talk about security best practices, and that’s the champion model. Find your allies, and incentivize them to have the right security conversations with their peers, and that’s where I think the whole value comes out of this entire thing. Now, one more thought, the opposite is true too. On the spectrum of your population, you will find people who are not allies with what you're trying to do.

You’re going to find people who are like, “We don’t have time for this, I don’t care about this, I have other things to do, quit wasting my time.” Those folks hopefully will eventually reach, and I have some stories about that, where we’ve been able to sort of change hearts and minds over time but initially, don’t worry about them. Find your allies, work closely with them.

[0:19:08.1] Danny Allan: So, I want to touch on that cultural change for the antagonist to the concept but first, how do you identify who the champions are? Are those your best developers or are they self-selecting that they put up their end and say, “I want to be a champion” How does an organisation go about identifying who should be the champion for the different groups?

[0:19:28.6] Dustin Lehr: Yeah, and this aligns well with what I was sharing before and that’s I do very much believe in these programs being more of a volunteer type of program, where you let folks self-select for the most part, like here’s the opportunity. As you formalize the program, you know, maybe you’ve got a built system or you’ve gamified it and there’s rewards, there are incentives and so forth.

Certain people again are going to emerge as being attracted to that regardless, in my opinion, of their seniority, their tenure, etcetera, they should be invited. Why would we refuse any help frankly and I also think everyone has something to offer there, maybe they’re less experienced, maybe they’re more excited. This isn’t an age thing but I would say in terms of you know, where people are in their career, I think if you’re more senior, you might have more influence and so forth, you just may not be as excited about something like this, okay?

So, there’s a certain thing you bring as opposed to being more junior, where you just can’t wait to get your hands dirty and you are excited about it and you can get behind it that brings a certain amount of energy to your program that I think is valuable as well. So, I like to keep the doors open in terms of whoever wants to join.

[0:20:50.5] Danny Allan: I like that answer because I’m a big believer in unlocking or unleashing the passion of the people who have this proclivity. I think there’s a danger sometimes in saying, “Hey, the best, you know, coder or engineer on that team is going to be my security champion.” And they’re probably already overworked and have 10 other projects and this isn’t the top priority.

And what you’re really doing is you're just putting more load on top of the head of the person who’s already overworked as opposed to finding someone who is passionate about this to drive the change. So, you’ve identified the person, you’re rolling out the program, what are the things that you’ve found to be effective in nurturing that seed for effectiveness and how do you measure that within the organisation?

[0:21:38.3] Dustin Lehr: Yeah, a hundred per cent and I will if you don’t mind, share a resource that I created. It’s completely free, it’s a website called The Security Champion Program Success Guide, and the reason I share that is because I go into a lot of detail in terms of how to think about this stuff. Where I think it begins is by setting very clear goals and a vision for your program, everything else comes out of that, right?

If you don’t know where you’re going, how do you expect to get there, right? Sort of concept. So, in terms of metrics and measurements and so forth, you know your security champion in my program in my view is not just this, you know, optional thing that sticks out on the side. Like, you’ve got these others, very important security initiatives that you’re pursuing and then you’re champion program that’s just sort of there.

No, they should be completely merged, and what I mean by that is a lot of your strategy should include how to make these changes through the champions, okay? So, in a lot of cases, your AppSec goals are your champion goals, they’re the same, right? So, and that’s where I think it starts and then I think everything from there is about really clearly defining responsibilities, how are those responsibilities, or I don’t really think about them as responsibilities so much as a list of optional actions that they can take with some sort of reward attached to those, right?

This could not just be material rewards, thinking about things like recognition and so forth if you report a potential security issue in the code base or something like that or you’re the top vulnerability triager, you know, or fixer, or something like that, starting to really tap into the motivators of the developers, and then rewarding them accordingly I think is extremely important. I think if you do all that mapping, if you map the actions to your goals, and you have metrics that are going to measure those, you know, progress towards those goals and so forth, you can easily demonstrate, “Hey, look what my champion program is doing.”

We have people doing these actions to satisfy these goals and we’re measuring them and we can see an improvement in triage rate, fixed rate, whatever those things are.

[0:24:04.8] Danny Allan: If we can take that and make it tactical, what are the specific actions that you would put at the top of the list, and what are the specific key results that you would measure against that?

[0:24:18.3] Dustin Lehr: Boy, there’s a question. So, I think when you’re first starting out, we were talking about this in terms of shifting left, I think it’s important to start on the right side when it comes to goals, okay? I don’t think it makes any sense to have this huge initiative around threat modelling or training. If you can’t demonstrate how that’s affecting your metrics in production, in the end product, right?

So, I like to work backward, I like to say, “Okay, what is our current production environment look like? Are there specific opportunities where we can improve things?” So, that would be like a root cause analysis, think pen test root cause analysis, what caused this to end up in prod? Oh, well, we missed that here. Okay, well, how do we get ahead of that? You know, what are some scans that we can perform or threat modelling, etcetera that we can do?

So, over time where I’d like to see something like a champion program help with this is in those more left-side best practices because now you can demonstrate how they actually affected the production environment. So, to get specific, one thing I really like to start with when it comes to champion programs is, “Are people reporting potential issues?” Period, like if we talk about code reviews, we talk about threat modelling.

We talk about just generically, “I saw this thing in the code, it didn’t look right.” I’ve had a lot of luck reinforcing those activities and then demonstrating, “Hey, now that we have eyes and ears everywhere through our champion program, look at the type of stuff that people are actually finding that maybe the security team isn’t able or just doesn’t have the resources to find themselves.”

So, in my view, that’s a huge value add is we’re starting to find stuff, and then I think from there, going down the path of fixing and having metrics around, you know, vulnerabilities. How quickly are we fixing them, are we meeting our SLAs, you know, what’s the mean time to remediation, that sort of stuff. I think you can get specific to that stuff too and I think that shows a lot of value.

[0:26:34.6] Danny Allan: I like your recommendation there because I often say that engineers are truly the only ones that understand the application. If you have a security person coming in after the fact, they often don’t understand what the intent of the application is, how it’s supposed to be used, how it’s not supposed to be used, and so asking them to do security analysis, they don’t have the full breadth of understanding to do that type of effective analysis.

How do you determine success? Or I know that you never crossed the finish line, this is always incremental and it continues forever but at what point would you say, “We’ve reached a security champion maturity model status that I am happy with.”

[0:27:14.6] Dustin Lehr: Yeah. Well, I do think you hit the nail on the head in terms of I don’t think you’re ever really finished there. There are always other opportunities to improve. Now, that said, you know I think the – and I have not seen this, so let’s be very clear but I think the vision here would be that the majority of your developers are involved in some way in this process. So, if we kind of step back a little bit, we talked about finding early adopters, early allies when you first start.

In my view, change looks like those early adopters mindset and the things that they believe in and so forth starts to spread to the point that you now have developers that are more aware of best practices and you’re measuring that they’re actually following those best practices overall. Now, there will always be laggards, okay? But I think if the majority of people are acting in a way that you wanted your initial champions to act, that’s a win.

That’s where you can step back and say, “Okay, I’ve done really good things here.” Now, that takes years and that takes a lot of work but I do think that’s kind of the finish line to some degree, you know, is to get our culture to that point.

[0:28:36.6] Danny Allan: Yeah, pre-this principle, right? If 80% of the developers are acting as those early champions then that’s probably the success metric that you want. Going back to the pin of there are some that might be opposed to this and they don’t want to be bothered with it, do you have recommendations, or have you seen things that have been effective in winning over those types of individuals?

[0:29:00.0] Dustin Lehr: Yeah, so I shared before that I’ve got a story there and this was from a champion program that I ran, where I was – a guy in my team, we were running around evangelizing this program talking to the engineering managers, right? And we’re like, “Hey, we’re going to do this thing, here’s how it’s going to work, you know, we’d love any recommendations for folks on your team. Who do you think would be interested?” And so forth.

And I remember we were in a cross, this one individual, and he basically just said, “No, thanks. It’s not for me, that just we’re busy. We just don’t have time for this.” I was like, “Okay, okay.” I’m not going to push it. I’m not going to say, “Well, you should or don’t you believe in security?” And like, put this guilt trip on him or something. It was more like, “Hey, you know what? I respect that, that’s fair, totally fine.”

And then, I’m like, “Okay, but we’re just going to go over here and we’re going to do our thing.” So, we started to create an amazing champion program, and it got to a point where it was three years, three years later where that manager since it spread across the culture enough, signed up himself to become a security champion because he saw all the great things that it was doing. That’s incredible, okay?

So, the advice that I would come back to would be let them go for now, focus on how I – focus on the ones who do get it. It’s not going to be everyone and don’t try to impose this mindset on folks, it’s just going to be rejected. Like, people are – even if you think it’s a win, “You know, hey, we made…” Cool, we went to their leadership and we made them get on board, cool like we want that one.

No, you’re going to lose in the long run because you now have people involved who are not interested in being involved and that’s a recipe for disaster.

[0:30:55.9] Danny Allan: I love that answer. I do believe it’s the grounds up, it’s a movement. If you push this down, that is the opposite of a security champions program, and you want them to want to join the champions program. We can’t go through a podcast these days without talking about AI, so I have to throw in the AI component to this. Do you see LLM usage or AI usage having any impact on things like champions programs or do you think no, this is truly a cultural phenomenon, not a technology phenomenon?

[0:31:32.9] Dustin Lehr: Well, I do think, you know, technology can help with culture quite a bit and the company that I created, Katilyst, is sort of built around this concept as well, how do we automate a lot of this, how do we, you know, motivate individuals by reinforcing their actions and so forth in a way that’s easy to manage, and as automated as possible. When it comes specifically to AI, let me just say this that I do think when it comes to culture and building relationships and so forth, we’re still forever going to desire the human connection.

So, I do not think that a bot interacting with you, you know, “Hey, I’m your security,” you know, like Clippy, right? “Looks like you’re writing code today, how can I help?” right? I don’t think that that approach is really going to create the relationships that we need to get stuff done but that’s not to say that we can’t utilize AI in smart ways to help feed, you know, the champion program and this entire thing.

A couple of examples, one would be recognizing patterns and behaviour, and you know, turning that into something that you can use to maybe identify gaps in your program. You know, there’s certain things that developers are doing, there’s certain types of vulnerabilities and so forth that are still being submitted, or people spend X amount of time on the training that you know, or whatever it is that can sort of help us understand the behaviour across the environment.

That’s good as a whole. I also think point-wise, like you know, in terms of identifying specific opportunities at an individual level, there is some bot work, you know, that I think would be valuable there, including, “Hey, you know, it looks like you haven’t done this for a little while, you know? Here are the reasons why and here is the rest of your sort of behaviour profile,” and so forth, “Have you considered, you know, looking into this?”

Or, “Here’s a training that I think would be relevant to you based on your behavior and activity,” and that sort of stuff. So, that’s where I see a lot of value coming out of AI.

[0:33:43.7] Danny Allan: Yeah, I think there is a lot of pattern matching that can be done there, and even back to your first statement of successes, identifying things earlier in the process and identifying more, you can use AI to augment those types of efforts within the program and then across an organisation. Well, it’s a fascinating topic, and I believe that Security Champions Program is one of the most important things you can do from a cultural standpoint.

We’ve actually developed something we called prescriptive DevSecOps here at Snyk and that is an essential part of it. Do you have a mature program that does that? What was the website again that you mentioned earlier that gives a lot of this material?
[0:34:23.1] Dustin Lehr: Yeah, it’s called The Security Champion Program Success Guide, and it’s at SecurityChampionSuccessGuide.org.

[0:34:32.6] Danny Allan: Okay. Thank you, and we’ll link to that in the show notes but that can be, I’m sure, an awesome resource for the people here. You have a company if I’m not mistaken that does something in this area, is that right?

[0:34:44.9] Dustin Lehr: Yeah, Katilyst. Yeah, we created this over three years ago and it focuses on solutions when it comes to security champion programs, including design, training, engagement, as well as we have a product, like I mentioned, that helps to automate the motivational pieces. You know, “Hey, you did this thing, you get X out of that.” And sort of a flywheel that comes out of that, right?

“Okay, cool. I did a thing, I did a good thing, I was rewarded for it. I feel like doing more of those things.” So, that’s the idea behind the product.

[0:35:18.4] Danny Allan: I have found that gamification is very, very valuable in these types of things. People are naturally just competitive, they like the fun kind of gamifying, and you can use that to great effect when rolling out a program like this, so. Well, it’s been great to speak with you today, Dustin. What makes you most excited about the future? So, you’ve been in the security space for a while.

You’ve been an engineer for a while, is there anything that you look at and you say, “I’m really excited about this, I think there’s a bigger opportunity than people realize?”

[0:35:50.9] Dustin Lehr: Yeah, and I think it is in this champion and culture change model. I don’t think tech is going to solve everything. I think the more that we realize that most of the issues in cyber can be solved by finding allies and going through culture change and sort of really focusing on the people side, it’s going to get better. So, that’s the future that I’m looking forward to where it’s not so much of an emphasis on just tech.

But also using tech and using AI and taking the behavioural science side approach to the entire thing. So, that’s kind of the nirvana that I have in my mind, and I think – I think we’ll get there. I think it’s a matter of, you know, increased awareness when it comes to these types of things, and just learning from our mistakes, you know, as they happen until we’ve evolved, you know, to the extent, so.

[0:36:43.5] Danny Allan: Well, it definitely is people process in technology and I love the light that you shined on relationships because ultimately, although we’re writing code, it still does come down to relationships in whatever you're doing, and certainly when writing code and building software, having those relationships is super effective. Well, Dustin, thank you for joining us today on The Secure Developer.

I wish you well, and for those folks who are interested in learning more about his company, where should they look you up?

[0:37:10.0] Dustin Lehr: We are at Katilyst.com. The spelling is a little bit different though, it is K-A-T-I-L-Y-S-T. So yeah, feel free to look us up, and great to be here. Thanks so much for having me, it was a really great discussion. I appreciate all of your questions.

[0:37:25.5] Danny Allan: Excellent, and thank you to everyone for joining. We’ll see you next time on the next episode of The Secure Developer.

[END OF INTERVIEW]

[0:37:35.0] ANNOUNCER: Thanks for tuning in to The Secure Developer, brought to you by Snyk. We hope this episode gave you new insights and strategies to help you champion security in your organisation. If you like this conversation, please leave us a review on iTunes, Spotify, or wherever you get your podcast, and share the episode with fellow security leaders who might benefit from our discussions.

We’d love to hear your recommendations for future guests, topics, or any feedback you might have to help us get better. Please contact us by connecting with us on LinkedIn under our Snyk account or by emailing us at thesecuredev@snyk.io. That’s it for now, I hope you join us for the next one.