EP168 Beyond Regular LLMs: How SecLM Enhances Security and What Teams Can Do With It
15 Apr 2024 · 33 min
In this episode of the Google Cloud Security Podcast, hosts Timothy Peacock and Anton Chuvakin interview Google Cloud security experts Umesh Shankar (Distinguished Engineer, Chief Technologist for Google Cloud Security) and Scott Kuhl (Head of Data Science Research). They introduce SecLM, a security‑focused orchestration system that is not a single LLM but a platform that combines multiple large language models, parameter‑efficient adapters (e.g., LoRA), classifiers, and other ML components. SecLM routes user requests to the most appropriate model or tool, applies persona‑specific preference alignment (e.g., threat‑intel analyst vs. SOC analyst), and can perform tasks such as question answering, large‑scale data summarization, enrichment, and cross‑system querying. The conversation covers why general‑purpose LLMs fall short for security (sensitive content, rapid knowledge turnover, out‑of‑distribution data), the architectural choices that avoid catastrophic forgetting, safety concerns like prompt‑injection, and token‑window limits. They discuss practical starter use cases (summarization of threat‑intel feeds, automated enrichment, generating actionable recommendations), early customer feedback (ease of use, reduced need for in‑context learning), and trade‑offs (potential loss of some prior knowledge, model size vs. specialization). The episode ends with recommendations for getting started, suggested reading (Google Cloud blog post, CISO‑Mandiant paper, SEI evaluation paper), and a preview of future capabilities such as privacy‑preserving, natural‑language‑to‑query translation across heterogeneous security data sources.
Chapters
Security.
Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here, as ever, are myself, Timothy Peacock, the Senior PM for Threat Detection, UEBA, and some other stuff in Google SecOps, and Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website, cloud.google.com/podcasts. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show, argue with your hosts and the rest of the Cloud Security Podcast listeners on our Google Cloud Community page. You can find the link to that in our show notes. Anton, we're talking about AI, SecLM.
Correct.
Forgetting everything in the Krebs cycle. What is this episode?
I mean, this is actually way more fun. Because it's basically a way for everybody, and I mean everybody in the world, to get access to a security-trained LLM. Actually, it's not even an LLM. It's more than that, as we learned from the episode.
It's like many or several or a system for dealing with.
Super fascinating.
Yes.
Yes. But I think this is a fun episode because it involves 2 of my favorite Googlers to work with. I've worked with both of them for years. I think they're both brilliant, and their brilliance comes through. We ask, I think, decently not stupid questions for 2 people who don't know very much about LLMs. And maybe with that, listeners, let's turn things over to today's guests. I'm delighted to introduce today's guests. Today we are joined by Umesh Shankar, a distinguished engineer, which I don't even know what level that corresponds to, some number I can't count to, Chief Technologist for Google Cloud Security, and Scott Kuhl, Head of Data Science Research here at Google Cloud. Scott, Umesh, delighted to have the two of you with us today. We're talking about teaching AI security and SecLM. What is— what does that mean? Why did we make a SecLM?
Yeah, thanks for having us on, Tim, Anton. I'd say there's two big reasons why we felt we couldn't just lean on what Google was doing overall with its general-purpose model development. So the first thing is that we found a number of cases where the general-purpose models didn't do a great job at security tasks intrinsically. And part of that is just due to the training mix. Part of that's also because some of the questions that people ask in a security context are sensitive or risky, involve things like bad code, stuff that general-purpose models tend to steer away from entirely. Oh, in fact, if you ask security questions even now to, you know, popular general-purpose models, a lot of times they'll say, you know, you should really go ask a professional, or you should go, you know, ask something that's more specialized because they don't want to kind of venture into that territory.
Or they judgmentally say, oh no, that's hacking, as if it's like a really curse word. Yeah, I had it happen to me when the model said, you're asking about hacking. Are you a bad person?
And I'm like, oh. And you're like, yes, but not for that reason.
But I can also see that, like, I wouldn't really want a general-purpose model to be implementing RSA for people. That's— that'd be rolling your own crypto. We all know that that is verboten.
Right. I would say the other big reason is that just in general, the kinds of questions people were asking, tasks that they wanted to perform, They couldn't be done by a static model, even a huge, well-trained static model, because security is changing very, very quickly. There's a zero-day vulnerability, we find out about it, you know, that model might have been trained 2 months ago, right? It's not going to know about things that just happened. That's just one of many examples, but I think a very salient one for our audience. So you, at the minimum, have to sort of augment what the core model is doing in order to get a good result. And we wanted to embody all the things that you need to do to get a good result into one system. And that's where PsychLM was born. Scott, do you want to add to that?
Yeah, absolutely. I mean, I think the interesting part was, you know, you mentioned like safety alignment and, you know, it's a big thing with the LLM space, right? This idea of like human alignment, like how do you get the LLM to act the way you want it to act so that when it interacts with humans, it does not crazy things, right? I think one interesting thing that we've noticed when interacting with security professionals is they kind of have a different view of what they want an LLM to do, right?
You're saying security professionals only have one interesting difference?
They're different than normal humans.
Yes.
I was just holding my tongue.
Sorry.
They are different than normal humans. We all agree.
How have they been different with models? No, but I mean, It's true, right?
I mean, think about it. There's all these different security personas out there, right? There's your CTI analyst, there's your SOC analyst, there's your person that's doing like CISO compliance stuff. There's all sorts of like these sort of subgenres of security. And I think they all have different needs, right? And so a lot of this stuff kind of falls out through this idea of preference alignment.
Hmm.
So like as an example, right, you have like a threat intel analyst. Because of part of their job, they need to be very nuanced about what they say and how they say it so that no one makes the wrong conclusion from their intel, right? So they want the model to be in that same mindset about like, all right, well, be very nuanced, provide all the details, make sure that you explain why you've said these things, and then, you know, somehow back it up with like a confidence rating, right?
That's the type of thing they're looking for.
So you're teaching the model to equivocate?
Yeah, effectively. To hedge, right? But it's very much different than some of the other model alignment that might be happening. On the other side of things, you have like a SOC analyst, right? If you're a SOC analyst, what you don't want to do is read through 10 pages of equivocation from the model about what you're supposed to do with some information to go do it. So like, these are like polar opposite ends of the alignment spectrum. And so yet, You know, when you think about alignment and you think about all the things that you might have read about it, you know, they think about it from a very like one-size-fits-all perspective. Okay, well, there's some notion of safety and alignment. Everybody's got to fall into it and we're going to have one model that does it and best of luck, right?
Wait a second. So in this case, I want to describe it as sort of a model with a split mind when part of it is more equivocation, part of it is more certain. So how did we make it and what can it do that a regular model cannot do? Like, this is more about some complexity in there, right? Not just a better-trained model.
Yeah. I think the key with SecLM is, I know, despite it has LM in the name, it is not a model. It's actually a system, okay? So there's an API to it. And inside that system, there's a lot going on. There are, in fact, large language models, more than one, that we use. Some are tuned by us. Some might be general purpose. They're each good at different tasks. There might be existing non-LLM machine learning models that we use for all kinds of things, classification or whatever it might be. On top of that, we look at what the user is requesting and we actually do reasoning on top of it. Okay, what kind of task is this? Or how can we break this into a number of subtasks? And based on each one, we can actually kind of route each piece to the part that's going to do it the best. And so I think that's some of how you capture that flavor and the difference in the output that you might want for different flavors of these tasks. Scott, do you want to talk more about how we did that?
I think what's really interesting is that there's this idea in the LLM space about trying to make things more efficient. And one of the major techniques— there's this whole class of techniques called parameter-efficient tuning. So it's like, what happens if I don't want to spend millions of dollars to remake or to fine-tune an LLM? Well, one thing you can do is use something like LoRA tuning. It's like low-rank adaptation to do this. It's basically like just slapping kind of an extra layer of parameters over your existing model to kind of like adjust it both ways. But you could imagine, for instance, a situation here where you have one LoRA adapter that's like your threat intel aligned LoRA adapter, right? That doesn't necessarily mean that the core tasks that it's trained on are different, right? The model itself may be trained sort of full parameter style on these sort of really core security functions, but you might use, let's say, the LoRA adapters to kind of push you in certain directions when it comes to alignment and sort of the way that you output or the way that you respond. I think one really interesting thing that like came out when we were playing around with some of the more general purpose models is like, you know, and we mentioned it in the alignment part, which is like, it'll say things to the effect of, well, you should really go talk to a security professional about this website that you're asking me about because, you know, I'm not a security professional, but it's, you know, in that same vein, you can make them provide really long answers, really short answers. And it really all comes down to preference information. And so we do leverage quite a bit of our, you know, built-in subject matter expertise at Google Cloud to basically come up with this human preference information about, all right, well, for this particular persona, those people that are working as our peers, what do they think? Which of these 2 outputs do they prefer? Like longer, shorter, more succinct, more nuanced, all these sorts of comparisons. And then we can use that to sort of drive these more specialized sort of adapters on top of the core models that we offer.
This is not at all what I thought, by the way. I sort of, like, in my mind, limited though it may be, I kind of assumed that you read a security book to the model at night and it learned something and that was it.
Baby's first bedtime rootkit.
Yeah, like a baby's first rootkit book. Yes. Like every night for a few months, you've been reading the book to a model and now it's—
And it's finally gotten to the point where it can hook some calls. It's really excited about what comes next.
Right, exactly. Thank you. But this is like, completely different. And this is eye-opening and mind-opening to me.
Yeah, baby's first exploit was not the way that we went with this one, for sure. I think it's, you know, I'll let Umesh chime in a little bit here. But so my perspective on this is that I think most people anthropomorphize the LLM and the LLM training process to a certain extent, like where they're like, well, okay, how would I go about learning this thing? Well, I'd go, you know, read some blogs, read a book, and I'd do some course material and whatever.
And certainly there's like benefit to that, right?
Like, you're getting the sequence of words and tokens that actually matter. But at the end of the day, what you really want the model to do is perform a task.
Hmm.
And the words in a book are not always equivalent to how it would output words and tokens to perform a task, right? So, as an example here, if you want to do, like, I don't know, like, event summarization, right? You have a bunch of security alerts, and you're saying, hey, can you please tell me a little bit about why these are important to And, you know, are there any kind of concerns here? Well, that random JSON structure from whatever security tooling you have is probably not in that book. The schema is not in that book. It doesn't inherently have the knowledge, so to speak. It does know the words that it might use. It knows the sequence of words to string together to explain those sort of interesting tokens that it's found. And so, really, what we're talking about here is, like, this really, really super complex sort of, like, statistical correlation prediction kind of machine under the hood. And so, you don't necessarily all get it just from, you know, books. Like, there's a lot of other things that you'll find that are really important to sort of teaching the task, so to speak.
Yeah.
I mean, one way to look at it is, have you ever worked with someone who had primarily book knowledge?
Yeah.
Right?
Yes.
Yeah. And we all have, and we all probably were that person at some point, right?
I still am.
And then you realize how big the gap is between what's been sort of codified in that way and what you have to do as part of your job.
Yeah.
Right? I mean, if you just think about what you do every day, how much of that is actually written down maybe anywhere, let alone the kind of sources we can train models on? It's not as much as you would think. And so this need to kind of do the alignment, task-specific training, tuning still very much exists. And that's a lot of where our investment goes. I do want to quickly mention, and this is going to sound like a carefully engineered mission statement because it kind of is, but I think it's useful. Our vision for SecLM is to have it be a one-stop orchestration for security AI. that delivers high-quality responses with low effort.
I want it now. This is amazing.
Yeah. Can I have it?
This is— it's not really overly engineered. It's also attractive. Maybe I am attracted to weird things, but this is really good.
That's for sure.
So that is pretty exciting.
So I want to pick at something that Scott was saying, because I think Scott is earning his honorary PM badge in this episode. And Umesh, based on that description, you might be earning your honorary PMM badge. But, but Scott, you were describing, you know, the tasks and the users so well. I want to ask a PM question, which is, what are the trade-offs inherent in that? What did we lose by going down this road? What is it worse at?
Maybe it writes worse poetry. I don't know, Tim.
Is it worse at haikus? Like, what did it lose? Or did it not lose anything? It's just better.
Absolutely. There's a concept, right? It's a very well-known concept in sort of neural nets called catastrophic forgetting, right? Loosely speaking, the way— well, okay. Well, it's well known for, well known for some of us, but I don't know that.
The model gets Alzheimer's? What are we talking about?
The idea of catastrophic forgetting is really this notion that as you continue training the model with new data, if you don't really refresh the old data, it kind of just goes away, right? Like that knowledge, so to speak, with quotes around it. There's lots of different definitions of knowledge, but it will disappear. And the way you can kind of think about it is if you're making one of these really large general purpose LLMs, you're aiming for kind of like the average case, right? Like you want it to do pretty good in a couple of tasks. There's some benchmarks that you're aiming for. You're probably tweaking it to make sure that you're doing really well on those benchmarks. And, you know, everything else is sort of like frosting on the cake, so to speak, right? Like if you can get it to also generalize to security, cool. But that's not necessarily what they're looking for. And the issue is that, like, when you try to generalize to security, there's sort of this out-of-distribution problem, right? Which is, well, okay, how much security data, like, even just from just the way that security reports are written or the way that blog posts are written for security tasks, how much of that is even in the training corpus versus everything else that's out there, right? And then you really start thinking about it and you're like, all right, well, what about my, like, super niche security products that I have, right? And the output format that it uses, or the semantics or syntax of a query language that my SIEM or SOAR platform uses, right? Like, there's probably this hugely long tail of just stuff that probably, even if the upstream more general purpose LLM saw it, it's likely not seen in any sort of significant volume to actually learn useful stuff from it, right? Or it's being sort of averaged out towards things that are more generally useful to the public.
So this is like how I don't remember the Krebs cycle.
Exactly. You don't use it, it falls out of your brain.
I don't use it. It's not useful. There's no benchmark for me to know about the Krebs cycle. Okay, sure.
So I think there's this problem that ends up happening here where we're like, all right, well, we're going to try to shove some security knowledge, particularly about things that you probably have not seen, And it's going to, because of the amount of change that's necessary there, it is kind of forcing it in some ways to forget some stuff.
Hmm.
And that happens, you know, lesser with very large models because there's sort of spare capacity, so to speak, and a little bit more with smaller models, right? So you kind of have this trade-off that ends up happening there. But this also happens very much with this alignment idea, right? If I teach it about malware, right, if I'm starting to tell it like, here's how you classify malware, take a look at all this bad code, like, it's going to kind of forget about all its sort of safety training about how not to generate malware because, frankly, it has to learn something about the way malware is created in order to actually do that classification task.
So wait a second. I think that makes sense to me. And I also want to know, you mentioned utility for security, right? So what can a team do with it today? And I think, back to my Gartner days, I think in terms of starter use cases, like I have my little hands on this SecLM thing, I got it. And what should I do? What are the first 2, 3? I mean, question answering makes sense, but anything else? What magic can it spin?
Hopefully not make a rootkit.
Yeah, besides question answering, where we're seeing people use it today, and people, I mean, including our own products that we build in cloud security, as well as third parties that we've been partnering very closely with. One big one is, I'll call it distillation and summarization of large amounts of data. I would say security has a too much information problem, right? And so what can you do about that? This is actually really leaning into one of the strengths of these language models, right? They're able to take that stuff, synthesize, summarize, and you could direct it in different ways. Sometimes it's like Here's a bunch of data, tell me basically what it's about. In other cases, you might have a specific question in mind. So it's, in a sense, it's sort of question answering, but you want it to act over a particular corpus of things, right? And so you want to extract kind of, oh, here's the slice of it that is most interesting or relevant to me. You know, we see this in things like threat intel search, right? You search for some common vulnerability, Log4j, or a certain threat actor, you could get like 50,000 results, right? I mean, Google Threat Intelligence is quite comprehensive. We have a lot of data, but then you're like, okay, but now what do I do with that, right? Where do I start to even look? We're actually finding good success using GenAI to summarize that and, and pull out the parts that you actually care about.
Can I ask a follow-up on that? I remember some time ago now, and I've forgotten it 'cause other stuff got added to what I know about on top. When I had a first look at these, I was like, oh, Could I just shove a bunch of cloud audit logs into the thing and ask it what's weird? And somebody was like, yeah, sure, but context windows. And then they told me a size for context windows that made me sad. I've recently seen context windows that are much bigger numbers. So like rough and tough, how much audit data could I put into it as an example of data size?
Scott, do you want to take that? And then I'll, I'll riff on it to a different direction.
Yeah, that's a great question.
Listeners who are listening, They both made faces at each other of, would you answer that? Would you answer that?
Absolutely. So the quick and dirty answer is that the models that we use at the moment are all kind of 32,000 tokens, where tokens you can kind of think of as words or parts of words. Kind of depends on how frequently they're used, right? But there's, you know, what can you actually fit in there really depends on how verbose your examples are. The thing I normally tell folks is that it doesn't hurt to do some preprocessing. If you already know what you're, you know, what you're looking for and roughly where you're looking for, never hurts to give some deterministic help to the model. But this is actually pretty large. All the things that are happening here in the space, getting up to like 10 million tokens, you can easily imagine that, you know, when you're going up multiple orders of magnitude in token size, you're going to get some pretty massive changes in how you can use that space to solve your problems.
Yeah. So I almost expected something. So like, I was super impressed so far. And I think summarization just doesn't trigger my magic sensors. Like summarization is interesting, but I'm assuming you're not just saying, give me 3 key ideas from these logs. Like, it's kind of an intelligent, thoughtful summarization that is security-minded. So is there an example of summarization that's like maybe more magical than just Yeah, I think adding insight is kind of the key, right?
So a lot of times you don't just want the summary. You're like, okay, tell me the summary and what should I do? That's a very, very common case, right? So that is the kind of thing that we are expecting and trying to tune the model to be good at.
Yeah, I would, I would actually say that there's like a really interesting part here where, from my perspective, Certainly part of it is like this idea of large amounts of information. I think another part of it is sort of breaking down the security silo issue.
Say more about that.
Yeah. Yeah.
Like, you know, dozens, you know, if you're a typical customer, you might have a bunch of different security tools in your portfolio, each of which has different formats. Maybe they're not that well normalized for you. It's really hard to query over them, really hard to reason over them. You're really relying pretty heavily on your human to be able to basically look at one Think about the information it's extracting, then look at the other, and then pull all that information together and make an output.
Right?
And so I think the really cool part of this is it's sort of like, you know, the magic behind it is it's able to pull from all those different sources and do that sort of combination and synthesis across this heterogeneous environment, but then also do things that, that you would normally expect to have to do sort of manually or semi-manually with like a SOAR platform, like enrichment.
Mm-hmm.
If you have a connection to a threat intel product, you can automatically enrich, you know, entities that are in here and actually have the LLM do it in a way that's smart, right? Not just, oh, well, give me enrichments on these, you know, 50 million IP addresses in here. It could instead be, well, okay, let's look at the, you know, what's going on in this sequence of events. Okay, well, given what you're seeing as the actual attack or the attack pattern that you're seeing, Then intelligently look up which entities might be involved in that type of attack and tell me some enrichments about it. And how does that affect what we should do next?
So, oh, go ahead, Umesh.
I just wanted to absolutely second what Scott was saying. I think that actually might end up being the secret superpower of gen AI in a lot of ways, is actually as the hub that's able to reason across disparate systems, which is absolutely one of the most manual and painful things that people do in many fields, but certainly in security. Today what you're seeing in a lot of the results are we can do that in SecLM over data sources and APIs that we happen to own because we're like the authority of that thing. But in the future, hopefully not in the distant future, we want that to be possible across data sources that also belong to the customer and have all that magic happen at runtime. In a completely privacy-preserving way. One of the key tools that we're developing for other reasons, but I think will be key to this, is the capability to take natural language and turn it into a query against a particular other system, right? So we do that today for our Google SecOps product, where, as with most security products, it has its own schema and it has its own query syntax. And that's something that, you know, the average user might not intrinsically be familiar with. They can be pretty extensive. And even experienced users, you know, just to know the nuance of what's the exact field name that has the thing you want.
Yeah, yeah, yeah.
It's very convenient to just say in words, like, show me all the Windows machines that exhibited this behavior in the last week.
Sure.
Right? And then boom, you get a query. So already we're seeing a lot of mileage with that. Like, Very strong customer feedback.
So I wanted to ask about feedback.
So yeah, let me just finish the thought and I'd love to talk about that. Once you have that capability across a number of systems, so imagine you have that not just for your threat intel, but wherever you happen to store your logs or your application-specific telemetry, right? Maybe even data on what kind of data protection standards you have to uphold, whatever the case might be. Once you're able to take a question, break it into subparts, and have each one in principle reach out to a different system, make a query against it to pull just the data that it needs, and then synthesize a response, that is magic, right? I wouldn't want to promise we're there today, but that's where we're aiming for. And I think That's a realistic thing that we can achieve.
I love that answer. It triggers my magic sensors. I don't know about Anton's, but I want to ask—
Yes, same, same, same. This is way better than summarize. Yeah.
Summarize is still cool though. I don't want to hurt the LLM's feelings to anthropomorphize it once again.
Yeah, it's a little 1990s, 2000s.
What's the feedback been? How are people reacting to this? What's the good word? What's the bad word? What do they hate?
What do they love? So, you know, we're still very early in our journey. And, you know, as with all these things, people start playing with it. And then, you know, that leap from playing with it to embedding in product, which we have a number of product partners that are doing just that, it takes some time to get the full feedback cycle. But in terms of what we're hearing in this early going, we're already hearing that people like the fact that it saves them having to do this work on their own. Right? They try things with models and they're like, oh, okay, the model didn't do what I wanted. All right, now I need to do in-context learning. All right, let me Go get a bunch of examples. All right, well, now I got to figure out which one to do, because if I just do the same one, the static one, every time, it doesn't really give me the results I want, and so on and so forth, right? And then your own threat intel integration. It turns out models are very sensitive to where exactly you put that information in the prompt and how you phrase it and all that stuff.
Hmm.
So already they're saying, all right, this means for me, I don't need all my teams to become expert in thing, right? This is like sort of a much more straightforward and usable API than kind of the raw model that you might otherwise use. So we've definitely seen that. And we've seen people again, use it in that product context. And now we're seeing what I'll call complementary use. So people who use our products and GenAI in our products, but want to build their own workflows and tools that complement that, that go outside that. And once you go outside, you don't have, like, the full seamless integration with the data. You need to use some other API. And SecLM is something that's very attractive to them for doing that kind of development. So we're seeing that with, like, say, managed security providers.
That for them seems kind of obvious and a huge advantage in having not just, hey, I have an LLM, but I have a special LLM that knows security in logical way. Let me ask you a strange question. And I guess I probably start too many questions on Twitter about what I learned on Twitter from people, but people assume that LLMs will become smarter and will become like, I don't know, AGI or something. So it's a little silly. So what are limitations we're seeing? Like, what are the boundaries of the LLMs that we are exploring here? Because it seems like we're not going to get to, hey, AI, secure my network kind of thing.
Or are we?
Oh, Tim, come on. You're not even on Twitter that much.
I'm willing to be surprised.
This is Umesh and I looking at each other again about who wants to go first.
I know, I know. I mean, for sure, I think to some extent your question touches on coming back to that rationale for building SecLM is we saw the limits of large language models, like the model itself. And we do see absolutely there's limitations to it. Even from a safety point of view, things like prompt injection are something you need to think about, right? So sort of architecturally, I think that there's absolutely room to run. I think another interesting direction is part of why we wanted SecLM to be a system and not a model is you need a different tool for a different job. Large language models are incredibly impressive, powerful, general, like all this great stuff. But they're not the right tool for every job. Sometimes a cheaper, faster classifier that's super well-trained to detect a certain kind of abusive content is a better tool to use than an LLM, and it might actually do a better job, not just do it faster. In other cases, you know, we're working with newer techniques like graph mining or graph neural nets, right, which might be better at problems that are structured more like graphs or time series. So, you know, we're keeping our options deliberately open to be able to synthesize everything we have at our disposal to answer those questions. So yeah, I think we are seeing some limits, but we have a way to work around that.
Okay.
The dream is definitely to just tell it to go fix all your security problems on your network, but, you know, we'll get there one step at a time.
One step at a time. I think that's a very reasonable answer. I hate to do this because this has been so much fun. We've covered so much good ground and I suspect The 4 of us could do this for another hour. I have to ask our traditional closing questions. One, do you have a recommended tip for people who are getting started with SecLM? And 2, briefly, do you have recommended reading?
Yeah, sure. So I do have some recommended reading. So there's a great blog post that Google Cloud Security put out, I don't know, now like a couple, 8, 9 months ago, I guess, when we were first really starting this journey. Has a lot of great links to kind of how we're seeing it being used in all of our different products. But I think it gives a good vision for where we're trying to go. There's, you know, a really good paper that just came out, I think, from the Google Cloud CISO Group and Mandiant talking about, you know, how AI can be used to reverse the defender's dilemma. And then, you know, really some good papers, one in particular that I've seen come out of Carnegie Mellon's Software Engineering Institute on how to evaluate LLMs for cybersecurity tasks. We are still like really, really early on, so it's very early days and there's really not that much literature about how to apply these in this space. So we're definitely much at the sort of bleeding edge, but I think there's some great options out there.
Love that.
Yeah, another, uh, just to make a plug, our session on SecLM at CloudNext is a good way to find out about the latest that's in the release. And you can also hear from one of our partners at Broadcom who's using SecLM to build features into their products and how they're using it and the benefits that they're seeing, which I think is helpful for people who are considering it. And I think, you know, I'd just like to leave people with, try it out. You know, I think one of the beauties of these APIs is we don't actually know everything it can do. We don't know the entirety of what it does well and not well. We would love to learn and to have people use it in their products or for their enterprise cases.
Well, Umesh, Scott, thank you both so much for joining us today. This was a true delight.
Yeah, my pleasure.
Yeah, thank you for having us.
And now we are at time. Thank you very much for listening and, of course, for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity, Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter, @Anton_Chuvakin and _TimPico. Tweet at us, email us, argue with us, and if you like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.
Bye.
Security.
Security.
More from Anton


EP289 Software Engineering vs. Software Craft: How Google Scalably Eliminates Classes of Vulnerabilities


EP288 CISO Tested, Board Approved: Cloud Resilience with General Mills CISO Noah Korba


EP287: Creating Trust at Global Scale with Local AI: Reken-ing with Shuman Ghosemajumder


EP286 Building an AI-pilled, solo vibe-coded, Clickhouse-based SIEM with Dan Lussier


EP285 Scaling Lessons from Leading the NSA to Defending the World with Morgan Adamski


EP284 Closest Alligator to the Canoe: How Transforming SOC Became P0 for Lloyds Bank


EP283: How Google Cloud CISO Chris Betz Uses LLMs to Defend Billions of Users from Vulnerablities


EP282: Debating Coupled or Decoupled SIEM with Alex Hurtado and Christopher Witter


EP280 Hyperscaling Cloud Security: Wiz Joins the Cloud Security Podcast by Google