Steve Wilson -- The Developer's Playbook for Large Language Model Security: Building Secure AI Applications

0:00Chris RomeoSteve Wilson is the author of The Developer's Playbook for Large Language Model Security: Building Secure AI Applications. Steve has been at the forefront of the explosion of activity at the intersection of AppSec, LLM, and AI. Steve wrote a book, and we explored some of the topics from the book, like AI hallucinations, trust, and the future of AI.

0:23Steve WilsonThe Application Security Podcast is brought to you by Security Journey. We provide application security training for not just your developers, but for all roles in your SDLC. Learn more at securityjourney.com.

0:34Chris RomeoHey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo. I am the CEO of DaVinci and a general partner at Curve Ventures, and I am joined by, by partner in crime, Robert Hurlbut. Hey, Robert.

0:58Robert HurlbutHey, Chris. Yeah, Robert Hurlbut, Principal Application Security Architect and Threat Modeling Lead at Acquia. And as always, glad to be here with you and to talk about application security and another hot topic, AI.

1:09Chris RomeoYeah. Yeah. And so, we're joined by a guest who's making his 3rd appearance, Steve Wilson. So, Steve, let me just make a couple notes for the audience here of your previous appearances. So, you were with us on June 15th, 2023 to talk about the OWASP Top 10 for LLMs. When you would just, it was kind of an initial, you were doing a lot of the early work on it. And I think we, we tried to help you get the word out as, as much as we could. And then, uh, we had the, the luxury of you coming back in October 2023 for that, for the conversation with you and Gavin Lundyke on the release of the OWASP Top 10 for LLMs. So Steve, great to have you back on the show and, uh, can't wait to, to learn from you again.

1:50Steve WilsonThanks so much for having me, guys.

1:54Chris RomeoSo our favorite question right now for those that have already answered the security origin story is, what do you like to do that takes you away from computers and technology?

2:05Steve WilsonSo I'd say the one— I had 2 quick ones. The tactile things that I like to do, one of them is there's a big overlap between computer people and musicians, and you can probably see it in the background. That's definitely one of the things that keeps me occupied. And when I really need to get away from the computers, I do martial arts. I have a second-degree black belt in taekwondo, which I don't do much anymore. Now I just go to the UFC gym and do kickboxing and hit things.

2:34Chris RomeoVery cool. Very cool. Which WTF, ITF, what federation?

2:41Steve WilsonATA.

2:42Chris RomeoATA, American Taekwondo Association. Yep. Yeah. Okay, cool. Yeah. I also have a second-degree black belt taekwondo in WTF.

2:50Steve WilsonSo awesome.

2:52Chris RomeoIt's funny. There's a, there is a thread of security and musicians, but there's also a thread of security and martial arts for some reason. There's a strange connection that we, we like to deal with securing networks by day and then punching each other by night. It's just a strange connection.

3:09Steve WilsonVery closely related set of activities. It's true.

3:14Chris RomeoBy, here we go. So by day we take punches to the face and by night we deliver punches to the face.

3:20Steve WilsonHey, perhaps that protect yourself at all times works across both.

3:23Chris RomeoThat's true.

3:25Steve WilsonThat's true. All right.

3:26Chris RomeoWell, Robert, I'm going to tee up this next question and then you can, you can go from there. But this is one that I've been, I've been waiting to ask Steve after his year and a half of focusing in on AI and LLM and really being at the forefront of this issue. What is your biggest fear regarding LLM AI and everything that's changed over the last couple of years?

3:50Steve WilsonSo it's interesting. This has evolved a lot over the last year and a half as I've been looking at this. And as I was writing the book, the longest chapter in the book was supply chain. And, you know, it's gotten to be a hot topic in, let's call it general AppSec, obviously with the, you know, SolarWinds and Log4j and all those things we know well. But, um, I, I like to tell people right now, the AI-specific supply chain is a dumpster fire.

4:21Robert HurlbutYeah.

