The Security Champions Podcast

North Carolina State University Students - Navigating the Cybersecurity Journey

• Mike Burch • Season 4 • Episode 6

Share episode

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 30:51

In this episode of The Security Champions Podcast, Michael Burch sits down with Britton Janet, Quinn Merkel, and Snehanshu Samanta, students from North Carolina State University, to discuss their collaboration with Security Journey on a project to automate lab setups.

The conversation explores what they learned while working through a real-world technical project and how the experience shaped their understanding of development, security, and teamwork. They share the challenges they faced along the way, from troubleshooting and adapting to unfamiliar requirements to learning when to ask questions and how to keep moving when things did not go as planned. The episode also touches on the role of AI in the development process and the importance of persistence, curiosity, and communication when building practical cybersecurity solutions.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Podcast sponsored by Security Journey, Secure Coding Training for Developers and Everyone in the SDLC. Learn more at securityjourney.com. 

FOLLOW US to stay up-to-date with new content!

Get your free VIBE Coding Field Guide: https://hubs.ly/Q043-zdS0

SPEAKER_00

The Security Champions Podcast is brought to you by Security Journey. We help enterprises reduce vulnerabilities through application security education for developers and everyone in the SDLC. Learn more at SecurityJourney.com.

SPEAKER_01

Welcome to another episode of the Security Champion Podcast. I'm your host, Michael Birch, and today we have a unique episode. You'll notice I'm not in my usual studio setup. I'm joined today with a bunch of students from North Carolina State University that we partnered with over this last semester to create a really cool project to let us move faster in the way that we build content. And I brought them here to have a conversation about that experience, the things they learned, and kind of share that with the rest of the audience here. Because here's the reality these are some of the earliest security champions. These are people that are out there building tools, working in school, and showing that interest and security before they even get to the organization. So let's talk about what drives that and see their experience. To start with this, what I always do is we talk about what your security journeys are. I know you guys are maybe earlier in those security journeys, but I want me you to tell me about your experience, what you've done up to this point, what you're studying, what you want to do after this. So we're gonna start with you, Britton. Tell us your full name, who you are, um, and kind of your security journey. Thanks, Michael.

SPEAKER_02

Yeah, uh my name's Brittany Janae. Um I think my security journey started a long time ago. I've always been interested in technology in middle school. I I hate to say it, but I would try to get around the firewall to play games in class sometimes. And so I think that's where it kind of started. But eventually I was inspired my sophomore year at NC State by my first computer science professor to um hunt down like bad guys on the dark web. Um he showed us some steganography, and I was like, okay, if this is what I feel like this is my calling, like it feels righteous. And um eventually I just really enjoyed the actual process of learning um technology, especially in the offensive security field. So I started uh studying for my OSCP, I got my sec plus, and that kind of drove me to be a part of Security Journey Senior Design Group. I saw you guys were really into making offensive and defensive security labs, and because of that, I I felt drawn to the mission, and that's why I'm here.

SPEAKER_01

Awesome. And and so to like offensive stuff, amazing stuff, and I and that is kind of a caveat. I should let people know what we did here, is at Security Journey we sponsored a group of students to work on a project for us, and we picked something about building our our labs and helping automate and speed that process up. Um, out of that then, so so get what you're trying to study. Are you looking to get into off sec? Is that kind of your next step of your journey?

SPEAKER_02

Yes, 100%. I um I have my OSCP exam scheduled, but one thing I really want to do is I just feel like one of the best things that we can do is emulate the attackers and find the weaknesses before they can. And one of the best ways to do that is to do offensive security, opposes the attackers before they can find anything that they can use. Um it's also just fun to me. I really like puzzles, and I really like I really, really like not breaking things, but like seeing how I can like kind of like change things, like, oh, press a button, like, oh, what does this do? You know, when I'm not supposed to. And um, I think that um it's also extremely important just to show people like hey, this is extremely possible that something bad could happen, and then being able to actually use my skills to show them that. Um yeah, I I think that's definitely what I want to do. I'm pretty passionate about it, and it's something that I'm I'm very interested in. It's amazing.

SPEAKER_01

I can't wait to see what you do. All right, Quinn, tell us about you. Full name, what are you studying, what got you to the point you are, what are you doing next?

SPEAKER_03

