James Mckee -- Developer Security

0:00Chris RomeoJames McKee is a developer, MCP-DEA, and a security advocate, CISSP, whose biggest responsibility is leading developer security practices. He sets the standards and procedures for how the practice operates and leads all client engagement efforts with regards to security. He also takes the lead in making sure the company's staff, developers specifically, are properly trained and following best practices with regard to application security. In his current position, he's responsible for the training and providing product guidance for developers across the world. James joins us to discuss offensive application security for developers, kind of a different take on a way to train developers about security. We also get into the role of security professionals in reaching outside of the security echo chamber. We hope you enjoy this conversation with James Mckee.

0:50James MckeeCoding more securely from the start saves your organization time and money while protecting yours and your customers' data. Security Journey provides hands-on secure coding training in an application sandbox that allows developers to identify, break, and fix common security vulnerabilities. Give your developers the opportunity to recognize and prevent common and emerging security issues before they become a problem. Visit securityjourney.com to try our training today.

1:18Chris RomeoHey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo. I am the CEO of Curve Ventures and also co-host of the podcast. Happy to be joined by my good friend, Robert Hurlbut. Hey, Robert.

1:48Robert HurlbutHey, Chris. Yeah, Robert Hurlbut, and I'm a principal application security architect and threat modeling lead at Acquia. And, you know, really good to be here and to talk about, again, application security, one of our favorite topics.

2:01Chris RomeoYeah, and it's been, I don't know, 6 weeks, 2 months since we've recorded one of these, and I just hope we can remember. What do we do? What do we do next? Our audience is yelling through their nonexistent microphones in their cars. Security origin story, security origin story. So, without that, without further ado, we'll jump right in. James McKee's joining us today. James, we like to jump right in and give our guests zero time to warm up. Like, we just throw you right in the deep end of the pool with what's your security origin story or how did you get into application security?

2:33James MckeeYeah. So, James McKee, we'll get to who I am and what I do. But My origin story started in college. I was a comp sci major at Murray State and had to pick a minor. So I went with the most, the longest major I could, or minor I could find that was telecommunication systems management. And in there they had a course on security. And so I sat in and I sat through it. And a lot of the people who were there were all kind of networking side people and they They walk through things like, okay, well, this is how Kerberos works and this is how Blowfish, you know, the encryption works. And all you have to know is just that it works. And I went, well, stop. I actually want to know how that works. And so spent a lot of time kind of digging into it. And I still have a copy of Bruce Schneier's Applied Cryptography sitting here from college that was kind of the book that drove me through it, right? It gave me the code behind what was going on. And so got super excited, took the minor, did my, you know, emphasis in security, graduated, went into the real world and found out that nobody wanted to hire application security people except for the government, the military, or banks. Wasn't really interested in working for any of those 3, and they end up working alongside many of those groups throughout history. But so I just went in and did software development. and did some consulting gigs and went from one place to another. And one day, I was working at one of these consulting gigs, and we had an incident that happened in one of our environments, and it was a shared environment with several of our customers. And we brought in a new customer. They had stuff that they didn't know about, and it spread from one place to another to another and ended up infecting the entire environment. And the people who were in charge said, yeah, we can't have that happen anymore. And so said, you know, you've got some experience, go figure out what's going on. Since you helped remediate this issue, you know, you've been given the blessing, you're now the cybersecurity person, go do this. And so I started doing code audits as we brought on customers to kind of clear that stuff out. And it just kind of ballooned into me realizing that there was a need to talk to development staff about the mistakes that they were making in code, right? And that kind of pushed me into doing conference speakers speaking. Now, I'm not a— by nature, I'm not a super social person in that way, right? I have no desire to be in front of a stage and talking to people. It's really kind of counter my nature. But I thought it was important enough. And that was the reason that I kind of kept doing it, kept standing up and, and doing it. It's carried me further and further and finally got to the point where I was like, hey, I'm going to do you know, 8-hour workshop on the OWASP Top 10, doing it from the kind of attacker's perspective and then showing how it's remediated in code. And I did that for a couple places and left consulting because I was getting tired of kind of moving from, you know, dumpster fire to dumpster fire, which is what you do as a consultant, and decided I was going to go work at a small startup. Well, as I went to go work at that startup, they were acquired by a larger company the day I was signing the paperwork. But I went to work for them anyway and said, hey, I'm getting ready to go out to do a conference. Would you guys like to sponsor me? And they're like, man, that's not really our thing. And I kind of explained everything that was going on. And they're like, yeah, no, we'll give you the time off, but, you know, we're not really going to sponsor you. So I went and came back and had the CISO sitting, or the de facto CISO at that time, because He didn't have the title, sitting at my desk and said, hey, you know that thing that you were just doing for the conference? Yeah, we'd like you to come do that for us. And I said, okay, well, just, you know, schedule with my manager and get everything set up. He's like, no, I don't think you understand. And so that led me down a path where for the last 5 years I've been running the application security program at Trimble, or developer security program that I like to call it. My title is now Senior Manager, Global Developer Security Program Manager, which is a really long way to say that I get to hang out with devs all day. So that's, that's the origin story. That's how we got to here. Basically, you know, there's a lot to be said for just being the person who will stick your hand up and say, yeah, I'll do it. Right?

