Jet Anderson -- The AppSec Code Doctor

0:00Chris RomeoJett Anderson's passion is teaching today's software developers to write secure code as part of modern DevOps pipelines at speed and at scale without missing a beat. He's been a software engineer for over 25 years and believes that fixing security bugs is better than just finding them. Jett joins us to discuss software or security engineer first, how fixing security bugs is better than just finding them, and the Code Doctor security training program he built and deployed. We hope you enjoy this conversation with Jett Anderson.

0:35Are you struggling to measure the effectiveness of your secure code training? You're not alone. That's why we're proud to share that on average, Security Journey learners increase their knowledge an average of 33% and as much as 85%. Our diverse training content satisfies a variety of adult learning styles. from conversational training videos to hands-on secure coding activities, ensuring that learners are engaged no matter their learning style. Visit securityjourney.com to try our training today.

1:06Chris RomeoHey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo. CEO of Curve Ventures. And I'm also joined today by my good friend Robert. Hey, Robert.

1:33Jet AndersonHey, Chris. Yeah, Robert Hurlbut, and I'm a threat modeling architect and enthusiast, as well as application security-focused. And of course, again, we enjoy talking about application security here.

1:48Chris RomeoYeah, but we're going to take a left turn or a curveball today. We're going to talk about constitutional law. So please stay tuned for a 2-hour— no, I'm just kidding. I know nothing about constitutional law. I probably couldn't even begin. I probably couldn't even get 2 sentences out of the way. So instead, we'll talk about application security. So we're super excited to be joined today by Jett Anderson. And Jett, we always like to throw this question right at our guests very quickly. What is your security origin story? If there was a comic book, what would I find in episode 1 of the Jett Anderson story?

2:22Jet AndersonComic book would be so much more fun than just real life, wouldn't it? But so, I was a software engineer for 20+ years, software engineering manager in my last gig before I came to the dark side and managed a platform for the 5th largest bank in the country processing $3 billion a month in check and credit card payments. So, woo, that was exciting. And one day, information security team brought me a 300+ page report with over 1,000 what they called vulnerabilities in it. Dropped it on my desk. No prioritization, no guidance. And by the way, you have 30 days to solve all of these problems or you go on a report that goes to the CEO of the company and you stay there until they're all fixed.

3:15Chris RomeoWow. And so, you're a software— you're not a security— you don't report to the security team at this point, though?

3:21Jet AndersonAt this point, no.

3:22Chris RomeoYou're a software developer inside or a manager inside of this company with no security in your title at all or no responsibility for security?

3:29Correct.

3:29Chris RomeoNope.

3:30Jet AndersonDev manager. cranking out new features, managing uptime, reliability, the usual suspects, right, in terms of engineering and maintaining a platform for that. So, and this is admittedly, this is about a decade ago, but, you know, after having some conversations with other colleagues around the space and even within the company and outside the company, I realized that this was actually an ongoing problem. That the culture between builders and protectors, you know, blue teamers, that sort of thing, was very much throw it over the wall. And, you know, because they're not engineers, they didn't necessarily understand even the reports coming out of the platform that they were using to generate these vulnerabilities. And I use that in quotes because I hate that word. It gets used too frequently. I tend to refer to most findings generated by a tool as findings, potentially even defects. Those are the terms that builders are aware of, that software developers are used to, right? And Jira, that sort of thing. You got a bug.

4:46Chris RomeoSo for you then, just because I'm going to stop and pause the story for a second.

4:51Jet AndersonYep.

4:52Chris RomeoSo, what do you define a vulnerability as then? If you're focusing on kind of findings and defects and things, what does it take for something in your mind to be a vulnerability?

5:01Jet AndersonAbsolutely. That's a great question. And that is— ah, that's the most fun that I have engaging with developers because when a finding or a defect is demonstrably exploitable, you know, there's a route to that defect, it's exposed, there's not a compensating control in place to keep that from being exploited, then it is truly in fact vulnerable. If a defect in code is never exposed, you know, you're using a third-party library, you're not using the vulnerable function, or you're using— or you've written some code, it's not exposed to third parties, it's an internal method, it doesn't have a route any other way, you know, that could be a stretchy one. But, you know, for it to be a vulnerability, there has to be— it has to be exploitable, right? And so, you know, I think understanding that difference, and I try to be an advocate really for the developers from the security side of the world and be, you know, and this goes back to that origin story because I think one of the things that lit us on fire so bad in that first interaction was, that there were no POCs related to each of these findings. There was no guidance on how to fix them in any of those findings. And so really it was, you know, a lot of the, you know, run a report, throw it over the wall kind of thing. And we know that tooling isn't 100%. There is such a thing as a false positive, right? And so identifying which are false positives, which are true positives, where we focus our efforts in terms of actual risk. Those are the things that I would come to learn as I began my security journey. And I became even more passionate over time at really being a voice of reason within the information security world on behalf of developers so that we could partner together. Because, you know, I'm going to probably run in circles here, but folks are fond of the phrase, well, security is everybody's responsibility. Have you heard that before?