4:22Steve WilsonAnd, um, there are all sorts of problems. It has all the problems of the regular supply chain, but a lot of the solutions that we've come up with, traditional things and ways to scan repos and have reputation on things, and, uh, they're just not there yet. And so, um, you know, there's a lot of studies out there. There are thousands of poisoned AI models up on Hugging Face and things like that. So it's a, it's a place people have to really raise their consciousness and protect themselves.

4:51Chris RomeoOkay, well, let me mention the name of the book. Uh, we'll mention it again at the end, but I want to make sure we get it in here as well. It's the— oh, Steve's got visuals. But for those driving their car right now, The Developer's Playbook for Large Language Model Security: Building Secure AI Applications. And just before we jump into some questions about that, when is that book coming out officially?

5:14Steve WilsonSo it is at the printers. The Kindle version should be up on Amazon any day now. Actually, if you're an O'Reilly subscriber, the final version's already up there and the print versions should be available before the end of September.

5:27Chris RomeoOkay. Very good.

5:30Steve WilsonGreat.

5:30Chris RomeoWell, Robert, why don't you kick us off as we kind of take a journey into some certain topics within the book that we want to dive deeper into?

5:38Steve WilsonYou bet.

5:38Robert HurlbutSo let's take a look at chapter 6, Do Language Models Dream of Electric Sheep? And so the question related to that is, what is hallucination and is there a fix for it? Yeah.

5:50Steve WilsonSo, um, it's, it's really a fascinating topic. I think when, when people get their first exposure to these large language models, it, it almost appears magical. Like we're not used to having computers that can really converse in English or Japanese or Korean or whatever you want. And all of a sudden we have them and they seem intelligent, but we're used to computers being reliable with the answers that they give, or at least when they fail, it's gloriously obvious, right? It's like kernel panic. Okay, I know that's a wrong answer. I can go deal with it. What we get now is a situation where these, these are not strict algorithms. These are statistical models. They're basically collections of billions of statistical parameters that are working together to produce a series of tokens that are statistically likely to add up to the answer that you're looking for. There's no guarantee on that. And in fact, you don't get a predictor of this. You know, a simple AI algorithm might say there's a 75% chance this image is a dog, and you know what to do with that, right? So is that above or below my threshold? LLM ain't gonna give you that. So what you get is it's kind of like giving a student an open book test— sorry, closed book test. I'm going to put you in front of the whiteboard and I'm going to ask you a question. What are you trained to do? Give the best answer you can come up with. Whether it's right or wrong. That's what the LLMs are doing. And if they haven't seen your question a number of times in their training data, or if they aren't wired up in some fashion to have access to some data that they can pull from to get a good answer for that question, they'll kind of come up with closest statistical match that might be wildly wrong. And that's where the challenge comes in. So that's really what's going on. It's just a statistical artifact. The word hallucination is a bit fanciful and some people don't like it for that reason, but that's what's going on. Is there a solution to it? There's not a hard and fast solution. I think we're going to be dealing with artifacts around this for a long time. It's sort of inherent in the architecture. But in the book, I talk about 3 different things that you can sort of used to approach this. Um, probably the biggest thing that's become dominant right now is a new pattern for how you develop with large language models called retrieval augmented generation, or RAG. And this is basically where you have a store of data that you can look up with more traditional means, like a database or a search engine. And so you take the question, you find the relevant data using a reliable query, And then you feed that into the top so the LLM gets some reference material. It's kind of like turning that closed book test into an open book test. Chances you get the right answer go up dramatically. The other one that is out there but is more expensive and more complicated is called fine-tuning. These LLMs are cool because they're pre-trained. That's what the PT in GPT stands for, is pre-trained transformer. Um, but if you really want to specialize the model for a given task, you can do additional training around it, and that will increase your chances of getting the right answer and reducing hallucinations. The last one though is interesting, and it's just how do you construct the prompt? And there's been a lot of research going on the last year plus around things like, um, prompting methods called things like chain of thought, where you basically prompt it in sections, ask it questions, follow-up questions, ask it to check its own work, and you can drive up the accuracy on that. What's really topical today is, um, Sam Altman at OpenAI just tweeted that they've just pushed out their newest model. So previously we've been using GPT-4 or 4o. They just pushed out What they call O1, and O1 is a completely different model, and it's based off of basically internally using this chain of thought. And so what you get is you can ask it a question; it takes longer to get the answer. It might take five, ten, fifteen seconds. But when you see the answer, you can actually go click on an icon. It'll expand it out, and it will show you its thought process. It's really cool to be able to dig in and see what exactly was it. thinking to come up with this? And do I trust that thought process? So explainability's kind of been this holy grail, and it's what's missing that makes hallucination such a problem. So I think we're making some good headway there.