7:12Chris RomeoYeah, we hear that a lot in AppSec people. A lot of opportunity has come as a result of either doing something that stands out or being willing to just raise your hand and say, I'll figure it out. Because when you think about like how many AppSec people do we have in our industry right now? I mean, 1,000, 2,000, like I don't know what the number is, but it's not very many people. And so, you know, your path of being kind of stepping into the role and running with it is an opportunity I think that exists for a lot more people as well.

7:47James MckeeYep, definitely.

7:50Robert HurlbutYeah, and I can relate to that about in my own career as a longtime developer and then switching over more and more to application security. There were no positions for application security. No one was really interested. So I, same thing, I was doing very similar where I was working as a developer or an architect and applying application security, developer security, helping developers write more secure code, but it wasn't really a job per se to do that. And so, you know, here we are many years later and it's certainly becoming more and more prevalent, but it's interesting to see that history and see your history as well in that.

8:31Chris RomeoYeah, and James and I met at, he's wearing the shirt right there, AppSec Village at DEF CON. He introduced my threat modeling workshop that I did for AppSec Village. And so yeah, it was really cool to, that was my first time, first time at DEF CON, first time at AppSec Village. And so that was such a cool experience just to even be a part of it. And that was a tough room to get into. Like, well, you know, that was, there was a lot of people waiting and there was a lot of, it was a tough room. So tell us a little bit about what kind of your experience at AppSec Village at DEF CON.

9:04James MckeeYeah, so I, my first DEF CON was either '22 or '23, I think at this point, I think it's '23. And I had a blast. I went and saw a lot of really interesting stuff. But the first year that they had the AppSec Village, I kind of went, no, that's exactly— I found my people. I found my tribe, right? And so I've kind of hung around there and by process of being the person who's willing to do it against sticking your hand up, Ended up becoming kind of the this MC for the the AppSec Village, and it's awesome. It's amazing to see the first from the first year that we did it. Like there was a line out the door, and it's good to see the same faces coming back and the crowd growing every year. It doesn't matter how big our space is inside DEF CON; it's always packed. And I find that really encouraging for kind of the space. Like I said, you know, whenever I left college and wanted to do this, nobody wanted to hire this. And we now see an entire generation of people who are— this is their job. And we are now in a place where people are starting to take application security seriously. I hate the way that we had to get to this point for that to happen, but It's good to see the change in it and it's good to see the kind of force of good that comes out of that really in that environment. Been very, very happy.

10:42Chris RomeoGreat experience for me too. So I did a threat modeling workshop and I had basically 50 seats for people and split those 50 into groups. And I like to do it very interactive and get people doing a lot of stuff in the room. And groups had formed on the other side of the glass shield. It was so that, yeah, that, that just gives you a little, little picture of DEF CON, right? Like, like groups had formed on the other side of the shield and people passed the materials back through to them so that they could have, there were a couple of groups while they were operating back there. And so it was, it was a great experience for me. I look forward to, to being back again in the future and, and being a part of that. You know, like you said, there's a movement, like this is, you know, our people are now at DEF CON. Like there's, there's a group of people that are passionate like we are about AppSec. And so we just, we, you know, We've got a lot more work to do. There's a lot more people to reach, but things like AppSec Village are just incredible. So that's what a great experience for people to be a part of.

