EP268 Weaponizing the Administrative Fabric: Cloud Identity and SaaS Compromise in M Trends 2026

Security. Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here on this lovely RSA Week 2026 are, as ever, myself, Tim Peacock, Senior PM for a bunch of stuff in Google SecOps, and of course, Anton Chuvakin, 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 on our YouTube channel. youtube.com/@cloudsecpodcast. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. Anton, what are we talking about today? Is it trends? Are we doing another RSA plus trends thing? What's going on?

I really wanted to talk about the fact that we now have YouTube Shorts and switch subjects altogether and tell people that security advice in 30-second doses actually does work.

Oh, no.

And so I know I'm hijacking the topic a little bit, but It's just maybe a peculiar part of our podcast craft is that since we are on video now, we stopped making jokes about how we have faces for radio. That's one thing.

Yep.

And also, we are doing YouTube Shorts, right? So, people who have 30 seconds can experience the podcast by doing that. But now, back to the regular program. We are talking about the wonderful world of compromise incidences. We are talking about the Amtrendz report. Which is the Mandiant flagship report going back many years. I probably should have checked how many years.

Many.

And it's usually required reading because it comes from the very depth of reality.

Yes.

The depth of real breaches. And by the way, as a funny aside, I think we made this comment last time. If you learn security from incidents only, you probably would not do well. But you do need to learn security from first principles and the incidents. It's really and. There's no or here. You can't do first principles. You can't just do IR.

You cannot learn to fly a plane just by Correct.

And the same with the fireproof buildings, only from studying fires. There's physics. Physics shows up in this episode, by the way.

Physics shows up in this episode, listeners, and I even got the physics right. That's the even crazier part. But I don't want to take too long because this is a fantastic episode. I do want to mention real quick, listeners, if you are in person at RSA, Anton and I will be doing a live show from the Google booth on the show floor. You can get the schedule for that online. You can check our Twitter. We'll definitely post about when that's happening. And maybe without any further ado or further plugs for our Shorts or our in-person appearances, let's turn things over to this week's guests. Today we are joined by Kelly VanderLee, a manager of intel analysis here at Mandiant, as well as Scott Runnels, a member of the Mandiant incident response team. Kelly, Scott, thank you so much for joining us to talk about this year's MTrends report. We're delighted to coordinate the release of this episode with the release of the report the week of RSA. It's a big, exciting week for everybody. I want to start with what I thought was one of the scariest parts of the report, which is the staggering reduction in handoff time that our adversaries have managed to achieve, not that our SOC defenders have managed to achieve. Your report says that there's a reduction from 8 hours to 22 seconds. That's crazy. Imagine if a SOC achieved that, but it's adversaries achieving that. And so what's that all about and how does that change the picture for defenders?

A lot of that comes from what is likely to be just closer collaboration between 2 groups, but it's also heavily influenced by a very automated nature of that collaboration. So it's, you know, Group A gets into an environment and one of the first things they do is they deploy Group B's tooling. And at that point, because that automated nature, it drags that handoff time down so far that you're looking at a very short turnaround where the, really the number of unauthorized attackers in your environment has doubled.

So it's really a collaboration story. We should all be excited about collaboration, but not in this case.

Not in that.

And so how does this— what does this change for defenders? Do we need to rethink mean time to respond? Because, you know, if our goal is under 22 seconds, we're in, as I would say, deep doo-doo.

I think at that point it really is talking more about like the types of things you can and cannot ignore. A lot of these are coming from opportunistic attacks, so like malvertising, things like that. Those types of low-impact indicators that people might have where they say, well, I'll look at that later, those can turn into quite high-impact turnarounds when that access is effectively being given or sold to a secondary group that can go through higher-impact type of activity. So it does put a lot of downward pressure on security teams to not be able to bucket these into those high and low-impact types of events, but also it really is just like when— The clock starts ticking. Obviously, it'd be great to stop the first attacker, but it becomes more and more critical to stop once there's a second group in the environment who is looking to have much more high-impact type of consequences.

I'm getting a depressing vibe from this, and I think that it's the point you made about attacker threat groups collaborating better sometimes. And this is kind of— I know maybe if I would try to go on a limb and say, Are there lessons for defenders from this? I don't know, but tell us more about this collaboration between threat groups. So we don't think they have competing goals, but it sounds like they can work and have almost like distribution clusters for stuff. So maybe enlighten us about this bit because it puzzles me quite a bit.