So I'm Quinn Merkel. I I've always been interested in technology, same with Britain, ever back even back in middle school. I've always loved programming too. Um but then in about freshman year, I was like, I didn't know exactly what I wanted to go into. I knew I wanted to do engineering and something with computers, but I went I ended up going to computer science partly because I joined HackPack, a club at NC State, which is all about offensive security, actually. So they got me interested in all that kind of stuff, um, including uh, you know, just basic uh offensive security. And then I took a couple more classes in the cybersecurity concentration at state, you know, our class about offensive security, our network security class, stuff like that, and I got more and more interested. And then this summer I'm actually gonna go and get my OSCP done as well, so I can do some of that hopefully when I graduate.

SPEAKER_01

I'm surrounded by hackers. We got a lot of off sec going on here. That's awesome. Um so getting into the offsec stuff. All right, we practiced this like a dozen times to say your name right, but I think it's best if you just introduce yourself so I don't butcher it and tell me about what you do.

SPEAKER_04

Hi, uh I am Snehan Susamanza, and um my I well, I study computer science. Uh my securities journey, I mean, I don't know where when it started. It's it's basically, you know, when you're a kid and you are playing games on someone's phone, your mom's or your dad's or someone's phone, your grandparents. There's a phone in the house, you play games on it, right? I mean, whenever I played a game on it, it would probably I would probably break something. There would be some setting I would change and would literally break it, and I would always had have to fix that. And that was basically my thing. Every anytime there was a technological problem, I had to fix it. And that's just basically how it was. I also was I mean, I think I'm still pretty good at math. Um so because of that I just got into computer science. I just loved solving puzzles, fixing things, and just building something or just making something for a problem that I was just given to solve. And I actually was taught like I I had a coding class when in fifth grade, it wasn't basic. And that was just the beginning, I guess. It was pretty low level, but yeah.

SPEAKER_01

So what are you planning to do next? What's your what's your uh next step after this program?

SPEAKER_04

Yes, uh I am still figuring that out. Um I don't know. Uh I am just going as it goes, I guess. Um learning things. Um I think I'm just figuring out.

SPEAKER_01

You know what? I think I'm still figuring it out too, so you're right. That's one of the great things about this type of field and these type of studies, right? It's ever changing, right? If I were to talk to you guys about, I don't know, a year ago about what I did and what I was thinking, what I was working on, completely different than what I'm working on now, right? So not having it all figured out is perfectly okay in an industry that changes this fast, right? Absolutely.

SPEAKER_03

Constantly learning, trying to keep up.

SPEAKER_01

Absolutely. All right, so I have my team here. You guys all NC State students worked on a project with us. What we're gonna do is we're gonna take a quick break. We're gonna do a word from our sponsors, but then I want to start talking about the project that you guys worked on, what you guys learned and what your experience was.

SPEAKER_00

The Security Champions Podcast is brought to you by Security Journey. Security Journey is an enterprise class secure coding training platform with lessons that are built on learning science principles to deliver long-term, measurable results. Learn more at securityjourney.com.

SPEAKER_01

Alright, welcome back to the Security Journey Podcast. I am joined by a group of North Carolina State University students that helped work on a project for Security Journey to actually help us build labs faster. So let's start. I'm gonna pick on you, Quinn. Give us kind of an overview of what you guys did this semester.

SPEAKER_03

So we were tasked with creating a product that could automate the setup of the configuration files for your lessons. So, you know, the Docker files, Kubernetes configuration files, stuff like that. Stuff that just a lot of busy work takes a lot of time because you've got to get things exactly right, but not a whole lot of actual thinking going on. You're just writing out code. So what we did is we take the output from your internal tool factory, and then we turn that into just the built-out files. And we take a little bit of user input to get some of the finer details right. And it's meant to not get you 100% of the way there, but it gets you about 90% 99% of the way there. And you just got to fill in those just the little things that you know we can't account for on every single run.

SPEAKER_01

The biggest thing there is you took something that was a manual long process on our end and you condensed the amount of time it took us to do that, right? So what was kind of the what was the output effect of that?

SPEAKER_03

So our goal was to bring, because we were told that you're it took you guys about three to four hours to create just those configuration files, we can get it down to about 15 minutes, we hope.

SPEAKER_01

Well, that is an amazing output. I like the sign of that. I'm pretty sure my entire content team loves not having to do that manually, also. Um so a great project, and the biggest thing is it has a some complexity with that too, right? So, what are some of the complexities you guys ran into in solving this issue?

SPEAKER_02