11:42James MckeeYeah, no, it's one of those things. It's the double-edged sword, right? Like it's awesome to see the room filled with people who are like AppSec people, but it really kind of leads into that kind of weird space where it's like, well, are we like, I connected with you through the AppSec Village. We're both already in AppSec. Right?

12:03Chris RomeoYeah.

12:03James MckeeLike, I wonder how many of the people in that room were coming from the development side and how many people were coming from the AppSec side. And because the reality is, is to grow this in the way that we need to grow AppSec, okay, we don't need to train AppSec people. We need to take developers who have that empathy for the process and bring them over to security. And that's a lot of the kind of philosophy of how I drive into the subject of DevSec, and that's the reason I refer to it as DevSec, right? There's the idea of looking at the application, right? We can talk about how we secure the application as part of the process and, and all of that. But at the end of the day, the root of the— where the problem's originating is that developer. And so if we can help that developer kind of shift their thinking in a way that helps them to produce more secure code, we're stopping it before it ever hits a SAST or DAST scan.

13:00Chris RomeoYeah. Yeah. Let's, let's call an audible on our plan here. You know, every, every, as Mike Tyson was famous for saying, everybody has a plan until they get punched in the face. Nobody's getting punched in the face. But let's talk about that though, because we had wanted to get into this. We wanted to get into this, you know, this idea of, you know, are we still spending too much time preaching to the choir? And as we were chatting before we began recording this conversation, we talked about, you know, how long ago was it that Josh Corman had his— had the whole thing about the echo chamber and, you know, we'd get out of the echo chamber. I can't remember the exact date, but it feels like it was about 10 years ago or so, and it may be longer or less. I don't know. I'm very bad with time, but I think it was about 10 years ago. And I guess, where are we? Like, have— is the echo chamber still a reality? Is— are we still stuck in it and we don't even know it?

13:51James MckeeSo I can tell you one of the If you want to see how real the echo chamber is, go to a small conference, host a workshop teaching the OWASP Top 10. It's one of the first questions that I ask whenever you get in there is like, okay, how many people have had any training in cybersecurity? And there are maybe a couple of hands that go up. Okay. Okay. How many people know about SQL injection? And there's probably 3 or 4 hands in a room of 30. like, okay, cross-site scripting, and it goes down to 2. And then you can go through the rest of the OWASP Top 10, and you won't get a single hand. So whenever I talk about this, and I feel that we're in this space where we're talking in the echo chamber, that's what I'm comparing against. And I would love to say that that is reserved for, you know, conferences where maybe we're getting junior or mid-level developers trying to, to kind of boost their space. But I can say that I see similar things inside the business world where I'm talking to developers of the entire spectrum. And further to that point, there's, you know, there's confusion. The message has gotten muddied along the way because there was that one person who kind of went out and understood the stuff and take it back. I think about specifically one of the examples I used whenever I was at DEF CON talking about the junior dev who was going through and doing salting and hashing. You know, we went through and we're talking about this, and I was asked to do a code review because they were working on a very sensitive space because they're doing password, you know, management storage. It's like, okay, I'll sit in on it. And, you know, open up the code that he's got for the review, and he's got salt that's like statically written into the file. He's appending that to the password and then running it through a single round of SHA-256. By his understanding, he was salting and hashing that password.

15:50Robert HurlbutHmm.