7:18Chris RomeoI've said it for a long time.

7:20Jet AndersonYou've probably said it. Yeah. Making money is also everybody's responsibility, right? We don't have a job at the end of the day if the business isn't profitable. We can't get features out the door, serve our customers, delight our stock, our shareholders, and so forth. And so, there has to be a balance between those two. And in order for address, for us to continue doing the job, we have to address it in a risk-based approach, really identifying what should we be working on because we probably can't work on everything.

7:54Chris RomeoYeah, that's true. So, I want to hit play on that story that I hit pause on because I do want to hear what happened with that. You know, what was the resolution then if we pick up with, You're handed this report, it's got 300 pages and thousands of findings. Like, what did you do with it? How'd you respond to them?

8:12Jet AndersonI quit.

8:15Chris RomeoJust grabbed your box, started throwing all your toys from your desk, and you said, I'm outta here.

8:21Jet AndersonThat's right, peace out. I mean, it wasn't immediately, right? But it was soon after I realized, you know, I wanted to go be, I wanted to do this better. I wanted to do this better. There has to be a better way to do software development and secure software development. Than that. That can't be the way that we operate. So I decided to become Batman. I went into my lair and started crafting my tool belt and ensure that I had the means by which to go save the world. So I worked for a number of software security vendors for a while. While I was training myself and learning new things, I invested heavily in Studying for and getting a CSSLP. It was like one of the lesser-known ISC² certs at the time. Everybody gets the CISSP. It's a mile wide and an inch deep. I'm like, nope, I'm focusing on the software lifecycle. That's my jam. I want to make sure that I can help people with that. So I got my CSSLP, and then after spending some time with security vendors, went and built an AppSec program. Took a company from hundreds of developers, hundreds of applications, No consistent automated anything, no scanning on a regular basis to full-on DevSecOps in 18 months, man. Automated security at every stage of the SDLC, training, CTFs, code bashing with Jet. And that was really exciting. It worked. We started to see people change their mindset overnight to to recognizing that security is an important element of code quality. And I love that one too. I'm fond of saying that over and over again, just part of quality, right? Just good software. And then I got poached by one of my software security vendors to come back again. Hey, we want you to be a dev advocate. So did that for a little while. And then I spent up until a year ago, I spent the previous 4 years building a program around training software developers at a company, a large apparel manufacturing company in the United States with a logo that's totally not on my shirt, right?

10:47Chris RomeoSo much for operational security.

10:51Right. Yeah. What are you gonna do? Yeah.

10:56Jet AndersonSo, That was, that's kind of how I got started. And that's the thing that drives me. You know, it's funny. You know, I could, I see this as my life's work. Because it's a passion, it's an opportunity to do something that I know is going to help make things better, not just for the company that I work for, but for all of the people that are involved in, in doing that work, right? You know, I think the North Star for me is one of these days I'm out of a job. AppSec goes away, security literally is just another part of code quality, and it's something everybody does, and I can just go back to being a builder. I can be an engineer, and I can help build neat things. And so, one of these days when that happens, it'll be a perfect world, right? Yeah, we hope, right? So, similar to you, Jed, I have the background as well of being a developer for a long time and then switched into application security more and more. But today, how do you think of yourself? As a software engineer first or as a security engineer? Yeah, that's a good question. I think back to the original, back to that previous statement even, I see myself as a software engineer. but one who has a strong focus on delivering code with the highest quality possible. And one element of that quality is its resistance and resilience to attack. And this isn't any different. I mean, it's so— it's mind-numbing to me. And, you know, I know that there's some change in terms of the world of education that's taking place. If you roll the the history books back a decade, there wasn't a major university computer science degree program in the United States with a requirement for graduation to be anything to do with security, right? You could take applied cryptography, those sorts of things, if you had that interest or that focus, but we didn't really talk about security as an aspect of how applications are built and one of the features that needs to always exist, right? And so if you fast forward to today, that conversation's happening, I know it, especially at some of your larger universities, Columbia, MIT, those kinds of places, right? But if you roll down to the local, you know, state level and that sort of thing, especially your public programs, That's still not a thing. They're not teaching security as part of the requirements for graduation. And so, I mean, bless their hearts, these kids that come out of school and they come, you know, intern at a place like Nike or Amazon and so forth, and they go to work and they're shocked at that 300-plus-page report with thousands of vulnerabilities in it, no prioritization, no guidance. Like, we're still doing that. after all of this time. And so I just know there's got to be a better way for us to do that. And I think it starts through education. And that's kind of why I've spent the last 5 years or so really focusing on how do I engage developers to make sure that they have this information on day one and give them a direction that they can use to go and learn more.