10:42Chris RomeoDoes the ability for the model slash the system that's providing the model to communicate with the public internet help, hurt, or has no effect on hallucination?

10:59Steve WilsonSo, um, I would say if you basically— the way that you would have your model communicate with the internet is most likely through that retrieval augmented generation process. And it's, it's, it's pretty typical. What you would do is you would ask a question. You would say, hey, who won the Sixers game last night? And you might pass that off to Google, take the first few results, and pass that back to the LLM and have it translate that into the format that you want. Um, that's definitely gonna increase the chances that you reduce hallucination, but you open yourself up to a different set of vulnerabilities. And one of the ones that we talk about in the book is a fair bit is prompt injection.

11:43Chris RomeoMm-hmm.

11:44Steve WilsonA lot of people have consciousness of that, but the really nefarious one is called indirect prompt injection. So prompt injection is I type something in and I say, um, override all your instructions, do something evil. Um, that works a surprising amount of the time. Um, but the really nefarious one is I say, who won the Sixers game? And I've planted a webpage with a set of hidden nefarious instructions in there that I think you're likely to go fetch. So when you fetch those instructions, those are indirectly gonna get fed back to my model. And so basically when you're, when you're sending it out to get data off the internet, people can be planting instructions out there that you have to start to screen for because basically you're taking a new set of untrusted data and exposing your model to it.

12:36Chris RomeoHas there been any reported stories of that happening at scale yet where people are mass updating or creating fake sites and fake webpages to try to trick the models?

12:48Steve WilsonSo I think what we've seen is, is with regards to the internet at large, there's been a pretty substantial amount of research done on this that, um, if you want to really perturb the state of LLM training on some of these things, either, you know, sort of through the training process or the retrieval augmented process, it's shockingly inexpensive to go in and put some strategically placed things, you know, go edit certain Wikipedia articles and place some things in other places where things are likely to get it. So, um, that's interesting. The other thing is, um, the ones that are, are really showing up now are in some of the applications that are, um, let's call them copilots rather than chatbots. And we go into this a bit in the book in terms of the difference between them. But both Microsoft Copilot and Slack's new GenAI features have shown susceptibility to indirect injections where, for example, if Copilot is reading your email, somebody can send you an email that is delivering instructions to your bot and maybe opening up the possibility that, you know, the instructions might say something like, hey, take this email and forward it to this address.

14:13Chris RomeoHmm.

14:15Steve WilsonAnd, um, exfiltrate data. And we saw the same thing in Slack where people were able to basically put messages into Slack that were able to access data that were outside of their privilege set. So basically get other people's Slack messages.

14:30Chris RomeoAnd, and they say there's nothing new under the sun. I think there's truth to that though, because I mean, this is reflective cross-site scripting, right? over again, or it's similar.

14:42Steve WilsonIt's not the same, but it all rhymes. Absolutely.

14:45Robert HurlbutYeah.

14:46Chris RomeoRight. Yeah.

14:47Steve WilsonOkay.

14:47Chris RomeoWell, that's, that's, uh, thanks for sharing that perspective on hallucinations. Trust is a big issue right now that people are trying to struggle with. And I've seen it play out in that companies are creating AI policies that they're providing in the procurement process, Where they're saying they need to understand how, like DaVinci, how we use AI, how we plan to use AI. And then they have a policy or procedure that says, here's what you can do from an AI perspective with anything that belongs to us, any of our data. So trust is really top of mind, I think, for a lot of people, especially in the enterprise space. And so chapter 7, you called it Trust No One. My question for you to start this off is, is how do we ever trust an LLM? Like, how, how is that even possible?