15:53James MckeeHe knew that that was something that he was supposed to do, but he didn't understand the why behind it, right? Didn't understand that the reason that we use things like PDBFK or Argon2-ID is because we're trying to, you know, increase the amount of time that it takes an attacker to go after that database of passwords for reuse, right? And so without that information, it was very difficult for him to connect those pieces. And once I kind of talked through the process and say, hey, you know, these are the things that we do and the way that we want to do it. Here's the reason we don't use static salt. Here's the reason we don't do all of that. It sank in, like the message gets there. And so there's that gap that we have to cover because in some ways we've done a really good job of getting kind of that first person out into the world and getting them out so that they have that communication. Somebody, you know, got through to him and said, okay, you know, if you're working with passwords, you should be salting and hashing your passwords. But the details of why were missed. And that led to a miscommunication and eventually could have been a security problem had it not been caught.

17:00Chris RomeoYeah. And that's, you know, that's one of the things that I, as someone who has spent a lot of time educating developers about application security, product security, one of the key things is always why. So I, you know, and I learned Simon Sinek wrote a book called Start with Why, probably, you know, 10 years ago. Everything's 10 years ago for me, by the way. It's probably about 10 years ago. But it's one of those books, has nothing to do with security. It has everything to do with how you can educate people, but starting with why, especially with a developer audience, which, You know, we know developers are smart, highly analytical, you know, good attention to detail, you know, all the things, because there are traits that make people good and great developers. Those same things translate into, a developer wants to understand why. When they understand why, everything changes. Like, if that developer had really had a good understanding for why, what the outcome was going to be, then they may have had a better chance of going, taking further steps. Maybe they don't get to a full, maybe they don't get to something that you come out of the code review with no changes. But I think to your point, like, starting with why is really the key for helping developers see, because developers, there's no developer that's sitting there going, hmm, I want to create something. that's not secure. Like, that's my life goal has been to work at this company and make crappy software that's not secure. Nobody's saying that. Nobody, like, if they do, they're gone, they're getting weeded out. Like, that's an attitude that doesn't, won't exist in modern software engineering teams that are high-performing. And so, it's not, see, as soon as we realize it's not, they're not doing it on purpose, they're doing it because we haven't taken the time to teach them and explain why these things matter, and unlock their ability to really be effective there. That's on us as AppSec people, security people.

19:04Robert HurlbutSo James, one thing I was thinking about, you know, we're talking about this echo chamber and also helping developers. And I know that's one of the things that you do, work with developers quite often. A thing that I've seen, I know you've talked about it, I believe in one of the conferences, is this thing where it's sort of almost tribal knowledge of security where maybe somebody, like you said, somebody has learned about security and they may have shared something with somebody, but then 3rd and 4th, 5th generation are now picking that up and really don't have the context anymore. I experienced that in the last few years where I was talking with a developer and they said the same thing. They said, well, you know, somebody was here 2 or 3 years ago And they, they did some things and we now have their code. They're long gone. We don't really know why it works. We don't know what it's doing, but we're sort of following the same pattern and we hope it works and we hope it's current. So there's that I've seen. But also there's something I think you mentioned is the Stack Overflow cryptography. It's almost like we're certified in Stack Overflow cryptography.

20:22Chris RomeoYeah.

20:23Robert Hurlbutwhich is not a great thing. And I remember one example I've seen in code in my own experience where I was working with a team and I was a developer on the team and I saw some code that said something to the effect, sample code, do not use this in production. And it was a direct copy from Stack Overflow. It's like, oh great. And of course, yep, it was production code. And so those kinds of things, I mean, I know you've seen similar, but what are some ideas on how to help teams, developers with those kinds of situations that you can think of?

21:00James MckeeYeah, so there's, there's an interesting cross-section here, and you brought in kind of a lot of tough topics, right? And I talked a little bit about how it's important to have empathy for the development staff, right? You're working 40, 60, 80 hours on a project, and then you have somebody from information security or an AppSec person come in and go, your baby is ugly, right? Nobody wants to hear that.

21:24Robert HurlbutNo.