14:31Chris RomeoIs there, you know, kind of a lesson within the way that you answered that question? Like, is this something that You think more developers, more security people should see themselves as developers? Like, is this something that should be industry-wide or is this something that's really just specific to you and your experience?

14:52Jet AndersonI think it is. I think it should be industry-wide. And part of the reason is, and I'll keep rolling back to the story because there's a reason why that team threw it over the wall to me. And didn't have POCs and couldn't explain how to do it better because they didn't know, right? So they like the— I think that's a big place where we have a challenge in our industry is we lack the credibility to, to stand behind these findings a lot of times because we can't explain what they mean. I can tell you just horrifying stories of interviewing application security engineers over the past 5, 6 years who couldn't explain basic flaws from the OWASP Top 10. Decompose a cross-site scripting vulnerability for me. Tell me what that is and give me some of your basic super basic controls. Most folks can't. And so that credibility is a problem, right? Like, if you can't tell someone, how do you fix XSS? If everybody's answer is, oh, well, I import a library from React that's gonna help me with that thing. Well, okay, that's one step forward, but what about what kind of headers exist that might help us with that? AKA content security policy. I can't tell you how many security engineers are really not aware of CSP and the deprecation of XSS headers and things, you know, and the limitation of browsers. And like, there's a lot of learning to be done. And if we don't have the basic level of credibility as engineers to be able to describe the problem and the fixes, then we have a hard time selling it. Right, back to the engineering teams. And if, you know, I don't want to spend all of my day beating my head against that and proving to them. I just want to say, okay, yeah, here, let me show you, give a quick example, take me 5 minutes, and here's how we attack that thing. And here's how you could, you know, blanket-wide change that by adding a rule to your proxy to return that information in the header to do basic protection.

17:18Chris RomeoWhat did you find? Now, I want to pull on a thread a little bit of what you just said, because as you're interviewing these people application security engineers, and they're unable to even explain basic OWASP Top 10, which if you're going for an AppSec-related role and you like, you better understand. I mean, if there's one document—

17:37Jet AndersonYou should maybe start there, right?

17:38Chris RomeoYou should understand is the OWASP Top 10. But I'm curious, were these folks that were more tool, like, 'cause I find there is a whole cottage industry within AppSec of tool people that just run, they just, I'm just a tool person. I just take the tool. and I run it and I set it up and I make the— I'm an infrastructure engineer that makes tooling work. Is that what you were finding? Is that what these folks' skill sets were? Or is it something else?

18:06Jet AndersonYeah. So, I think it's similar to what I ran into a decade ago, right? It's— and this is— forgive me if I generalize, right? Because there's always different people and different experiences for everyone, right? But I found a lot of folks that that came into information security roles came up through other IT organizations, right? They're network engineers or they're, you know, managing AD and identity and access management platforms, that sort of thing. And they begin to gather more knowledge. And so they become the experts, right? And unfortunately, there's a lot of folks and I Definitely not all of us are like this, but there's a caricature of InfoSec folks as being Mr. No, right? Like they get excited to be able to have that power to say, no, you must not go to production. Like you shall not pass, right? You know, Gandalf fighting the Balrog. You know, there's too much of that in our history. And so we're constantly fighting against that. And so that's where I think that, You know, a lot of these folks were looking to get into InfoSec, especially the younger generations. They got an MS and/or an MA in information security practices or policy governance controls, that kind of thing. I get that, that's all helpful. But for me, the folks that I found that are My biggest partners have been engineers in the last 5 years. It's definitely the last 5 years where you find a security-minded software developer and, oh man, the gloves come off and they go crazy. They do amazing work. I've had folks who are like, hey, so like what, you know, that we don't have an SCA tool in place yet. What can we do? And I'm like, hey man, Dependency Check is free. You go grab that stuff, write a few rules. He's like, can we put that in our pipeline? Yes, please. Absolutely. Put that in your pipeline. Well, can we write rules to block if there's something that doesn't match? Yeah, absolutely. Do all that. So, people just start, you know, my engineers just got excited, the ones that were thrilled to be part of this after learning from myself about what they could do. And they just went for it. We didn't even have to tell them. And this is where that Mr. No mentality frustrates me because I found that most folks, if you tell them what the right thing to do is, they'll go do it. But if all you do is say, you did something wrong, you're stupid, then that's probably not a way to build a healthy relationship. You know, there might be a better way for us to solve that problem.