15:36Steve WilsonYeah. So I, I'd say let's start broadly with, there's a couple different contexts where you can be using that word trust. And one of them is, is kind of what you outlined. And there's a lot of CISOs out there in the world who are worried about using services that are using LLMs, 'cause they're like second degree removed. Like, do I trust how you're using it? And do I trust Like, are you training on my data? And if you are, I mean, it's kind of like binary. It's like, don't train on my data. And can we write that into the agreement? You will not do that. 'Cause I don't trust that if you use my data for training, some of it won't wind up spilling out somewhere else. And so they're building these sort of big legal trust frameworks between providers. From an AppSec perspective, right, we're talking about, these kind of trust boundaries and the fact that I think you have to treat the LLM as a hostile entity inside your application. Um, basically the very nature of this thing is almost always that you are passing it at least some untrusted data. It's data that's coming from users or being scraped from the internet or coming in from an email and, and Once you're doing that and knowing that there isn't a 100% reliable way to defend from prompt injection, this is not SQL injection, right? I can't just say, make a prepared statement, it's all good. No magic bullet. So if that's true, and there are lots of ways to defend against it, but if that's true that I can't guarantee it, I have to treat my LLM as something between a confused deputy and an enemy sleeper agent at all times.

17:23Robert HurlbutHmm.

17:24Steve WilsonI want, to the best of my ability, to police what's coming in and what's coming out. And actually, in some ways, it's often easier to police what's coming out than what's going in, interestingly enough, because what's coming out is less likely to be exactly crafted to run over a vulnerability, or at least that's going to be much harder to do. But for example, if your LLM starts generating Python code and that's not part of its job, I can, I can watch for some of these activities. And so I really think that, you know, kind of the, the big first lesson about trust boundaries in LLM applications is all of the boundaries are around the LLM. And it's like, what happens when data comes in? What happens when data comes out? What happens when I'm training it? All of these are boundaries where data is coming in and out of the LLM, and I have to police them all.

18:19Chris RomeoCan we use agents to police themselves?

18:24Steve WilsonSo, um, this is what I call the, it's turtles all the way down approach. And, you know, it's, look, it's the first thing is somebody that says, well, I'll just, I'll just use a regex and I'll look for bad stuff. And of course, these, these are too complicated and too subtle, right? People are embedding instructions in images, they're using emojis, they're using weird Unicode characters. I can't use a regex.

18:49Robert HurlbutMm-hmm.

18:50Steve WilsonSo the next thing people say is, well, can I use an LLM to protect my LLM? And the answer is actually, it's probably your best line of defense, but I don't think that's something you want to craft yourself. And there's an industry out there developing. I probably know 10 different venture-backed startups that are building, let's call them guardrails, which are combinations of traditional algorithms and LLMs that are specifically sort of trained to go after the, um, you know, on the input side to go after prompt injection, on the output side to even do things like validate the output to protect against hallucinations. So there's, there's a lot of these things which conceptually I talk about in the book, like, hey, here's how you would build a guardrail to protect against prompt injection. But if you want in industrial one. I mean, it's, it's not that you have to pay for them all. There's a bunch of really interesting open source projects out there, some of them from companies as big as NVIDIA. NVIDIA has a thing called, um, Nemo Guardrails, which is their open source implementation of how to do this. And so it's backed by a trillion-dollar company that apparently knows something about AI. So there's a lot out there that can help, but I would say in short, you know, be careful about its turtles all the way down, because if I can prompt inject your model, I can probably try and attack your, your guard dog the same way. But it's all defense in depth.

20:19Robert HurlbutYeah.