I think we're seeing that their objectives do effectively align, which is like self-enrichment. A lot of these are coming through ransomware operators. So the idea of one group telling another group, if you do get into either this organization, or an organization in this vertical, or an organization with this type of revenue stream, then go ahead and deploy our things. And it doesn't mean that— when we say that 22 seconds, it really is just the time at which the secondary group has access. It's not really the time at which the secondary group is actively performing actions in the environment. It's just when they have that access. That can start in 45 minutes, could start a day later, it could start 10 seconds later. There really is not, in my opinion, a like really good metric to use to say when and when you cannot respond that way, that you do have to start treating things quite seriously, have good understanding of your environments, and be able to really understand what is and is not within your baseline. But that type of collaboration between groups, I think, is an expected outcome of really what we're seeing with high-revenue ransomware operations.

So you said that this was coming from malvertising. I think of that as background radiation of the internet. Is this a transition from that background Background radiation is kind of like a slow beta decay and is now like a hot gamma, and we need to be more worried about that background radiation.

This is such a physics example, Tim.

You're welcome. You're welcome, physics PhD. No, it's because one of our guests recommended such a good book, Atomic Accidents, and it's really been rattling around in my head for weeks now.

Unfortunately, I came up through the Department of Defense schools in the late '80s and early '90s, so I definitely don't have that kind of physics background, but I I think describing it as the background radiation of the internet is true, and that's always been the case for those low-impact type of indicators. But attackers are getting an understanding that these low-impact indicators can turn— or low-impact activity can turn into high-impact and high-reward type of consequences. Things like taking popular tools and injecting Trojans into them that Starts your initial opportunistic infection. And from there, it really is that starter gun going off. And unfortunately, that does put, like I said, that downward pressure on internal security groups to be able to respond and quickly take either blocking or even semi-destructive action of like, we're turning this system off. This system is effectively bricked. It's isolated with, say, our EDR or something like that, without first having that call to the person to say like, hey, is something going on?

Hmm. So that type of pressure is really quite distinct for, I think, internal There is also, just to expand a little bit more, there are things security teams can do proactively to think about these things. And that starts with understanding the initial infection vectors of those initial access groups. So, there are steps that you can take for browser execution to mitigate some malvertising impact. There's things that you can do to stop the click fix. Let me copy-paste the actor's command and run it.

Mm-hmm.

type of things to protect large swaths of your users who may not need to use PowerShell or the command line or things like that. Yeah. So it's not just the handoff stage where things should be thought about in terms of creating defenses. It's also, well, let's take it a step back. What are those initial infection vectors and can we tighten up around some of those things that we maybe have not prioritized previously?

You did mention advice for defenders, and does this advice go beyond do better at cyber? It has a vibe of like, do you know what would help you if you are better at cyber? And people are like, yep, yep, we agree.

Yeah, we do try to take a pretty distinct stance on just telling an entire industry, get good, It just has never worked in like the 30 or 40 years that like cyber's been around. Really what it probably does start to look like is just better collaboration. As we were going through a lot of the articles, what we started to see was a lot of the recommended actions are, you know, integrate better with your internal security teams. And to that effect, internal security teams should act as enablers to ensure that people want to work with them. You know, make sure that you are acting as an active partner to these other organizations so you don't get things like shadow IT. If there are ways that you can make sure that you're an organization that users want to come to, then you're the first stop instead of just having to find it on your own. Turning users into assets instead of like just pure risk, I think is incredibly valuable for internal security teams. And I think that helps, like threat actors are out there collaborating. I don't think it's outside the realm of expectation to expect that the organizations within your own company can collaborate as well.

So there is a particular TTP that I wanted to pick on because the report highlights this as a growing concern, and that's voice phishing. I worry about that a lot because there's literally hundreds of hours of my voice out on the internet. It would be trivial for somebody to make a fake Tim Peacock and call people up. When my parents call me unexpectedly, or when I call them unexpectedly, we ask each other like questions that come from way back in our lives that were not on the internet that we can use to know who is who. But that doesn't feel very scalable advice. So what scalable advice do you have for teams worried about voice phishing?