21:25James MckeeAnd having been on the other side of that, I'm like, yeah, I— believe me, I fully understand all the problems that we have with the software. I was there when it was written. And so, you know, there's that complicated space where I think the empathy has to be there. And it's, you know, the understanding that there are going to be those pieces of knowledge that have been tribally passed down, the salting and hashing conversation kind of being at the point of that. But the key part to me is, especially whenever you talk about, you know, the difference between like crypto exchange or security exchange and like Stack Overflow, right? They're the same forum for 2 different audiences. And so we've got one group, and Stack Overflow is notoriously bad for giving security advice. I mean, it is just the absolute bottom. And then they're like, well, we know that that's the bottom, right? So let's go over to Security Exchange and ask our questions over there. And the answers that they get are so wrought with details.

22:32Chris RomeoYeah.

22:34James Mckeeand things that are not particularly important to implementation, that are kind of the semantic portions of it, right, that it becomes confusing and it kind of turns them away. And so the talk you were talking about, the Encryption for Developers, was really my attempt to kind of bridge that gap because there are certain things that need to be understood and know. Whenever you see the initialization vector, well, what is the purpose of an initialization vector in AES? That's something that's important to know because in .NET for a long time, I don't know if it's still the case, but you could select InitializationVector.None. There's no documentation that says, hey, you should never select the setting. Right? Because it's going to output the same thing every single time, and that lowers the security of that piece. But developers go, oh, I don't know what it does, and that looks like it's going to make it work easy, and I get the same thing out every time. That's desirable, right? So as an information security professional, we have to figure out how to bridge that gap.

23:48Robert HurlbutOkay.

23:49James MckeeYou know, I've never talked to a developer in my 10 years of doing this that has said, I want to write insecure code. Nobody wants to be up at 3 o'clock in the morning because a server has been hacked. Nobody wants to receive that ticket, right? Nobody wants that. We all want to do the right thing. The trick is, is that having come from a software development background, it's always Time for turnaround, right? How long is it gonna take me to fix this issue? What are the resources that I have to do it? And what is the, the path to, you know, getting it right? And so really, you know, we can't say, okay, well, you've got a bug, go spend 8 hours doing training on this bug, and then come back and fix the issue because having production off for 8 hours isn't gonna do it.

24:44Chris RomeoRight.

24:45James MckeeAnd we can't, you know, for the life of us, we can't put the to-do in source code because the to-do follows it right into production and it stays in there for the entire life of the product.

24:55Chris RomeoRight.

24:55James MckeeMm-hmm. So we as information security professionals have to get better about pulling out the pieces of information that are right, that are important, and put the why behind it. Right. And that's really the key in that space is if we can get to the why and simplify the why, the details make sense. We're engineers at the end of the day. We revel in the fact that there are details, right? That is inherently the space that we work in. It's all about how you handle those and how you kind of measure that across that space and what you do with it.

25:33Chris RomeoGood summary. Good way to think about it here. I just, I can't stop thinking about, you know, you guys both mentioned Stack Overflow. But wait, now we have ChatGPT from OpenAI. And where is it getting—

25:48Robert HurlbutI thought about it, but I wasn't sure to mention it.

25:50Chris RomeoWe got to go there. So, where—

25:53Robert HurlbutGo there.

25:53Chris RomeoHow are they training that? So, like, I mean, I'm sure we've all probably done the same thing. We've put some code in, or we've asked ChatGPT to show us, you know, SQL injection, or we put a piece— I pasted a piece of known vulnerable code in. It had a very easy SQL injection there. And immediately it came back and said, oh, you have SQL injection here. You got to, you know, you got some problems. And so, but the question is, if you train that thing from Stack Overflow, we're in trouble because it's garbage in, garbage out, right? Like, if you put something bad into training the models or whatever, you're going to get inconsistent results or you're going to get insecure results. And so, I guess that's a coming fear. I thought Stack Overflow was bad from a coach perspective, but imagine if you have an AI that is using the wisdom of the internet to somehow provide guidance. I mean, that should keep you up at night, right?

