In this episode of The Redefining CyberSecurity Podcast, join host Sean Martin and Chief Product Officer, Steve Wilson, as they explore the intricacies of developing secure AI applications and the unique challenges posed by large language models. Discover actionable insights and frameworks, including Wilson's Responsible AI Software Engineering (RAISE) framework, designed to help developers and product managers navigate the complexities of AI security.
Guest: Steve Wilson, Chief Product Officer, Exabeam [@exabeam] & Project Lead, OWASP Top 10 for Larage Language Model Applications [@owasp]
On LinkedIn | https://www.linkedin.com/in/wilsonsd/
On Twitter | https://x.com/virtualsteve
____________________________
Host: Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]
On ITSPmagazine | https://www.itspmagazine.com/sean-martin
___________________________
Episode Notes
In this episode of Redefining CyberSecurity, host Sean Martin sat down with Steve Wilson, chief product officer at Exabeam, to discuss the critical topic of secure AI development. The conversation revolved around the nuances of developing and deploying large language models (LLMs) in the field of cybersecurity.
Steve Wilson's expertise lies at the intersection of AI and cybersecurity, a point he emphasized while sharing his journey from founding the Top 10 group for large language models to authoring his new book, "The Developer's Playbook for Large Language Model Security." In this insightful discussion, Wilson and Martin explore the roles of developers and product managers in ensuring the safety and security of AI systems.
One of the key themes in the conversation is the categorization of AI applications into chatbots, co-pilots, and autonomous agents. Wilson explains that while chatbots are open-ended, interacting with users on various topics, co-pilots focus on enhancing productivity within specific domains by interacting with user data. Autonomous agents are more independent, executing tasks with minimal human intervention.
Wilson brings attention to the concept of overreliance on AI models and the associated risks. Highlighting that large language models can hallucinate or produce unreliable outputs, he stresses the importance of designing systems that account for these limitations. Product managers play a crucial role here, ensuring that AI applications are built to mitigate risks and communicate their reliability to users effectively.
The discussion also touches on the importance of security guardrails and continuous monitoring. Wilson introduces the idea of using tools akin to web app firewalls (WAF) or runtime application self-protection (RASP) to keep AI models within safe operational parameters. He mentions frameworks like Nvidia's open-source project, Nemo Guardrails, which aid developers in implementing these defenses.
Moreover, the conversation highlights the significance of testing and evaluation in AI development. Wilson parallels the education and evaluation of LLMs to training and testing a human-like system, underscoring that traditional unit tests may not suffice. Instead, flexible test cases and advanced evaluation tools are necessary. Another critical aspect Wilson discusses is the need for red teaming in AI security. By rigorously testing AI systems and exploring their vulnerabilities, organizations can better prepare for real-world threats. This proactive approach is essential for maintaining robust AI applications.
Finally, Wilson shares insights from his book, including the Responsible AI Software Engineering (RAISE) framework. This comprehensive guide offers developers and product managers practical steps to integrate secure AI practices into their workflows. With an emphasis on continuous improvement and risk management, the RAISE framework serves as a valuable resource for anyone involved in AI development.
About the Book
Large language models (LLMs) are not just shaping the trajectory of AI, they're also unveiling a new era of security challenges. This practical book takes you straight to the heart of these threats. Author Steve Wilson, chief product officer at Exabeam, focuses exclusively on LLMs, eschewing generalized AI security to delve into the unique characteristics and vulnerabilities inherent in these models.
Complete with collective wisdom gained from the creation of the OWASP Top 10 for LLMs list—a feat accomplished by more than 400 industry experts—this guide delivers real-world guidance and practical strategies to help developers and security teams grapple with the realities of LLM applications. Whether you're architecting a new application or adding AI features to an existing one, this book is your go-to resource for mastering the security landscape of the next frontier in AI.
___________________________
Sponsors
Imperva: https://itspm.ag/imperva277117988
LevelBlue: https://itspm.ag/attcybersecurity-3jdk3
___________________________
Watch this and other videos on ITSPmagazine's YouTube Channel
Redefining CyberSecurity Podcast with Sean Martin, CISSP playlist:
📺 https://www.youtube.com/playlist?list=PLnYu0psdcllS9aVGdiakVss9u7xgYDKYq
ITSPmagazine YouTube Channel:
📺 https://www.youtube.com/@itspmagazine
Be sure to share and subscribe!
___________________________
Resources
Book: "The Developer's Playbook for Large Language Model Security: Building Secure AI Applications": https://amzn.to/3ztWuc2
OWASP Top 10 for LLM: https://genai.owasp.org/
___________________________
To see and hear more Redefining CyberSecurity content on ITSPmagazine, visit:
https://www.itspmagazine.com/redefining-cybersecurity-podcast
Are you interested in sponsoring this show with an ad placement in the podcast?
Learn More 👉 https://itspm.ag/podadplc
Book | The Developer's Playbook for Large Language Model Security: Building Secure AI Applications | A Conversation with Steve Wilson | Redefining CyberSecurity with Sean Martin
Please note that this transcript was created using AI technology and may contain inaccuracies or deviations from the original audio file. The transcript is provided for informational purposes only and should not be relied upon as a substitute for the original recording, as errors may exist. At this time, we provide it “as it is,” and we hope it can be helpful for our audience.
_________________________________________
Sean Martin: [00:00:00] And hello everybody. You're very welcome to a new episode of redefining cybersecurity here on ITSP magazine. This is Sean Martin, your host. And if you listen to the show unit, you know, I get to talk to lots of cool people about lots of cool things. And today is no different. Uh, thrilled to have Steve Wilson on the show again.
How are you, Steve?
Steve Wilson: Great. Thanks for having me, Sean. Excited to be here again.
Sean Martin: Yep. Good. Good to chat with you. And we did a little preview of your session that, uh, global and, uh, I need to have you back for a deeper dive on a I what it means to do responsible development using a I. And of course, we'll touch on a bit of the O.
S. Top 10 again as well. Um, but I really want to dig into the book that you have coming out. I guess it's available now and Digital format and available soon and in print. Yeah. Look at that. Nice. That's why. So display book. Yes. Fantastic. And, [00:01:00] um, yeah, this is a topic that. That, uh, early, early years, early days of my career, I was doing app sec before it was called DevSecOps and all that fun stuff.
It's something that I want to dig into quite a bit more. So I'm thrilled to have you on again to talk through this book and what it means to securely and safely develop using AI. So we're going to get into that, but maybe a few words, uh, about what you're up to in your current role, and then we'll get into the nitty gritty.
Steve Wilson: Yeah, well, it's funny. I feel like I spend all my work time and all my hobby time on the intersection of AI and cybersecurity. So in my day job, I'm the chief product officer at Exabeam, which is a cybersecurity company that focuses on, you know, using. AI technologies to analyze the massive amounts of security data that you're streaming in from all of your systems and help you find and remediate threats.[00:02:00]
Um, and really my hobby has become, uh, large language model security. And that started when I spun up the. Top 10 group for large language models last year. We talked a little bit about that. That just blew up way faster than I thought it might have. And, um, a couple of months after starting that project, I actually got a cold email from, uh, Nicole at O'Reilly who said, hey, do you want to write a book about this?
And I've spent the last. 12 months working on that. So I'm excited to get it out.
Sean Martin: Well, that answers the first question of what was the, uh, what was the prompt or the catalyst? Uh, so clearly no lack of, uh, passion for the topic and, uh, clearly no interest or no lack of interest on the other, the other side and looking for, uh, somebody to write a book about it.
So, um, what, I don't know where to start here. Cause I think when, when we, [00:03:00] certainly when we look at, AI from a content creation perspective, um, used in sales and marketing and advertising and creating stuff like that. Um, You put a prompt out there, you get something back. It's just a different way of producing similar results to what you already do in your current role, if you will.
When we start looking at AI enabled apps, I get mixed feelings. Kind of positions on, well, it's just an app. It just happens to use a new API to get, to interact with some other service. Or, no, it's not just an app. There's a lot going on with AI as a service. And how do you, well, do you use a public service?
Are you building your own MLMs and your own models? And how are you getting the data? My perspective is it's a whole different world when you, once you [00:04:00] connect your app to AI, but I want to get your perspective on this as well.
Steve Wilson: I think the first version that's interesting is kind of where, where you immediately jumped from a use case perspective, because that's changed so dramatically in the last two years.
You know, people who've been working on AI for a long time, the AI use cases were, you know, can I do image recognition or, or things like that? So it was about recognizing things and predicting outcomes, the idea of producing new work. With an AI tool was, was just beyond the scope of possibility. And that's why we've latched onto this term, generative AI is that all of a sudden AI is building, building new things.
We can debate the term new, but it's definitely, um, creating these things. And so the way I think about it is there's, there's kind of three broad classes of applications that you get built out of large language models today. And they're [00:05:00] overlapping and. An app can have characteristics of all three, but I think it's helpful.
So first thing you think about is a chatbot, right? And chat GPT is a chatbot. It's designed to interact with the user on a wide range of topics. It's, it's driven by prompting. It sort of starts with a blank slate and the user tells it what to do. Um, those, those are interesting, but as you say, they're, they're kind of very open ended.
Um, As you go down the spectrum, they get more and more focused and maybe more focused on, on potentially business value. So the, the next one is what we term co pilots. And that term's gotten to be really popular. Um, some people, um, including Exabeam use it as part of their brand. So we have a co pilot for cyber security professionals.
Um, Microsoft is building co pilot into Microsoft. Office and the basic gist of a co pilot is [00:06:00] it's not completely open ended. It's not just working against this massive knowledge base that learned with training. It's actually interacting with you and your data to focus outcomes and trying to make you more productive.
In particular areas. And I think that's a different use case was a different set of constraints. And then there's the one that's super hot right now. And I'd say in the last few months really has boiled up as the area of research, which is autonomous agents. So in the copilot case, still primarily the human driving and the assisting in the autonomous agent case, what you're seeing more and more is You're giving the agent a goal and it's pulling the problem apart into multiple steps and trying to execute to them and get to that goal with as little human intervention as possible.
Sean Martin: It's a rare occasion where I'm taking so many notes while [00:07:00] I'm also recording the episode. There's so much to unpack here and I, I want to get into the three, but I want to go kind of go Back to you calling out that I called out a use case. And for me, there's another area that, that I think we might struggle with because, and I can't remember if I mentioned this in a previous episode, but back in the day when I was doing quality assurance, you could pretty much write a set of use cases, user stories, user scenarios, and whatnot that you could test against.
Now it might be huge and you might choose to, segmented or alternate based on priority and, and, and probability of that use case happening and the risk associated with it, basically you can, you can slice and dice a, I'll say somewhat finite set of use cases. Once you start wrapping, especially with these three, and maybe we've talked about these three in this [00:08:00] context of using AI to generate.
New data sets, new tasks and automation, new orchestration and code development and all this stuff. Um, how do we get our, can we, and if so, how do we get our hands wrapped around all the different use cases and potential outcomes that, that might come along and, and know that we're doing something that's not.
Vulnerable, harmful, right? All the other things impacts privacy, all the other stuff that we have to think about with security and privacy.
Steve Wilson: Um, I mean, I think fundamentally when you think about it, uh, there is this, this long list of things that we do with traditional software to assure the quality of it, whether it's, you know, correctness, you know, think pure QA or security with, you know, And one of the things I, I like to tell people is we can have all [00:09:00] the debates that we want about AGI and consciousness and science fiction fun stuff, but you fundamentally have to treat these systems more like people than you're probably comfortable doing because.
They react more like people. That's what they're designed to do. And what that means is that they don't always answer the same question the same way, which means I can't write one test and say, this is the answer. And if you don't give me that answer, there's a bug. Um, you start there and you realize you're dealing with something much more general, and then you.
You look at the base terminology, I'm not programming the LLM, I am training the LLM. And that means from a methodology point of view, you might want to think about the, the full cycle here as education and evaluation rather than development and testing. So I'm trying to teach the LLM to do something, and then I'm trying to evaluate how good it is at it.
And there's new sets of tools and we should get into this, but there are new sets of [00:10:00] tools that are being developed today that are, that are designed to do just that.
Sean Martin: Can we, and I'm thinking of a use case that, that, um, I came across and then it's probably been at least eight months, if not a year now that I've looked at this, but you talked about the systems looking or acting more like people than a machine perhaps. What immediately came to mind is I was evaluating some, uh, some proof of concept software.
There was new forms, some new ways to engage with potential customers, prospects, and customers, where typically you'd have a radio button list or a drop down or a yes or no, right? A toggle, uh, on or off. And then you might answer things with questions. Your name, and there might be some short form fields to fill in as well.
But what I saw in this, [00:11:00] this prototype was a lot of this stuff was entry. You, you enter blocks of text and the blocks of text would then be analyzed to determine how it interacted with you down the line, which then determine the outcome. And so in that sense, um, I guess, what, what are some of the.
Challenges. I don't know if you want to tie it back to the that's kind of like a chatbot. Basically, it's a form based chatbot, but it could potentially lead into copilot. I don't know about the last one, but how do organizations need to look at this from a development perspective? Or are there ways to put parameters on?
How this stuff works in the, the, because let's be honest, it's creating new stuff on the back end based on the stuff that the user is feeding, right, that then it uses to make decisions and perhaps automate some things on behalf of that user or behalf of the organization.
Steve Wilson: Well, I [00:12:00] think the, the thing that we look at from a development perspective, one of the core concepts of large language models is this concept of what's called attention.
And you'll, you'll hear people talk about this. There was a seminal research paper that got published by some, you know, crew at Google seven, eight years ago called attention is all you need. And it was a fundamental rethink about how you do neural networks and how you deal with basically short term memory.
And this created what we hear bantied around a lot on LLMs, which is what's called a context window. which is as you, as you're interacting with chat GPT, every question is not a new discussion. It's remembering earlier parts of the discussion. And so if you ask a particular question and you ask it first or you ask it third, you're very likely to get different answers.
And so when you think about this from a security [00:13:00] perspective, it really does hammer home how It's, it's hard to write what you would call traditional unit tests on something like this. And you know, where this, where this really leads is we are developing an industry of security tools for LLMs where people have been rethinking these problems.
And so, you know, for people who are in AppSec, they're comfortable with SAST tools and DAST tools. Um, I would say there's a, there's a lot of work doing that I'd say is very equivalent to really advanced AI enabled DAST tools that are out there. And some of them are commercial, some of them are open source.
Um, it's a very popular open source one called Garak. Uh, it's named after a character from Star Trek Deep Space Nine, I understand, from talking to the, The founder of the project, but it enables you to sort of create more flexible test cases and [00:14:00] evaluate the output out of that a little bit differently.
And I think that's really important. The other thing that we find is much like an app sec, you have things that you do at development time and things that you do at runtime. And I think at this point. The idea of truly analyzing things with static tools. Um, that's super, super hard. So you're using things like DAST, but you're also losing things that look like RASP and WAF.
So web app firewalls, runtime application protection. Um, you really, you really need things that are watching the thing run. And what this comes down to is a lot. What people talk about these days is called guardrails. And you can talk about it very generically as I'm trying to keep the LLM walled in to a particular use case and doing what it's designed to do, because it's so easy to take these things off track and, um, you know, just super simple examples.
[00:15:00] Uh, there was a car dealer hired somebody to make them a chat bot to help give out information on the cars. Um, somebody quickly hacked it to start selling someone else's cars, and then they hacked it to sell them a car for a dollar. And, um, um, You know, that was obviously not what the developer intended.
So how do you build a set of guardrails around that to keep it on track and keep it focused on what it's supposed to be doing? And so those guardrails in a lot of ways become analogous to a WAF or a RASP. And in fact, you see them implemented different ways where some of them are network level that feel very much like, um, like a next gen.
App firewall. And you actually see some companies out there that produce those that are starting to integrate in LLM features. And then you see these other kinds of guardrails frameworks that the developer would basically be plugging into the code, but writing those guardrails yourself. I show in the book [00:16:00] how you can basically like, here's where you'd kind of plug in.
Here's where you'd start to put some defenses. And I show some simple ones, but as we talked about the idea that you're going to write. A set of regular expressions to look at the what's coming in or out of this and pretend that you can really interpret it. You can't. Um, so you're going to need something much more sophisticated.
And so there are, um, you know, companies as large as Nvidia, Nvidia has an open source project called Nemo guardrails and it's open source it's free, but it's designed to help developers with those problems.
Sean Martin: Yeah. Yeah. I was going to say the, all the. Permutations, you need that, that are thinking right, quote unquote thinking, you need something to think as well.
Uh, you, you described in runtime. I'm wondering, and you described some of the things in the middle of SAST and DAST, but how important it is, is it [00:17:00] to do something at the design and architecture? point. Do we know enough to do that successfully, or do we have to experience some pain in runtime to know what, what to design away or in at, uh, at
Steve Wilson: the, it's, it's such an astute question.
And, um, I'll, I'll kind of walk through some different pieces of the answer, but, you know, having worked. Add an app sec company before, you know, I remember when the rally turned into shift left, you know, we're going to do, we're going to do everything left. We're going to do it early. Um, and I think that mantra actually hurt app sec because it got to this idea that you don't need to think about it through the full life cycle, just do testing early and you're good, I think that was, that was a miserable failure, but I think if, if instead of saying shift left, you just say, start early.
And that doesn't mean that you're only doing things at one point. Start early [00:18:00] does start all the way back at product management. And, um, you know, I've been a, I've been a developer since I was a kid, but I'm mostly professionally, I'm a product manager now. Um, I don't write nearly as much code as I used to.
Um, and so I do think about these as product management problems. And when you look at the LLM top 10 that we developed at OWASP, A couple of these firmly start at product management discussions, and I'll give you a couple quick examples, but, um, one of them is what we call over reliance and it's the idea we've talked, um, in the past year to a lot about the idea that large language models tend to hallucinate.
They will, under certain circumstances, make up answers. And we get into the mathematics of why that happens, but it happens and it happens a lot. Um, by itself, it can actually be kind of creative and fun, but in the wrong situation, it becomes really dangerous. And it [00:19:00] actually becomes a security problem in some really interesting ways.
Security problems, safety problems. So. The concept of overreliance has to do with have we designed the system in a way with capabilities that fit with its ability to actually deliver from a li reliability point of view? 'cause these things are not gonna be a hundred percent reliable. So from a product management perspective, how do I find use cases?
Where I can deal with that, mitigate it, minimize it. How do I communicate with the users? What my level of certainty is around these things and what kind of things can they depend on from those answers? Um, the other one that that's one of my favorite ones is what's called excessive agency. And this one really is a common product management discussion, which you start with a simple version of something users get excited about the capability.
And you say that I'm going to I'm going to add more. Right? So it's 1. [00:20:00] 1 case might be produce a copilot for your financial analysis. to look at your stock portfolio and help you find better trades. Like cool, people start to get excited about it, starts to feel good. Um, and they say, couldn't you just execute the trades for me?
And that point I'm giving the thing agency, right? I'm giving it a goal and letting it execute to it. And if the advice it gives you on the stock in great, You're still in the loop. You're the one making the decision. You're just taking some advice. If the bot goes mad and starts trading on your stock and, you know, drills you into the ground, that's really bad.
Um, the, the end case example I give of this is one that I go into in the book and I have a chapter late in the book that. That people have told me is a lot of fun, which I just break down some actual science fiction examples. We've all dealt with, um, you know, rogue A. I. s in fun movies, and so I [00:21:00] dissect a few.
And, and the obvious one to do is Hal 9000 from, uh, 2001. And, you know, spoiler alert if you haven't seen it, but Hal turns off the life support systems at the end and kills Morse to the crew. Now, there was a lot of talk in that movie where they set it up very carefully that HAL was super reliable, super debugged, had never made a problem, or made a mistake, but at some point you're going to make a mistake, and if you give it the agency to turn off the life support systems.
It just might do it. And that's a product management decision.
Sean Martin: So as developers building stuff here, we can maybe unpack this in terms of who's delivering what piece of the, of the human like system that we're trying to build. And. You talk about reliance and then excessive agency. So how, how do developers and more, [00:22:00] probably more specifically product managers, then, um, figure out how to leverage this stuff in a safe way?
Cause I, I think if you're not building the. The large language model yourself. You're using somebody else's. Are you thinking other examples of where we, we say, well, we know this, we trust this vendor, so we're going to trust their, their model, right. Yeah. That would service, um, or, and, and their data, or we were.
Using their model and we, we trust our own data. So we'll, we'll do things a little differently that we're building our own models. So I guess, is there an easy button, an easy path, or do you have to build it all yourself? And can you rely on others? And if so, how do you, how do you navigate that?
Steve Wilson: So this was, this was a big revelation, you know, sort of writing the book.
And it was one of the reasons to do it, [00:23:00] which is the reaction to the OWASP top 10 was, Was so positive, right? And just hundreds of people have hundreds of thousands of people have downloaded that and gotten a basic understanding of the risks that come with this new style of computing. And that's awesome.
Um, But actually, one of the things we see right now is security concerns scaring people away from putting any of this stuff into production because they they've learned that those risks are out there and they don't have answers. So, um, the big part of the way I structured the book is the 1st part is just making sure that you kind of understand the technology.
How does it fit together? What are the security trust boundaries? And. Make sure you kind of understand the technology, because we have people coming from different places reading the book. Some people are AppSec people trying to, you know, understand the AI technology. Some of these people are AI people who've been working on AI forever, but they've been working on back office [00:24:00] applications that never had to touch a user.
So, A lot of level setting. The middle part goes through the vulnerabilities and just goes far more in depth than the top 10 list can. But the last third of the book is really about answers. And, um, part of the book is around basically how do you build, um, build on your DevOps process? build on your DevSecOps process to include new components that you need to evaluate this new kind of software to test for it, to protect it.
And so, um, there are, there are fields which have cropped up and they call themselves things like ML ops and LLM ops, which are all designed to fit in there. And there's some really good learnings in those frameworks. But what I'm, what I'm trying to do here is give people a framework for just thinking about how do I extend that DevSecOps mindset in the ways that I need to.
And then [00:25:00] the last chapter really goes into basically a framework. That I call the responsible AI software engineering. So raise framework and, you know, it goes all the way down to a checklist of about 10 things that you've got to look at. And, um, the feedback I've gotten is when you get it reduced down to a checklist that says, okay, yeah, there's all those problems.
But if I do these 10 things. If I, if I expunged all the problems, no, some of these are hard problems, but, um, but it gives me a place where I can go start hardening this, um, start to really understand what the risks are not in the abstract, but the risks for my application. And so, you know, you brought up this thing about, you know, I'm getting somebody else's model.
What does that mean? From a risk perspective? Well, 1 of the things in the framework is how do you manage your supply chain? And it's a fundamental app set question. Fundamental here, just a different set of constraints, different set of pieces you're going to get from different places. So [00:26:00] there's practices you can carry over, but there's a.
Different set of individual tasks you need to do. And we walk through that for people. And, um, you know, we do that basically in a number of different areas. Um, we talk about what is, what is a concept like zero trust mean in an LLM world? Um, we all, we all kind of understand what zero trust means, but I tell people with the way these language models behave, right.
Today, um, treat your LLM is somewhere in between a confused deputy and an enemy sleeper agent. That's how much trust you should be giving that thing based on all the other things that are out there. So it's going to do useful work for you, but you have to treat it with skepticism. And so how do I understand where I want to put trust boundaries around that core part of my software and check what's going in and what's going out?
And how do I police that to be more comfortable with what's going on? Yeah, a
Sean Martin: lot of human based [00:27:00] checks and balances. It's been my experience in the limited stuff that I've been. Working on,
Steve Wilson: yeah, I mean,
Sean Martin: the things we do, we're not highly critical data.
Steve Wilson: I mean, one of the last things in the list there, and it's one people shouldn't overlook at all is building a red team.
And, you know, we've, we've all had red teams in cybersecurity for a long time, but, um, AI red teaming really has become its own discipline. And it's, it's shocking how much this has caught. The imagination of what's going on. I was watching a YouTube video. Um, there's basically a snippet from C SPAN from a Senate hearing and there's Senator Chuck Schumer talking about guardrails and AI red teaming.
That was not on my bingo card.
Sean Martin: Uh, yeah, it's catching the attention of a lot of folks. Um, [00:28:00] I presume the book, you kind of alluded to it, that it can help product managers and architects and designers and developers and testers and pen testers, um, kind of get a grasp for things they need to think about. Um, I'm wondering, do you feel we're in a position and can the book help guide organizations, both with in house development teams?
And I, I imagine a lot of companies are saying we want to outsource. We don't have the expertise. So let's find an organization that can build an app for web and mobile. It's AI enabled. It does X, Y, and Z. Um, In those requirements that they provide or in vetting the, the, uh, the vendor to, to create the product for them.
Does the book help kind of say, we know enough, we have enough [00:29:00] team, we have enough tooling to pull this off or not. Cause I don't know what I'm, what I'm picturing is kind of like a, a scale of what the risk level is. And I think there's a lot of people say, we don't care. We're just going to build. And then the other is, a lot of people don't do anything, kind of what I heard you say.
And then the other is the extreme of the large large organizations that Invest to figure this all out.
Steve Wilson: Yeah. So we're, we're in a world where there's, there's two megaphones shouting in your ears, if you're involved in this stuff. And one of them is. If you're not doing gen AI today, you're a dinosaur.
You're going to get wiped out. It would be like a company in 1997 saying, I'm not going to build a website. I don't need that. That's scary. Somebody is going to steal my money if I build a website. And some of that happened, right? People's website got hacked. They lost people's credit card numbers. There were bad things that [00:30:00] happened, but.
As a company, you couldn't say, I'm not going to do the internet. Cause I haven't figured out how to do secure e commerce yet. Um, and then obviously the, the other thing that's getting shouted in your ear is there are really severe security risks. We, we don't go a week without seeing somebody having messed up and it goes from car dealer in Watsonville all the way up to Microsoft and Google messing this up, um, you know, we've seen recent examples with Microsoft co pilot and Slack where they're getting hit with.
Indirect prompt injection attacks, which are the number 1 thing that we put on the list more than a year ago and the biggest guys out there running into them. So this is real stuff. But, um, what I will say is the, the reaction to the book has been great because. When I set out to start writing it, I mean, you can see from the title, I was thinking about software developers, but it's not, it's not a code that it's not a book that wound up with a lot of code in it.
In [00:31:00] fact, there's almost none. Um, cause people are writing to so many APIs and so many frameworks and so many languages. It's more about the concepts and the feedback I've gotten, I've gotten feedback from CEOs and chief information security officers, all the way down to. Security engineers saying, Hey, I really liked this.
This gave me a framework to work from. So the, the advice I give people, you know, in the last few pages of the book is you have to go do this. You have to venture into this, go out with your eyes open that it's a, it's dangerous territory, but there are, there are big rewards out there. And the, the biggest risk is doing nothing.
So you have to venture out there, but. Start with once you're armed with the framework, you can think about things that are safe. And, you know, that's a beam. That's what we did when we came out with our copilot. There are a bunch of things that we made it not do, um, that we said we can get to later. But we came out with what we thought with a really high [00:32:00] value, low risk use cases.
And the feedback was amazing. We didn't need to do all of it to start to make a big impact where people are coming back and saying, Hey, my productivity is two or three times faster. Cause I have this, even though we know there's a bunch more we can do, but we can walk that up very gradually and make sure that we have solutions as we go.
And so that's what I tell people is venture out there. The rewards are there. Start small. Build the muscle on your team so that you have people who understand this and, um, go get your feet wet.
Sean Martin: A little MVP advice there. Minimal viable product. Product manager. That's right. I love it. Probably in your PRD as well.
Um, alright, so the book. The developer's playbook for large language model security, building secure AI apps, uh, with author Steve Wiley. Look at that, there's the book as I read it on Amazon. [00:33:00] Um, do grab a copy, a copy for the team, uh, or multiple copies for the team. So, you can start from, uh, requirements to design and architecture on through development and test and, as you pointed out, uh, the, uh, the pen test, the red teaming as well.
And. Yeah, I think you, you've shined some light on this for me as well, because I, I abandoned a project because it. Because of the risk. I'll be honest. So I don't know. Maybe we revisit it and and maybe the tooling is better now for building and testing and we'll see if we'll see if there's something there.
But a great conversation, Steve and congratulations on on getting the book out there. Ronnie is a great pub publisher and and hopefully lots of folks enjoy reading that and taking the learnings to their team.
Steve Wilson: Hey Sean, thanks a lot. I really enjoyed the conversation and Let me know if you [00:34:00] spin that project back up.
Sean Martin: It's been, it's come up a few times the last couple of weeks, so I don't know, there might be something there. We'll see. But, uh, regardless, it's been fantastic chatting with you and, uh, hopefully everybody enjoyed this conversation. Please do stay tuned, uh, for more here on redefining cybersecurity as I dig more into AppSec and, uh, SecOps and everything in between.
And please connect with Steve, grab a copy of his book and, uh, we'll see everybody. Out and about and here online. Thank you all.
Steve Wilson: Thanks, Sean.
Sean Martin: Bye.