Sorry, before you answer, I'm kind of like, a couple of years ago when somebody tried to coin the term vishen, I was just very like, yeah, like I had this cringy kind of like reaction to it. And I kind of naively assumed that most people who fall victim to vishen have voice phishing, fine, have process breakdowns. And what they need to fix is really their security processes or their approval processes. And that was pre-GenAI. So today, is that kind of like hand-wavy general advice, be better at cyber, in this case, be better at cybersecurity process authorization approvals, is still right? Or did GenAI and cheap voice cloning change it? It's like a side question to our question.

I think it likely changes voice phishing. And I'm very much in the camp that I hate the term phishing. It very much, I think, changes it a good deal because similar to what Timothy was talking about is if someone can create that clone, it does really lower the defenses, right? If someone calls my parents and they have my voice, my parents aren't— we don't even do the ask people special questions. But a lot of the voice phishing that does occur really is just someone copying, not even going to the effect of building a GenAI version of this person's voice, but just pretending to be that person and having enough information that they can answer the questions that are kicked back to them Succinctly and close to accurate. Having a good understanding of their environment helps a lot. Understanding the kinds of things that are expected obviously helps a lot. Like I said, I think the GenAI thing is going to make it harder. It'd be one thing if, you know, when your CEO all of a sudden is calling and asking you to go pick up a whole bunch of Target gift cards, that's a difficult thing. So I think people, it's just another realm where that level of education needs to come in of like, well, the processes likely will have to change to be able to say like, okay, well, I'm gonna hang up, I'll call you back on the line that I've known you at for the last year. And then even then, an additional like degree of certainty to be added to that type of process.

So this makes sense. And I just want to start evolving this beyond this, because ultimately, you're right, but it is kind of like not the placeholder advice, but it also has the The advice have shifted quite a bit from be better, but like what you described makes sense in the age of GenAI and cheap voice cloning and, you know, potentially anybody's voice, including in an interactive manner, right? Like it wouldn't just be like a recording of that sounds like you, it would be the whole conversation, right?

Yeah.

It does have the— it has the minor freaks me out factor, but like still minor. I feel like there are many other scary things online to fall victim to. So I wanna touch on one of the possible things that is named in the report as Weaponizing the administrative fabric. Somehow it just gives me some kind of apocalyptic visions in my head. Can you explain what this is and maybe explain why it matters? Sorry for a broad, easy question. Maybe try to be trickier.

No, no. I actually really like the phrase that the authors used for that, the weaponizing the administrative fabric. Anton, when you and I were coming up, I think we're probably the older people on the call, it was the firewall is your perimeter, the edge network's your perimeter, but now identity is Part of that perimeter, and a very large part. So many things tie into it between identity and SaaS that as attackers start to see that there's so much value there, that by attacking identity, they start to get the keys to the kingdom, right? It's not really even just like, oh, I'm going after the domain controller and I'm going to dump NTDS.DIT. I'm going to get access to their whole identity infrastructure. And from there, I'll spider out into their environment, into any type of third-party integrations they might have.

Right.

It really is one of those things that is such a force multiplier for organizations to use that not unexpectedly, I think we're seeing attackers move more and more towards trying to control that as well.

That scares me more than voice phishing. That is, I am literally thinking, well, this app touches that other app, and somebody gained access to this other app in the chain. It's like a tertiary, quaternary, whatever app connected to some other app, and you have almost no way to see it as well. This stuff is devilishly hard to DNR, to monitor.

So we talked about this, I want to say 2 years ago, with Omar from the Mandiant Group, who we love and very happy to have had him on the show. At the time, it felt kind of novel, but is it more prevalent now? Is this becoming a more industry standard term, this like trusted service infrastructure? How is this evolving?

What's changed?

So interestingly, the people who are writing those articles that use that phrase, they're colleagues of Omar. So it's part of our security transformation team. 2 years ago, I'd say it was probably one of those somewhat bleeding-edge type of attack methodologies, but nowadays I think you're starting to see it's not just, say, the incredibly adept threat actors that are using it. You're starting to see it be almost democratized, right? People are, just because of the value that can be taken from it, ransomware operators are going after it, all kinds of threat actors across all types of motivations. So yeah, Definitely, Kelly can probably talk to it more as to like the actual statistics around it, but I think at least from like lived experience, we're definitely seeing it more, or, you know, seeing it included really in more of our responses.

Yeah, Kelly, say more. I saw a big head nod there. What are you thinking?

So when I think of this issue, I think of the identity aspect and how more and more compromises particularly in the cloud, don't need to use malware at all.