26:56James MckeeBut it's— and here's the— so, you know, there are a lot of kind of hot takes on this, but I will say that at the end of the day, there is nothing that we can do to stop the onslaught of the coming AI, right? Anybody who has used Copilot for more than 10 minutes sees the value that's gonna come out of that. Now, there, it's not a perfect tool, but in the hands of a medium, you know, a mid to senior developer who knows the, what they're looking for and can modify the suggestions that it makes, it is reducing a lot of that space. So I don't think there's any way for us to avoid it. And so that the shifting in that becomes, well, how do we offset the danger that's presented by a tool like that? Right? You know, a saw is one type. A circular saw is a completely different type of threat in this space. Right? And OpenAI and, you know, Copilot and those type tools are really that circular saw. So we have to do the safety training further towards the beginning of the developer's, you know, lifecycle as a developer. It's making security training more important towards the beginning, getting in, talking to those junior developers, showing them why it's important, and then entrenching that knowledge and those skills at that level because these tools are going to, you know, they're going to speed up the development process. And if they don't know what to look for and they don't know these pieces, you know, there's gonna be a wealth for application security developers, you know, 15 years from now, right? Going back and correcting all of this AI-generated code that's been running in production for 15 years.

28:49Chris RomeoSo what about, so you're talking about training the junior developers, but what about training the AI? If we're going to use AI, doesn't it need to go to school for secure coding and OWASP proactive controls and secure coding guide and ingesting all the cheat sheet series from OWASP and ASVS and everything else? Like, isn't that part of the solution too?

29:11James MckeeAbsolutely. And, you know, taking, you know, let's actually take some of the projects that have gone through and figure out how to create a training set specifically saying, here is a bad code, you know, based off of a security bug, and here's how it was fixed. And now go out and find other things that look like that in that space. There's a lot of really interesting things that we can go in. I've said it since the day that I became a programmer, right? Like, the coolest thing that I've ever done is had a keyboard at my hand and a machine that I can make it do what I want. But we're rapidly approaching a new place where I get to have the keyboard and the computer gets to do what it wants.

29:55Chris RomeoRight?

29:56James MckeeAnd, and that's— and I, I say that in jest. I'm not saying that, you know, AI is going to create sentient computers or anything like that. But I'm saying, you know, ChatGPT has as much say in the code that's being written when it's coming out of Copilot as I do as a developer. I get to decide what stays.

30:14Chris RomeoRight.

30:16James MckeeBut at the crafting part, at that smithing of the code, that's where it gets its input. And if I don't know any better as part of that process, then there's that part. But you're right, we do absolutely have to start the training process. And, you know, it's kind of weird to think about, but training has to happen for both the developer and the AI, the toolset, right?

30:37Chris RomeoYeah, because if you think about The— let's take OWASP Top 10, for example. The 2021 edition was the first time injection had fallen out of the number 1 seed in as long as I can remember. I think it was back in, I don't know, maybe 2004. I don't know. I don't remember when injection wasn't in the number 1 seed. So it's not like there's a whole huge amount of innovation in the application security risks. Yes, we added SSRF, sure. But I mean, I don't necessarily need Copilot to fully understand SSRF, but if Copilot is generating code with SQL injection and cross-site scripting in it, that's something that's been around for so long that you should be able to train whatever it is that's generating that code to not use those negative patterns. And I mean, I think it's, I think it's, to your point, like it's, It's the future. Like, we can't— we can hate it, we can love it, doesn't matter. It's gonna happen. It's gonna be the— it is the trajectory that software development is on, is to use these AI-infused tools to generate code. I think we do need to ensure that whatever is happening, it is, as you know, the security lessons that we've spent 20 years learning better be baked into what this thing's putting out. Yeah.

32:04James MckeeYeah, no, and it's—

32:04Chris RomeoWe kind of went off on a bit of a tangent there. Like, you know, you can't stay away from ChatGPT. So easy to get wrapped up in it, you know, as a— and then, you know, it's gotten so much attention here in the last couple of months, so much that you can barely even get on it anymore unless you pay money. But that's, you know, that's the way things work. So I guess, James, any— like, what do you think as far as a key takeaway or a call to action? And we talked about a lot of different things in the developer security space here, but if you want to kind of summarize this, give us some takeaways, maybe give our audience a call to action, something they can do.