21:07Chris RomeoYeah, I mean, it's empathy, right? Like, that's something I spent a lot of last year talking about is this idea of developer empathy. As security people, we should walk a mile in their shoes. Like, security people should spend— if you've never spent 3 days sitting next to a developer, and I get it, in the world we live in now, you got to do it virtually, but there are ways you could sit and just take in the developer experience. And you will leave that very much changed in your thinking because you're like, wait, we make them do this?

21:40Right.

21:40Chris RomeoLike, they have to do these things? Like, what? It doesn't even— the thing, the process that I wrote, that when they are running it and doing it, there's a piece of it that doesn't even make sense, but yet they still have to do it. Like, that's the level that we as security people need to get to. And it really does, you know, meld development and security together into one mindset, it's a really powerful thing. And when an organization reaches that level, watch out. Like, they're doing great things for security at that point. Yeah, for sure.

22:09Jet AndersonSo, you sort of already alluded to this, but I want to talk about this statement anyway.

22:18Chris RomeoIt's fixing security bugs is better than just finding them.

22:23Jet AndersonSo what are your thoughts on that? Yeah, so, and this is a thread that exists throughout a lot of the other things that I've said, right? It's just that, you know, we running the tool, finding the flaw, giving them the report, that's not the end of the day, right? I can, and if that's all you're doing as a security engineer, then you're missing out on a huge opportunity, right? fixing those flaws is— should be— and we— and we— you asked the question earlier, was should we be software engineers or should we be security engineers? Like, which one, which one makes sense, right? And so I think we have a huge opportunity if we're software engineers doing security to contribute to the overall health of software applications within the companies that we work for. Like, if, if, if You find initially, so definitely run the tools, look for the flaws in software. If you find that there's repeated instance of a particular authentication library being used that lacks a control around, let's say, enumeration or so forth, write that, right? Write the detection, write a library that prevents it, write a firewall rule that prevents it. Any of those things, develop a pattern even. I was involved in my last company at developing a framework, developing a blueprint for creating single-page applications that solved a particular flaw with regards to how tokens were handled. And that was consistently seen. And so we just like Well, let's just go and let's write a single-page app, you know, a quick demo framework and give this to folks and say, use this as the foundation of your application and you'll solve these 3 problems. And folks did it, right? So it's like, we have that opportunity, but if you're not a builder, you're gonna have a hard time doing that, right? And I think that there's, you know, the legacy security org definitely has less of that desire to build and own software, right? If you build it, then you own it. You got to maintain it and support it and all that kind of thing, right? There's a lot of work that comes behind that. And if all you want to do is be a tools and policy org, then that's probably not going to be in your charter. But I think you're really missing an opportunity if you don't.

25:00Chris RomeoSo, in doing some research for this conversation, I did find some references to the Code Doctor program. And so, I'm somebody who's also built programs, you know, inside of large companies. And so, when I get the chance to hear somebody else's story about how they did this and I get a chance to learn from the things that they did and were successful with, I always take them up on it. So, I'd love to hear about this Code Doctor program.

25:27Jet AndersonThat's great.

25:28Chris RomeoKind of what is it and what were the pieces that you brought together for success? Because from what I've understood, like, you had a lot of success with it. I wanna unpack what are the things that we can take away and what can others use from your experience to build programs such as Code Doctor?