Hmm.

They just need the creds and the access to the apps. And as soon as they have that, they can navigate through and take what they need and cause a bunch of problems for the target organizations. There's a lot of like, it looks like living off the land and you think it's really cool, but really all it is is that they logged in so that Identifying and protecting identities and making sure that permissions are restricted as they need to be is really important. And for that integration with the third parties in your SaaS application, it is difficult to monitor because some— if like each one needs you to set up different rules to make sure that you are actually generating logs and are they feeding in and can you actually find that signal of Something bad happening before the entire thing was copied and downloaded.

So, it gives me— I'm going to coin a depressing line. There was a fairly frankly cringeworthy line that somebody else coined. Of course, mine are funny and his are cringeworthy.

Of course.

Hackers don't break in, they log in. And I really didn't like it that much, but it reflected reality. What you're describing, it's almost like hackers ask for access and they get it. Like, it's even A step before it. So it's like instead of logging in with stolen creds, somebody shows up and says, just give me real creds. And people are like, here are the creds. And that is genuinely a depressing bit of quote unquote news, even though it's not news, right?

As somebody who built cloud defense systems for many years, this is, this is not news.

Yeah.

After like many years of building graph-based technology to understand how identities can move around clouds, I'm surprised that in 2026, this is kind of like news. So why, why is it news now when us cloud people have known about this for many years? What changed that this became news?

Nothing.

Oh, okay.

I think it's the unfortunate aspect of technology that with every advancement in technology, you have to relearn all the old lessons.

Oh, bummer. Yes, I, I am the— this— we are the kind of like— I hate to be in the Old guys side, whatever. Like I'm I'm even cringing when I say that. But yeah, there are stories that go way back about some security lessons being like literally unlearned and then relearned. And there were funny examples from the previous wave of technology joking about the pre previous wave. There was somebody told me about some mobile phones having ping of death vulnerability ten years ago. It was funny ten years ago, but now I'm sure some vibe coded. apps have ping-of-death vulnerabilities. So it's the 3rd, 4th wave or something. Okay, I rambled too much. Ignore me.

This is depressing, Anton. You're depressing me.

Anything, something positive. Let's talk about North Koreans. They are cheerful, right?

Are they? No, they're not. And that's not in the questions. I want to talk about supply chain. I want to talk about supply chain because that's not depressing enough. What's going on with supply chain compromise? That's in the report this year. What's new there?

Yeah. So we hear in the news a lot about North Koreans using Trojanized packages from open source package registries and embedding them into what they bill as a, like a coding test.

Yeah.

And often they use these in social engineering engagements with developers as like, hey, check out my new app. Or, you know, if you're applying to this job, this is what the code test is gonna look like. Log in and, and write me this thing and download these dependencies, and then the dependencies come in and suddenly there's a problem. This is not new and it is not unique to North Korea, but it is still a problem. And it is a sneaky one because even if the developers in your organization are doing everything right, they can still have a compromised package come in and not really realize it until it's too late. For example, there was a campaign that we responded to where a previously benign package had had a malicious update so that when a developer went to run code using this dependency, it would automatically update itself as it was supposed to. And when that happened, it would download malware. And in one particular case, this malware, QuietVault, Also incorporated the magic of AI. It searched on the target system where it had downloaded itself to see, are there any AI command line interfaces here? Excellent. If there are, I'm going to send a prompt to ask the AI interface to run my recon for me and then send the information back to the attacker.

No way. So the malware was super lazy, looked for AI on the system, used AI on the system, To then get to the next. That's incredible.

Yeah, that's so 2026.

That's so Blade Runner. That's so like Neuromancer. That's amazing. That's sci-fi right there. I hate it.

That's the sci-fi we live in, right?

Yeah.

Also, by the way, Tim, this is 1990 sci-fi. Sorry, the '90s are back.

I think both those might be from the '80s.

Okay.

Yeah, good point.

I think they predate me, both of those. Not to give away my birthday. So, you know, talking about this kind of living off the land and abusing tools that are already present, how does the security team possibly defend against this stuff? Like, what's your advice to the DNR team for this kind of scenario?