I think I can start that off, but I I definitely want to tag these guys in eventually because we all had different things, but me personally, um uh so I started off by making the Kubernetes files, and originally I was like, okay, this is easy, it'll just be a file write. And eventually when I was talking with Noah, I realized, oh wow, there's actually a lot of complexity to this. So uh there would be niche application interfaces that they'd want um that you guys would want. So IDEs, um different coding languages for the actual IDE itself, uh whether it was a mobile device and or a Linux terminal, um, there were a bunch of different applications that we needed to add, but we didn't know what the actual basis was for adding them. Sometimes we would add them in the factory file from the application, it would come with three defined apps that they wanted to add, but then there would be more that we had to add after. And so figuring out how to do that, like those niche little edge cases, became probably the most complex problem out of all of them. Um and then on top of that, I'd honestly, Quinn, do you want to talk about standardizing the actual file creation? Yeah, go ahead.

SPEAKER_03

So there wasn't a huge really a standard before, because you know every developer does things slightly their own way. So the Docker files especially take a lot of you know individualism to them because there's it's just running commands. So what we did is we went through and we created a standard and made a set of templates. And from there you can actually look at, we did a lot of work in making it so that this is very adaptable later. So you know, if things change, version numbers change, um, you want to start using different technologies, all you got to do is add a couple lines to one of our configuration files and everything stays working. Nice.

SPEAKER_01

So a lot of that is is taking these complex, diverse problems that have a lot of different use cases, right? Because we're not just building one kind of lab, we're not doing one type of process, right? A lot of diversity in what we're doing, and a lot of complexity, and how do we how do we capture all that and create a unified way to approach the problem, right? And that's that's definitely an exciting thing to kind of work on, especially when you think about the different styles of developers working on this, because we don't have one engineer working on it, we have all sorts of developers working on this, and how do we standardize that? Um, really fun and amazing problems to solve. I actually would love to like pull back a little bit and think about the way your guys' course work, because it wasn't just solving our problem, right? The point of your class isn't to learn how to use Docker files or learn how to build interfaces. What's the point of the class? Like, what were you guys learning along the way?

SPEAKER_03

So the best way I think it was learning how to work as a team in a real production environment. Because before this, we take one other class that's on it, which is software engineering. And that kind of gets you like in it barely, but like a lot of the stuff that they give you is already well built out, and there's you're not really starting from nothing and you're not going into a production environment. So this is our first opp one of the first opportunities we get to really go through and learn how to work as a team of developers on a project that will end up being used and will be inspected very closely because of it.

SPEAKER_01

All right. You're not talking a lot, I'm gonna pick on you. What are some of those workflows that you guys had to do, right? Like it didn't just wasn't go just work on the project, you had to do stuff ahead of time. There's a bunch of like validation and testing and presentations, like what was involved in that.

SPEAKER_04

Yeah, well, we did some research. Um we were taught we were just thinking about um what ki what were the kind of kinds of designs that would that we would probably take up, you know. At first we were probably do thinking about making an a AWS standard function, which we kind of scrapped.

SPEAKER_02

Um Britton can explain why we did that, but oh um the reason why was because in order to get AWS access, um, there were some more steps we had to take. So also it wouldn't allow us the biggest thing was um the developers. It would be easier if we had a actual interface, like a CLI, in order for them to prompt, oh, hey, are there any other applications that you want to add to these Docker and Kubernetes files? So if we had an AWS Landua function, it would be automated, and we couldn't do that. But if we had a CLI, when you create the files from the factory file, it'll actually ask you, well, our our product, I mean, our product will actually ask you, like, hey, are this there anything else you want to add on here? And it'll be a multi-like a um oh gosh, multiple choice. That's what I mean to say. Multiple choice, and you can select them, and then it'll automatically add it based off of previous designs. Yeah.

SPEAKER_04

Um it's an independent package that you can use in your own command line interface.

SPEAKER_01

That's awesome. That's yeah, and that that's amazing. So design decision, right? That that's where you started. You had you had to come up with a bunch of different options of how you would solve this problem, right? And part of that was interacting with my team and individuals to understand our architecture and what you had to build onto, right? Um, as you did that design process, um, having seen how these classes go before, I'm pretty sure there's some other security tasks you might have had to do along the way, like I don't know, maybe some threat modeling, some security testing. Like, like talk to me some about that workflow. How did you do how did you manage project management? How did you do like what were those type of processes? What do you learn from that?

SPEAKER_03