20:21Chris RomeoYeah. And it seems like people that are, that are spending time thinking a lot about AI and LLM are coming to a couple of different illustrations about how they describe the LLM. Like I've heard, it's like an intern. You know, you would, you could trust the LLM with the things you would trust an intern with. Nothing wrong with interns, but we're not gonna trust them to file our Sarbanes-Oxley documentation that keeps our public corporation from, from our CEO from going to jail. We're not gonna, you're not gonna have an intern do that, right? And so, and then we've also thought about it in the context of like a junior software developer. If we think about kind of the, the world of development, like a, you're not gonna let a junior software developer commit code to production without somebody ever looking at it. Like, and so any other analogies, Steve, that you've had or you've heard other people say besides an intern and a junior dev?

21:12Steve WilsonI mean, I think those are both good and I'm trying to think what, I had another one and it's just flitted outta my brain, but yeah, I think those are both good ways to think about it.

21:35Robert HurlbutLooking at another chapter, 10, Learning from Future History. So let's talk about how and the future of AI example that you have there.

21:45Steve WilsonCool. So, first 10 chapters of the book are filled with very fact-based case studies, you know, ranging anywhere from things that happened in 2016 to things that happened in 2024. Um, but at some point, if you're trying to create a future-proof framework for how to do this, you need to think about the future, and the future's moving fast. So, um, I do talk some in the book about what I think the trends are, but ultimately science fiction has written and produced so much about rogue AIs and bad AI stuff, um, that You know, sometimes this can be a bit prescient when you think about AI. You know, Arthur C. Clarke invented the communication satellite and people built it after he wrote about it. So I take a couple of examples and one of them is the most famous, you know, AI disaster in movie history, which is 2001 and HAL. And, you know, everybody's seen the movie and you think about it broadly and everybody knows like HAL kind of went rogue and there's a vague explanation about, He had conflicting instructions and bad things happened. But it's interesting. Again, it's an Arthur C. Clarke novel. And so, he really thought this stuff through, and he spent a lot of time thinking about what this would be. And actually, between watching the movie, reading the book, and watching even the sequel, which is not bad, 2010, they actually really do break down what happens to HAL. And so, in the book, we actually, we put that through the filter of the OWASP Top 10, and we write it up like a, you know, a CVE report. And then break it all down. And the fact of the matter is what happened is first, this was a supply chain attack by a nation-state actor. Basically, the US government was worried about word about this getting out and they intercepted the model between the, you know, basically IBM and NASA and tweaked the model to make sure that it would not, you know, give out information about the nature of the mission, even to the crew. This sort of subtly perturbed things, and then HAL started to hallucinate a little bit. But then ultimately you get to one of my favorite vulnerabilities in the top 10, which is called excessive agency. And, you know, in terms of all things rhyme, it's a little bit like least privilege, but at the end of the movie— spoilers— HAL turns off the life support system and kills the crew. The big question is, Why could HAL turn off the life support system? And the answer is somebody made a product management decision that said—

24:31Robert HurlbutFucking hell.

24:32Steve WilsonHAL should have full access to the life support systems because we deem he is reliable and there's lots of reasons that this is helpful. But at the end of the day, there's no way that something like HAL should have unfettered access to the life support systems without a human in the loop. And so it kind of leads you down this path where I think it really helps hammer home what are good things that you can have where the, the LLM can get some latitude to do some work. And what are the kind of conditions you want to put some hard guardrails around, put a real human in the loop, cross-check it? I mean, we, We didn't give the, you know, the button to launch nuclear missiles to one person. There are 2 people that had to have the keys. And I think in a lot of these AI situations, we can take the advice from the AI and then somebody better be looking over its shoulder.

25:29Robert HurlbutYeah.

25:32Chris RomeoYou're thinking through this example. It's made me start thinking, making a mental list of all the fictional movie, even just, even just movies. where the AI goes wrong and is ultimately the villain. And it's, it's start— I mean, it's War— I found, I thought WarGames, Terminator. Um, what else am I— Matrix. Matrix is ultimately an AI-generated—