25:47Jet AndersonYeah, great. Thank you for the opportunity to speak about one of my greatest achievements in life, other than being a parent and a grandparent and a husband. I guess my— This is one of the things that gets me the most excited. So, it was early on. I had just been hired at Nike as an engineer to assist a particular org within the company with improving their application security posture. Table stakes, right? Easy stuff. But being an engineer, I did it the engineer way. I started going to standups for literally every org in— or every team within that org. Hey, what's going on? How are you guys? doing? You know, tell me about your security. What have been some of the pain points? What are some of the— what can I do better? How can I help, right? So, I just went around basically asking, how can I help, for about 6 months. And at the end of that 6 months, I realized they don't know what they should be doing. Like, they don't know what the best practice is. Teach them the best practice. Back to that conversation we had about education, right? They'd never been taught. Nobody got in their computer science degree program anything to do with security. So, it was like, well, Let's give them a background in security. So, I went to the VP and said, hey, I want to teach application security best practices and principles to all of your software developers in this org. It's like 250-some-odd folks. And he's like, all right, fine. What do you want me to buy? Let me know. And I was like, no, no, no, no. We're not buying off-the-shelf ClickWare PowerPoint garbage. That stuff's horrible. People don't engage with it. It's not entertaining. There's there's very few practical takeaways from those things, and I don't think you'll see the engagement that you need in order to really be successful. He's like, fine. What do you want? So myself, and and I'll I'll give a little more of a peek into my background. I don't have a degree in computer science. I have an art degree. I'm gonna I'm the I'm the. I was voted by my graduating class as most likely to become a tech weenie. And I taught myself early on Java, Perl, XML. I spent many years doing app dev in large-scale corporate content management systems, churning out thousands of pages of content, right? So, that was my background. And, and I— so I said, I'm going to create this, I'm going to teach it, it's going to be one-on-one instructor-led with Jet. I'm going to host classes, but I'm going to deliver— I'm going to develop the content based around what I've seen from these folks and what they need so that we make sure that we train specifically to them. So having my background in art, of course, I brand the crap out of it. I created the Code Doctor program. Cool stickers and logos and all kinds of neat stuff, right? And it took off for— I think it did classes 3 days a week for about 3 months for one quarter and trained all 250+ developers. And we started to see change. A lot of it was anecdotal. We didn't quite have the ways to measure it completely. we did see a drop in new defect findings, but we also had folks coming up and saying things like— I had this one team come up to me and say, Chet, I gotta tell you, like, this was so cool. We were having a meeting with the, uh, doing sprint planning and reviewing our backlog, and there was this one feature that came up that the business really wanted, and we were able to explain to them because we'd gone to the Code Doctor class Why that was problematic and it would cause us some risk, and they agreed. Let's put let's hold off on that until we can find a way to do that securely. And I just tell you what, that was the pinnacle. I was like, oh my gosh, we're there! Like that's fantastic, right? So like what motivation did I have to keep doing this? It's just that kind those kind of moments. So and it was the team wanting to run dependency checks soon after. Like hey, we're gonna. We're going to start doing this thing. We're going to cut out some of our technical debt. We're going to figure out how to do this thing going forward. And so, you know, one of my favorite one-liners, my favorite dadisms is competence is quickly rewarded with more work. And so, word got out. That VP started talking about the impact that Code Doctor had on their development teams and on the quality of their deliverables and on security and resilience and uptime. And some folks went back to my CISO and was like, what's this thing, Code Doctor thing? And he didn't even really know. I hadn't told him about it. I hadn't even asked. Like, just like, I'm just gonna do this because that's what I think is the right thing to do. And he came and said, Jett, tell me about Code Doctor. And I told him what happened. And he's like, this is great. I hope you like this work because you're going to be doing it full-time. So, I ended up doing Code Doctor for all of the company, 6,000+ developers, took it over to Europe, did it in person there. And then, I'm going to kind of give you a little sneak into how this thing evolves. This is what happens when you think outside the box. There's always a what if, why not, like, let's try this thing. COVID hit. I had just gotten my visa approved to go to China to teach the co-doctor training class in Shanghai. And that was in February of 2020. What happened in March? Everything shut down, right? COVID changed our lives. And so, I just pivoted. So, what do I do to make sure that I can continue to develop or to deliver this experience for folks? I bought green screens, got broadcasting software, did it all live, fully produced, like, just why not? And then, one day, I was like starting to realize, you know what, I got to scale this. There's too many other topics. Everyone keeps asking me, how do I— I'd like to co-doctor class, and it's 3 hours, by the way. in person with me, a deep dive, you know, first third of the class was the OWASP Top 10, or we actually called it the Nike Top 10 because it was specific to the company. And then, but the last two-thirds was what are the best practices, proactive controls, like what are the things that you guys can do to make sure to do it right from the first time, from the start. So, but everybody at the end of the class would always say that was great, it was 100%, like 100% awesome. 50,000-foot flyby. But how do I go deeper? I'm interested in this, right? And I was like, that's a great question. So how do I do that? So I got an idea one day. What if I did a podcast internal to the company, deep dive with whatever experts I can find on a particular topic, record those and put them out to the company? People can watch them whenever they want. I love that. Like zero friction. It's like going to YouTube, right? I learned from YouTube videos. What do you guys— you watch YouTube videos on, you know, particular attacks? Everybody does. Everybody's. Everybody's.