So I think I can dig that one. Yeah, you want to go for it. So we kind of did a uh Scrum framework almost. We had weekly meetings, actually, we had bi-weekly meetings, we met at least twice a week, twice a week, and then another third time with our sponsor, with uh Noah. And then we went through and we planned out our tasks for that week. We checked in every meeting and we made sure that we were all keeping up to date. We used GitHub projects for our project management, so we had to plan out what tasks need to be done now, what can be left for a little bit later down the timeline, what do we when do we want to have our final project done, stuff like that.

SPEAKER_02

Yeah, and I think one of the biggest things in terms of the project management was we didn't have one like centralized leader telling um like keeping everyone on track. It was more we divided ourselves amongst what we thought were we I were identi able to identify each portion of the project and then who was the strongest or who knew the most in each, and then assign them to each individual task. Because there were a lot of moving parts to the tool that we were creating, and uh that was the most successful part. The threat modeling, uh, because you mentioned it, I thought this would be cool, but as of the time that we're talking about this, software supply chain attacks are running rampant right now, and that's actually the number one threat that we're gonna be experiencing, is because the packages that we use, obviously we have them pinned right now, but uh just like anyone else, um, they're vulnerable to you know malicious code. Fortunately, we're good. Like um we're uh that's probably the only threat that we have, but thankfully, because it's an insider tool, we should be good. Yeah.

SPEAKER_01

And that's an interesting part about this class, right? I love that NC State does this. They put you in this environment where not just solve a problem for business, it's understand how businesses solve these problems, right? Because you got not only the insight of you had to run your own business management, but you worked with us like a third-party source that you were consulting for, right? And you had a product owner, right? Which I would have to say was a big shout out to Noah Morris for being that that sponsor for you guys and working with you guys. If anyone doesn't know, Noah Morris is a senior security engineer that helps build a lot of our content on our side and was with you every step of the way. He was incredibly helpful the whole time. Yeah, he was. He answered so many questions.

unknown

Yeah.

SPEAKER_04

We were in touch with him on Slack, like for hours, like every single week. Yeah. Yeah.

SPEAKER_01

So so what's that like? And then what's what insight did that give to you into kind of working in like with a senior developer and security engineer that has a lot of this stuff? Like, what did you learn from kind of NOAA in this process too, I guess, along the way? That's a good question. Yes, it is.

SPEAKER_04

There are no stupid questions. There are absolutely no stupid questions. Everyone is totally human and you can have any questions at any time, no matter how small they are.

SPEAKER_02

Yeah. Yeah.

SPEAKER_03

100%. It's better to clarify than spend a bunch of time writing code that just won't work and then having to go back and refactor it.

SPEAKER_02

Yes, Nahanchi hit the nail on the coffin right there. There were so many. I was gonna ask I would ask him, like, hey, what does this mean? And he was so helpful, but that's what a senior developer does.

SPEAKER_04

Helped us set the standard for all the configuration files. Like for every small keyword, every small line of code that we had, we asked Noah every single detail, and he was incredibly helpful in answering each one of those questions.

SPEAKER_01

A big drive-home point for that, too, and something I hope you guys take away from this, is you think that's like a thing you're learning in school. No, this is things that teams get wrong all the time. Right? Actually understanding the end user problem, collecting the right information to solve it the right way before you do work, like it seems like the most critical part, which it is. You'd be amazed at how often teams struggle with this. There's dedicated jobs. That's what UIUX and a bunch of these other uh roles are for, is they help you actually take the dev team and they go and interact with the customer and end user for you and collect all the information and the testing to help influence what we build. And I've seen teams, I've worked on teams where that's disconnected. And when that disconnects, is engineers like, I have a problem, I know the best way I'd solve it, but they're not seeing it necessarily from the customer, and they're not talking to the customer, and all of a sudden they build something really great the customer can't use because it's not for the right problem, right? So that that that's something that's I really do hope you take away from this is ask a lot of questions, like know what you want to do before you build, because that front-end work is gonna help you so much along the way as you keep building. Um all right, so let's let's let's let's back into the project, some of the things you learned. Let's talk about AI. AI is a hot topic. I can never get through a podcast without bringing it up at least once. Um, how did AI influence you guys' project?

SPEAKER_04

Yeah, a little bit, like initially a little bit of understanding just of the overall code base. I mean, there was a lot of detail on read on the README, but like some of the inner details of the code base, like some some of the directories, some of the files, yeah. It was easier to understand using AI.

SPEAKER_01