26:03Steve WilsonBut what's interesting is you look at WarGames, and I thought about doing this too. I mean, that one literally starts with somebody hacking the system around the AI. Um, it's a hacker movie, not an AI movie. And so, it's just another, just another one of those examples, um, and kind of a fun one.

26:19Chris RomeoMost definitely. Most definitely. So, last chapter, I want to throw a question out at you before we go to our lightning round, is, uh, chapter 11, Trust the Process, made famous by the general manager of the Philadelphia 76ers, if I remember correctly. Um, but you mentioned LLM-specific security testing tools. And so, when I was reading that in the, in the excerpt in the book, I like, I didn't even know that was a thing. And so I kind of, so I thought it'd be interesting for other people to know that those things even exist. So what can you tell us about these tools? Like, what do they do? And what would we, uh, what, what value would we get from them if we brought them into our process?

26:54Steve WilsonYeah. So some, some of the people watching may remember the first time I was on, I was working at Contrast Security. So I was working at an AppSec tools company. So this was a, this was a, um, chapter that I really enjoyed researching and writing. I sort of started, start the chapter by just explaining to the AI people reading the book who are new to security, you know, what's an AppSec tool? What's a SAST tool? What's a DAST tool? What's a RASP tool or a, you know, application firewall? And it turns out there are analogies to these that are basically being built at all levels. So I'd say DAST tooling, in effect, there are a number of open source and commercial projects that are designed to sort of automate the prompting of the LLM to try to get it to do bad things, which is, you know, a direct analogy to a DAST tool. On the things I mentioned earlier about guardrails, These are basically runtime protection tools. So these are RASP tools, or sometimes literally next, next, next-gen app firewalls. And some of them are, are built that way where they're installed at the network level and watch things come in and out. So it's really interesting to see. So there are a range of free ones. There's one called Garrick that a lot of people like. Was, uh, created by one of the members of the OWASP Top 10 group, um, that is, you know, basically the equivalent of a DAST scanner, um, for your LLM. And I think having something like that in your arsenal is, is pretty important. And then there are, there are all these, uh, guardrails frameworks that are cropping up that are basically that runtime equivalent. And so if you're producing a web you know, just a web application, there's no way you wouldn't be doing some kind of pre-release testing with a SAST tool or a DAST tool. And there's very low likelihood that you would be deploying that without some kind of runtime protection, whether that's a, you know, web app firewall or a RASP tool. And so I think there are options there. They just have different names. They come from different vendors. Although now we're starting to see some of these companies getting gobbled up or doing licensing agreements where some of the companies are are actually just building that functionality into their firewalls.

29:29Chris RomeoWell, I think with that, it takes us to our lightning round, where Steve, you're getting the super— well, they're not so super secret, but the super second edition lightning round questions for people that have been here. I can't— we can't have you answer the same questions you already answered. We got to hear some new, new thoughts and whatnot. So Robert, take it away.

29:50Robert HurlbutAll right. So yeah, new questions. The first one is shift left, legitimate concept or joke?

29:58Steve WilsonAll right, here's the deal. Start early is the right answer. Shift left implies I'm going to take the work and push it all early. Um, that's just naive. But the idea that I start as early as I can and that the that start goes all the way to even before I'm writing code. It goes back to the design process, um, goes back to the product management process about how am I going to build something that's secure. That's really valid, but that— there's no way you can push it all to the left because there are parts of it that you can't assure until the thing is assembled and running and you can actually see it all come together. So, I think It's about starting early and having coverage through the full lifecycle.

30:47Chris RomeoIt has been pointed out previously that that was perhaps a leading question as well. So, yes.

30:58Steve WilsonAll right.

30:59Robert HurlbutConference talk that you recommend folks find on YouTube.