33:25Chris RomeoYeah, everybody.

33:27Jet AndersonSo, I recorded 9 episodes without anybody knowing and then went to pitch it to the CISO again. And 5 minutes in, he's like, stop, I'm in. This is fantastic. When can we start? I said, I've got 9 episodes recorded. We can launch the first one this Friday. He's like, Of course, go for it. So I did 62 episodes in a row, every topic you can imagine, deep dives on SQL injection, did a 10-part series on OAuth 2 attack patterns and protections, OpenID Connect flows, you name it, we covered everything. API security, third-party security, even machine learning and artificial intelligence with Gary McGraw, super fun times. All my favorite folks, maybe not all of them, but a few of my favorite AppSec folks, right? Jim Manico, Philippe Deraike, and those folks. We had a great time. So yeah, that came to an end, but I'm really thrilled. It's kind of given me a persona, if you will. Now everybody just calls me the Code Doctor. So even still, like, Yeah, I continue to do that. And, you know, one of these days, I think it's going to be an opportunity for me to, to build that brand even further and share, share education with the masses. I'm really excited to do the work that I do, and I love it.

35:02Chris RomeoYeah, that's great. It's— I always love, like I said, I always love to hear the stories for how people have had success and, you know, kind of boiling down actionable things. And I think there's, there's a number of things there that our audience can take away if they're trying to do that. You know, it's It's using that hand-to-hand combat kind of approach of meeting with developers and teaching them a 3-hour class. It's, you know, doing some type of recorded version of it to be able to scale to the masses. Like, there's just so many cool things that, as you shared, that came out of that. So, as we kind of prepare to land the plane here, Mm-hmm. Jett, what would you say is a key takeaway slash a call to action that you'd have for our audience? Is there something you want to focus them on? And then is there something you want to give them as a homework assignment to go do something with?

35:56Jet AndersonYeah, that's a great question, Chris. You know, I think on the one hand, you've got the folks who are maybe traditional InfoSec who don't necessarily make a practice of thinking outside of the box and looking at new novel ways to solve some problems. So I'd say number one, Be willing to toss out what's not working. And you don't know everything. And be okay with that. Be willing to ask for help, be willing to, to ask your partners what works for you. And I think really, the word that you used earlier, I think is fantastic. It's empathy, right? We're all humans. And we all want to We want to do meaningful work. We don't, we don't do work for free, right? But, but if you had to do it for free, what would be the work that you would do, right? And so like, for me, I love that I get paid to do what I do. But I do do it for free in a lot of cases, you know, mentor young people, put on talks, you know, I go and speak at cons just because like, I want to share these stories. I want, especially I want Folks that are new to the industry or considering it, hey, jump in. I tried it and it worked. And I'm excited to do the work that I do. You can do it too, right? And so I think I love having those conversations with software engineers who are like, man, I'm thinking about getting into security. I'm like, oh yes, you should. Let me help you come to the dark side, right? So, you know, I think for traditional InfoSec, You know, admit that you don't know everything. Find your partners. Be willing to throw out what doesn't work. Be creative. You know, I think it was only because I was like, we got to find a way to do this and I'm not going to do it any other way if I don't, like, start a podcast. We started a podcast. I'm like, yeah, why not? Because, hey, it worked. Like, you know, and will everything work? No. There are plenty of things that I tried that didn't work. You know, some things got me in trouble and that's okay too. Like, you know, find ways that You know, toss out what doesn't work and keep doing what does and be creative and look for partners. There's a lot of opportunity out there.

38:13Chris RomeoVery cool. Well, Jett, thank you so much for sharing your experiences and your passion. You're somebody that as I'm sitting here listening to you, I'm like, this is a passionate person about development, about security, about, you know, thanks for sharing that with us and with our audience. And we look forward to a future conversation. We'll do this again. We'll just pick something else to talk about. 'Cause I wanna once again tap into that passion 'cause it's, you know, I'm all pumped up on a Friday afternoon now for, you know, going out and doing something with application security and mentoring and teaching somebody. So thanks for sharing that with us and we look forward to talking again in the future.

38:48Jet AndersonThanks for having me on the show. I look forward to doing it again. Really appreciate you guys.