That's amazing, because that's something that I think people like don't give AI the credit it it deserves. So many was everyone's all about, well, it helps me build faster, it helps me write code. But what about that person that's coming on your project that needs faster insight of what's there? Like leveraging AI to dissect that and translate that in ways that and I'll be honest, most of us are not great at building the read me, or no, it's not nearly to the level that we should be. You have a couple rock star engineers that do that stuff well, but the majority of us out there leave out a lot of detail, right? And that's one of the hardest things to hand out for a project, but having AI to be able to distill that, that's powerful. Because that changes AI from replace, not just AI is doing work for me. AI is helping me learn, it's helping me understand, it's empowering me, and that's such a great use case of it. How well how else though? I gotta dig more. What else do you guys use AI for?

SPEAKER_03

I primarily used it in mine for debugging mostly. Like, you know, error comes up, I use it to understand the error that appeared, understand where in the code caused it, how to fix the syntax, how to learn syntax I didn't already know to make things more efficient, stuff like that.

SPEAKER_02

Yeah, I think for me it was more like finding tools and packages to use. So my when we first started, I would mention earlier having a CLI multiple choice list, and one thing we eventually adopted was a whole helper function called inquirer. And when I first started, I when I was talking to Noah, I was thinking, okay, well, we need something that will actually take in, show the user a list of 20 apps and actually allow them to choose it. And since we're using a CLI, I needed to find a CLI package. Um I asked I asked Google Gemini, I was like, hey, what's a great package to use for a command line interface multiple choice? Sure enough, led us to Inquirer Pi, and then we were able to put that into our project, implement it, and like I thought it was really cool. Noah thought it was really cool, and it ended up working perfectly.

SPEAKER_01

It was exactly what we needed. And that's a great place for it too, once again. And what I haven't heard any of you say is, oh, I just Use AI to try to write all of it for me. You used it for research. You used it for understanding. You used it for what was yours again? Analysis. Analysis, right? Like it enhanced your capability to do your job. So I'm really glad that was the answers, and not just, oh, ChatGPT wrote the whole thing. We didn't write any of this.

SPEAKER_04

I mean, one other thing that I didn't use it for was templating. So we are we use so many templates for the configuration files that we have. So at first we were just using text files and just reading them, and it was a whole nested process that was like just a little more time complex. Then our instructor, Dr. William Enk, he suggested that we use a templating library called Jinja, maybe. So we used that and the whole the entire process was was a little more linear. And uh with that, um well, like now we moved from one standard which was text files to another format which was Jinja readable, and doing that was like so much more helpful using AI, you know. Yeah, absolutely. I could absolutely see how that could immediately help and enable that. This was like around the deadline. So since we had a like we needed a quicker turn around turnaround, yeah, I used the app for that.

SPEAKER_01

I'm not gonna lie about that. So I will say this too, because you because what's what are some of the things you guys have to do for this too, right? You're not just like you're accountable to us, but you're doing homework too, right? If I remember correctly, from what I did, is you had to write a whole paper and you had multiple phases of papers that you had to write. You have to do oral presentations on this stuff. Um, you had to have a threshold of security unit testing or unit testing, and even uh you might have had to like do uh behavioral testing, right? Everything along this, right? So that you had to do all these different components in a really condensed timeline and try to basically get a little exposure to everything you would think of seeing kind of that traditional development role. Absolutely.

SPEAKER_03

Like because our professors also, Lara and Will, they were talking about how we were given a much like we were only given a semester to do something that some in some companies might be taking six months, maybe longer even to try to implement. But we had to condense it down and get it done as fast as we could and get it done in a semester.

SPEAKER_04

Yeah. And having AI is incredibly helpful. Like even just removing some of the redundancies in the code, um, it's like very helpful when you have AI.

SPEAKER_01

Yeah, and that like I said, I think that's amazing. I think that finding those right use cases because it it let you complete a project that you might not have been able to finish otherwise, right? It let you it made you more productive across the way, it sped you up. Um here's the sad part you guys are gonna hit when you hit the rest of the industry. Um that's now the expectation. It's it's not gonna make you faster, it's gonna help you keep up with everybody else.

SPEAKER_04

Yeah, absolutely. I mean, yeah, since we were finishing like uh our tasks quicker, we were like, hey, how else can we make your life better? Like every time. Since we were finishing one phase, we were like, yeah, in the next phase we can how can we make this product even better? You know what I mean? Absolutely.

SPEAKER_01