32:43James MckeeSo what I would say is, is that if application security or developer security is your passion, share that passion. And to be honest with you, I kind of joke about it with some people, like, this isn't an easy job. Every day I walk in, something is on fire. Right? Every Christmas break, I'm on call because something's gonna go wrong. Okay? So something has to be keeping you coming back to this job to do it, you know, day in, day out. Right? And that's, that's the passion that's part of that. And so take that passion because developers, you know, they also have a passion and passion resonates with them. Talk about the things that you're interested in. Talk about these, you know, it's, we're joking about OpenAI and the hot kind of hot buzz that it's creating. But the reality is, is that we're all kind of interested in it, right? There's a small piece of passion in that space. And even having that conversation that we just had gives us an opportunity to open the door for more conversations. We gotta break the echo chamber. I speak at developer conferences because that's where the developers are. You know, I go and do DEF CON and do the AppSec Village, and it's awesome to talk to that environment, but the message that I give there isn't about AppSec. The message that I gave at the AppSec Village during the workshop was, hey, we all know this stuff. We need to carry it out and take it to the developers. Because it doesn't make sense to sit back and run through all the stuff in a group where everybody knows where you're preaching to the choir, right? So we got to take this out and take it to the developers, have those interesting conversations, get security as something that they're thinking about as part of it. Because even, you know, that small piece, if we were to take that clip and move that somewhere, that's going to open more conversations to get people thinking about it in a different way. And so my genuine takeaway in all of this is go find a group of people that you're not used to talking to about security and share your passion.

35:00Chris RomeoYeah, GitHub says there's 26 million developers on Earth right now, and there's a lot less application security people. And so we need to, you know, there is room to influence. And so It's been a good reminder for me as well, James, just to— I spent some time attending developer conferences looking for opportunities to go. Like you said, a developer conference, you could just do a talk on the OWASP Top 10. And that's good for that audience right now because it's not like— it's like, you know, if I'm trying to get into an OWASP conference, I'm never going to submit a talk on the OWASP Top 10 unless my name's Andrew or Brian or one of the people that's releasing the new version of it, right?

35:43Robert HurlbutYeah.

35:43Chris RomeoBut at a developer conference, there's a need, there is a captive audience that will take that as information they didn't know and then be able to go and apply it. And that's really the first step. And so you've once again reminded me of the importance of getting back into the developer space versus going back deep into the echo chamber.

36:02James MckeeAnd the one thing that I would add on to that, if I can, is that whenever we talk about that, like I go to conferences and I see 3 or 4 talks on the OWASP Top 10, that's awesome. I'm glad to see that that's being done. developer conferences. But what I would love to see more than that is just pick one item off the OWASP Top 10 and do a deep dive. Like, if you want to, if you want to speak at a security conference, I say this as a— I'm one of the organizers of BSides Boulder, right? Like, if you want to do this, take one of those topics, dive deep, give them enough that they can take back. That's more than just a blurb. The OWASP Top 10 is is important. It's something that can be covered in an hour. It's something that shouldn't be covered in an hour. So yeah, that's my spiel.

36:52Chris RomeoThat's good. Yeah, that's— that used to be one of my, one of my talks I used to do, the OWASP Top 1, which was a joke all in itself. Can't we just solve injection? Please don't think about anything else. Let's just work on injection. When we solve that, then we can go to the next one. Okay, we don't need 10. It's too many.

37:11James MckeeYep.

37:12Chris RomeoOh yeah, I'm with you. Like, it is— to truly cover one of those items, an hour is a good amount of time to dive deep enough for one of those items and show some code examples so that developers can ingest what the issue is, but also see it in code and take it away. And that leads to actionable results, which is what every talk we do should be. We should be trying to get to actionable results for the people that are sitting there. Yeah, James, thank you so much for taking the time to be with us today and have this conversation. I look forward to seeing you in Vegas again this coming summer and, you know, in the halls of the AppSec Village, which will hopefully be 12 times larger space than it was last year. Last year was a big space too, but, you know, 12 times larger, I'm hoping. But—

37:59James MckeeI would love to see it time when we can get everybody in there. And thank you very much for having me. Anytime, I will be more than happy. Um, thank you for having me. It was awesome.

38:09Chris RomeoYeah, thank you.