Living off the land, and I guess there's now like living off the cloud, these are actually quite difficult to defend against. In general, I think what we want to see people doing is trying to put more and more barriers in the way of attackers by really understanding what your baseline type of activity is. Like Kelly mentioned earlier on the call, that there's probably people in your organization who simply don't need access to certain things, so there's no reason for them to have that access. Spend the time to understand their requirements and build out your systems and your infrastructure such that if you see someone from HR logging into a code repository or pushing code into a repository, That should raise alarm bells. Again, going back to that concept of really partnering with other organizations to understand what it is they do, what they need, how you can help them, and how in turn they help you. I think that's an incredibly valuable way to start identifying places that you can start to restrict those controls a little bit more. It is exceptionally difficult. I've got to have been at Mandiant now for 14 years, and I learned really early on The old phrase, any sufficiently advanced technology is indistinguishable from magic. Any sufficiently clever system administrator is indistinguishable from an attacker. We have seen system administrators do incredibly strange things. We've seen system administrators use post-exploitation kits for certain operations. Obviously knocking those down is a good idea, but also removing the types of things that other people that just aren't ever really going to need and ensuring that their accesses are quite limited. And when they start stepping out of that, alerting and then quickly responding to those tends to be the most useful way to respond.

Is this again, be better at cyber? I'm sorry, this is stuck in my head now, so I'm going to be like annoying pest and tell people that. I mean, it is this be better at cyber though advice, right?

Frankly, I think it's be better at policy.

Oh, interesting.

I don't think it's really even a be better at technology. I think it's a be better at Collaborating, be better at the soft skills, be better building those bridges. I really don't like the view in security of, we're the watchers on the wall kind of thing. You're there to make sure that they can do their jobs, not to make sure that they can't. You're there to make sure that the organization can continue on if there's a problem. It really is a collaborative job, and I think having that aspect really does tend to really move the needle. The better technology that will always come along, we'll always have improvements there. If we don't maintain that collaborative effort with the people that we're, you know, we're working with and for, I think that's where we start to fail.

Okay, so let me— this is actually quite interesting. And I obviously agree with that. There's nothing contentious about it. But can I make it probably significantly harder? Like, how would you formulate the same advice for an org where IT and security hate each other? Like, where just do be friends has already failed, and they're not friends. So, is there anything, well, apart from become friends, that can be done? Because I think the right thing is don't hate security if you're IT, don't hate IT if you're security, but it does happen, right? And in some organizations, you investigate it.

Or put differently, what are the steps to go from the circle to the rest of the owl? Like, how do we go from we hate each other to we don't hate each other?

I think it comes from the top. Executives, they set the tone. And if they see that there's an issue between, just like really any relationship, you know, if you've got kids and you see your kids are fighting, you're never— they're never likely, you know, not gonna just pull themselves out of it if it gets too bad. At some point, the executives have to sit down and say like, hey, I sign your paychecks. Like, I'm the one who sets the vision for this. The CEO gets the opportunity to set that vision and drive that company. And I need us all with our hands on the oar pulling in the same direction. If you guys aren't doing that, I'll find someone else who can, or find ways to get those organizations speaking, operating, show them that they have value that they can provide to each other. No organization gets to really set their own pace. Again, this is a collaborative effort, I think, in organizations.

And there's an added complexity to this with third parties because organizations often have outsourced their HR. They've outsourced part of their hiring process. They've outsourced outsourced their help desk. And these are critical relationships and contracts and trust-but-verify situations where organizations need to be aware of these are the rules that we want followed, these are the allowed remote access softwares, and these are not. So if any of these are used, there should be a block or rules to either alert or prevent that. So So it's not just a policy thing. It's not just a contractual human relationship thing. Those do translate into actual hard controls.

As a fun aside, something I learned from doing the show is that the phrase trust but verify rhymes in Russian.

Yes, it does. Well, I think I may have told you that a few times.

You're the one who told me.

Yeah.

I'm telling Kelly and Scott. I'm not telling you.

I know you know. People quote Reagan and they're kind of like, but Reagan explicitly said that it's like for Russians. I don't think you're all easily deterred from crimes. But I mean, my nervousness here based on Kelly's answer is that I made gentle fun of your advice sounding like be better at cyber, but we ended up with be better at leadership at the end, which is even grander scale. It's also correct. I mean, there's no— I'm not saying it's wrong. I'm just saying that people who haven't done be better at cyber and who hasn't done be better at leadership, whose IT does hate security and security hates IT, do they have a chance or are they cooked?