Alright, so out of all this stuff, all yeah, just touched a lot of different things. You built a really great product for us. It was great partnering with you guys. Um I'm gonna go through each one of you, and I want you give me kind of like your your your the number one thing you learned, your biggest takeaway going away from this project.

SPEAKER_02

Number one thing I learned. Um you know, getting started and how do I say this? Persistence. That's the biggest one. 100% persistence. Um for context, I was really, really scared to start. I had never used Docker, I had no idea what a Kubernetes file was. I honestly didn't know um anything on how the project was situated because I had a lot of busy stuff going on the first week. Um and then eventually I just sat down and I said, okay, in the next four hours, I will have written code, I will have understood the entire project, and I will know what I'm gonna do next. And in those four hours, I did exactly that. And I sat down and I just I again like I used AI, or I didn't use AI actually. I literally just looked at the entire code base and I understood how everything was. Um and then uh I reached out to Noah and I asked him every single little question I could hey, how does this work? Hey, what does this mean? And eventually I just started typing, and one bit by bit the first bit of the file started coming together, and by the end of that, I understood exactly what we were going to do. I had a mission, uh, or I had an idea, a plan of what I wanted to do next, and brought that back to the team. And their next meeting, we ended up having a fleshed out idea of what we were going to do. So if I hadn't had that persistence at the very beginning just to sit down and do it, I think that that's I think that it wouldn't have gone as well. And I think that's the one thing I took away was just sitting down and actually doing it.

SPEAKER_01

You know, that's one of the things that I I think we take advantage of, or not advantage of, um we don't appreciate, is so often some of these tasks were handed in the this working world, is 90% of the battle is just just getting into the grind, and once you get going, like the momentum will keep you going, right? But that that first step quite often is quite the hardest. So that's amazing to hear. All right, Quinn, you're up.

SPEAKER_03

I was gonna say basically the same thing he did, but also I had the thing of in all my projects up till now have been something I've started from an idea I had or a project that we were given in school, where we were basically given a little bit of starter code, but we were writing the whole thing because the whole point was to teach us how the code worked. This was the first time where I was picking up on code a code base that already existed, ex requirements that already were there, and then augmenting it to make it better. And to like add a new functionality to it.

SPEAKER_01

Yeah, and that so that's another big thing too, and that's the world you're gonna live in, right? Not often are you gonna be like, oh, here's a start from scratch by yourself. No, you're gonna be dropped into an organization, they're like, all right, here's the monolith we've been building for 20 years, get working, right? Yep. Awesome.

SPEAKER_04

All right. Okay, um, yes, I would definitely agree with what these guys said. Uh something that I would definitely want to get over next time I'm starting a project is shame. Like when you're surrounded by like by brilliant people such as these, it's like you will always uh feel a certain kind of imposter syndrome um that you definitely want to get over um some way. And I have had um the privilege um to have the support of these guys who've helped me all the way through. Um because like in a team, you want everyone to succeed together because that's how you have something, the end product, it's gonna be beautiful. You know?

SPEAKER_01

So that's that's amazing. And the one of the biggest things is engineer work can often feel siloed if it's not done right, right? I'm oh it's me and my computer, it's me and my keyboard, I'm just pushing code. Um, the power of real builders, development, design, that's collaboration. It's working together and supporting each other, it's learning from each other. Like that's when you get teams that move at speed. Um, and like I said, I I'm it's amazing things that you guys did for us. I'm glad you guys learned a ton out of it. I gotta do a big shout out to Noah Morse, who wasn't able to be here today just because of timing, but um was really a driving force on this project. Um as that, we're gonna kind of think wrap it up at this point, but I want to thank you guys for all the work you guys did. Thank you for coming on and joining the podcast, sharing your stories. Thank you for having us. Thank you for having us. I'm so glad to be here. Absolutely. And you know what? And like I said, I'm it's such an honor to work with you guys, and especially like I said, big thanks to Noah. I want to reach out and say thank you to our audience for joining us today. Also, if you guys are looking for some bright young engineers, these are the people to be looking at, right? They do good work. We've already proved them out, right? Um, so uh we'll uh I'll promote you guys on LinkedIn, I promise. Thank you. We would need that. But yeah, like I said, all right, coming to the end here, I want to thank all of our audience for joining us for another great episode. And as we always say, remember, security is a journey, not a destination.

SPEAKER_00

The Security Champions Podcast is brought to you by Security Journey. Security Journey is an enterprise class secure coding training platform with lessons that are built on learning science principles to deliver long-term, measurable results. Learn more at securityjourney.com.