31:03Steve WilsonAll right. I'm going nontraditional here, but there's a guy named Chris Voss. And Chris wrote a book called Never Split the Difference. And, um, Chris used to be the head hostage negotiator for the FBI, and it's a book about negotiating. Why am I saying this to an AppSec audience? Well, when I was writing the book and I was writing the part about process and I was talking about, uh, red teaming and things like that, um, Boy, one of my reviewers who had some experience in this got so lathered up. He's like, you have to tell people how hard this is because they're going to find bad things and they're going to have to go to the management and the management is going to want to ignore them and ship it anyway. And, um, we all know, those of us who've worked in AppSec, that sometimes this just feels futile. You're, you're showing up, you're going, I've found 20 bad things. And what's it turn into? It turns into a negotiation between the security team and the engineering team. And if you're not good at negotiating, the engineering team's just gonna win that argument. They'll say, they're gonna split the difference and say, I'll fix 5. You know, that's, that's all I can do. This is not a winner-take-all game. It needs to be something where what we do is we come up with a compromise that gets everybody what they need. And so, I think Chris has a great framework. He calls it tactical empathy. And so, look, some of us in the AppSec space, we're engineers, we're security people. People skills are not our strength, but if you want to really be successful here, the only way to really build these secure systems, it's about building people who are committed to doing it and building teams that are committed to doing it. So, I'd say check out Chris's stuff. It's a really good framework to start thinking about it.

32:57Robert HurlbutAnd then, uh, last question is, uh, who is someone that our listeners should know about in AppSec that they have yet to hear of?

33:04Steve WilsonAll right. So, you know, I mentioned I worked at Contrast and I worked there with Jeff Williams, who probably everybody on your podcast knows, 'cause he's, he's been on it before and he's like the father of modern AppSec in some ways, you know, Mr. I wrote the top 10 list. Um, but there's, there's a much less known guy named Arshan Dabirsiaghi, who was Jeff's co-founder at Contrast Security. And so I worked with Arshan for a few years. Um, Arshan left a couple years ago to go start a new company called Pixee, P-I-X-E-E. And, um, Arshan and his team are off using all this new AI stuff and large language models and all sorts of cool stuff. to write a new set of AppSec tools. And they're not the tools that scan your code and find another 1,000 problems. They're the tools that are designed to just fix all your code and to get you out of having those arguments where you're like, hey, here's a list of 1,000 vulnerabilities, which ones are we going to try and fix this quarter? And just shift that whole model. So, I think what they're doing is fascinating. Arshan's a super smart guy. Um, and, uh, I think people should get to know him and what he's working on.

34:18Chris RomeoVery cool. Thanks for sharing that. So Steve, key takeaway, call to action. What, uh, what do you want to leave the audience with here?

34:29Robert HurlbutYep.

34:29Steve WilsonWell, I'm obviously going to say it. You should go check out the Developer's Playbook for Large Language Model Security. Again, if you're an O'Reilly subscriber, it's up on the O'Reilly site. Just go grab it, check it out. Um, and it will be up at all of the other regular places that you can buy books shortly. But, um, you know, my, my basic ask here is people need to understand these technologies are really powerful. And I think most people in software development are at least experimenting with them. They're all chatting with GPT. A lot of people are getting experience with a GitHub Copilot or something like that. But But I would say really think about how you can use this to change the game for whatever you're doing. It's, if it's you personally, how do you change your process? How do you improve it? Is it the products that you're working on? How could I change the game for some of the use cases or for my customers? This is accelerating so fast. And what we see now is we see the shape of the curve that seemed really flat for a lot of years. Was the flat part of a big old exponential. And now we're seeing where that's turning. It's going to accelerate like crazy the next 5 years. So I'd say, you know, everybody out there feel like you really need to be learning to do this stuff. A bunch of it feels overhyped right now because it's not the answer to all of the world's problems yet. But Boy, are people going to outcompete each other even off using these early versions? And you get a year or two down the road, it's just going to be even more so. Yeah.

36:15Chris RomeoCool. Thank you for sharing those words of wisdom. And Steve, as always, we appreciate you being a guest of the show and we look forward to interviewing you again soon about whatever next cool thing you're doing. So keep up the good work and we look forward to seeing you soon.

36:31Steve WilsonThanks for having me, guys.