No, I think there's definitely a chance there. It just, it really does require that everyone is, again, everyone has their hands on an oar and they're trying to move the ship. These are not in any way simple problems to solve. These are quite complex. When you have organizations that are antagonistic to each other, The best time to fix it was probably years ago, but the second best time is now.

Yeah.

The same way that you would not allow a security organization to just ignore every alert because they're inconvenient, you can't ignore the other problems that exist in the environment that are security risks. I think taking a comprehensive and a holistic view to it to say that these types of antagonistic relationships can cause security risks that could you know, ruin the business, cause incredible delays, cause, you know, people to get laid off. I think it's really important for people to take that kind of perspective and ensure that they're, you know, doing their best to improve the environment, both, you know, culturally and from a security standpoint.

Okay, so this episode has gone from, are we worried about voice phishing, to, are we worried that our leaders hate each other? I can't think of a more wide-ranging episode we've done all year. And it kills me to do this, but I have to ask our traditional closing questions. So one, other than recommending that people read the MTrends report, do you have recommended reading for people, maybe a book about leadership? And then 2, do you have advice to help a CISO or security leader make the most of this year's report? And so I'm kind of smuggling into that second part that people should read this year's report.

So I'm going to repeat something that I said on the forecast episode of this podcast, and that is that Something that can help an organization get the buy-in from other parties is examining when other organizations have failed to apply these policies well. And those examples can come from inside the organization. We had an incident, we went down to the root cause analysis, and this policy was not in place. In order to implement these policies, these are potentially some organizational things that we have to Mm-hmm. Or it may feel less painful to use somebody else's bad day to talk through, like, this is what happened. Here are the security failures in their environment. We also have gaps in these areas. So using the lessons learned from other organizations and trending information can be helpful for emphasizing how important this is. Voice phishing was our largest initial infection vector from all of our incident So it should be something that people are paying attention to and strategizing to defend against for that reason alone, that it is becoming quite common.

I love that. That's like almost the whole National Safety Board for cyber embodied in that of let's learn from the mistakes other people are making, not just our own. I love learning from other people's mistakes, by the way, listeners. I've learned a lot from my own mistakes in life, but if I can learn from somebody else's mistake, way better.

I think Kelly has a really good point. It is incredibly valuable to spend time asking, how would we have responded in this type of situation? The question of, well, are we secure? I think is, frankly, it's almost a specious question where there really isn't a good answer to it.

Yes.

But what would happen? Going through assumed breach type of practices where you bring in a pentesting company, you give them an internal laptop, you give them credentials, and you say, okay, These are the objectives that, you know, would really hurt this company if an attacker were to get to it. Watch how they get through that and then start to see what kinds of things did you actually detect. Kelly's team puts together the, puts together by the numbers. They also put together the mapping to ATT&CK. So, and they, they rank those out. Those are incredibly valuable in my opinion, to be able to say like, would we see this? Would we see this? Like, how would we respond if, if phishing was so high? How would we respond to that if someone using built-in tooling is so prevalent, how do we detect it? Like, where does that show up in our environment? I think that's incredibly valuable. From a reading perspective, I think everyone should probably read Axelrod's Evolution of Cooperation, learn about the tit-for-tat system. It is an exceptional book that, in my opinion, too few people have read. And I think that collaboration aspect is really quite important to understand.

I think this is where a military education trumps the physics education. So the game goes to Scott for sure. That goes on my reading list right there.

Amazing. Well, Kelly, Scott, thank you both so much for joining us today. Listeners, I hope you check out the mTrends report and enjoy your week at RSA. And you can look forward to a session that Anton and I are doing at the Google Security Theater. And you can look forward to our recap episode coming out next week. Kelly, Scott, thank you so much for joining us today.

Thank you for having us.

Thank you.

And now we are out of time. Thank you very much for listening, and of course, for subscribing. Please subscribe so you can get new episodes piping hot. And if you love our content, please drop us a review on your platform of choice.

You can find this podcast on YouTube, Apple Podcasts, Spotify, or wherever you get your podcasts. Also, you can find us on our website, cloud.withgoogle.com/cloudsecurity/podcasts. You can argue with us on the Google Cloud Security Community site, You can follow us on X, x.com/cloudsecpodcast.

Tweet at us, email us, argue with us, and if we like or hate what we hear, we can invite you to the next episode.

See you on the next episode of the Cloud Security Podcast by Google.