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

Security.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your host here, as ever, myself, Tim Peacock, uh, Group PM on Google SecOps, and of course, Anton Chuvakin, Senior Staff in Google Cloud's Office of the CISO. You can find and subscribe to the show wherever you get your podcasts, as well as at our website, youtube.com/cloudsecuritypodcast. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. If you love the show, drop us a review on your podcasting app of choice. And if you hate the show, don't do that. Anton, what are we talking about today? Today we have a guest that I couldn't wait to get on the show.

Well, I mean, I'm going to just make a minor spoiler and say that it was a really fun episode, even if you are not a builder of companies, of new products. To me, it has some of the wisdom that was discovered through—

Wisdom.

Yeah, fine. You and your puns. Of course. Yes. It had some wisdom.

It had some wisdom.

Which was very clearly discovered in a lot of really kind of hard fights with adversity, with competitors, with sort of difficult market conditions, whatever else. He mentioned red ocean situation in the beginning. And I was, my hesitation, of course, there has to be hesitation, was that Tim is just gonna have a PM love fest with a guest. But in reality, it was me who was like gushing over how this was amazing and mind-blowing.

Yeah, listeners, Anton covered the company I was at like a decade ago, and the Anton I saw today gushing about a startup, enthralled by a VP of product—

Enthralled is pushing it.

Enthralled, maybe not. Completely different Anton than the one I remember from 12, 13 years ago. So I don't know what Google has done to this man, But, you know, Inan said one thing during the episode that I, I think is really interesting. He said people are reacting from fear, and they should. And I don't love fear-based product marketing, but I, I think he was correct about the thing he was talking about. And so maybe with these teasers of Anton having a total meltdown and there being justified fear in the world, let's welcome today's guest. Today we are joined by Inan Kostika, co-founder and VP of Product You know, we are so stoked to have you on the show. When I was in SCCPM, I have to tell you this, you were like the only company I swore I wouldn't have on the show. And now that I'm not in SCCPM, and now that you guys are at Google, I'm so excited to have you here because there are so many things I wanted to ask you about. Like, how the heck did you guys build such an amazing product so quickly? Like, is it that Wiz was just a super PM-led company. How did you have such product excellence while moving so fast? Give us the story.

Well, first, thank you for having me on the show. I love listening to it, so it's a great opportunity. Basically, Wiz has always been product-led, and I think it was also super focused on a single problem, although it's a big problem, but it was a single problem of identifying and prioritizing the most critical risks in cloud. We started, it was a very, let's call it a red ocean in the sense that there were so many cloud security tools, so many. It was, yeah, it was insane. But the ability to solve that one problem, this is essentially where we focused in the first 2, 3 years of Wiz. And that focus actually allowed us to create a product that is, you know, winning every POV because in fact, even if you had dozens of different tools securing your cloud, connecting that one tool and then seeing the top 10, you're like, okay, these are the type of findings I need to have and remediate. And that was essentially what drove the excellence. Talking about the focus, the focus was only about that. How do we identify? And every single engineer, every single PM was focusing on how to contribute to that concept of critical risks or otherwise called toxic combinations that we wanted to prioritize.

So as you were doing that, surely you had to say no to things. What was the hardest no you had to give?

So we said no so many times, especially in the beginning, because think about it, we started doing cloud security without CSPM. We focused on identifying network exposures and vulnerabilities and lateral movement, but every customer we went to came with a list of hundreds of cloud resources and cloud configuration rules that they wanted us to add. And we were— we had to say no. We had to say, listen, there are many tools that are doing CSPM. That's great. The native tools, other tools. We are focusing on identifying what truly matters. And it kept going. Like, it's not only CSPM, it's actually on every market that in the end we consolidated into the concept of the CNAPP. We started initially by saying, No. And then after a while, and that's a bit, I think, the beauty about the story, we didn't say no and that's it. We said not now. And then when we had the right capacity infrastructure, the right product view on how should we implement it, then we came back and implemented it. And then we took over that market as well.

So wait a second, CSPM, if you would have woken me up at 3:00 AM and said, what does Wiz do? I would probably CSPM. as being the strongest, the best part. But I completely forgot you didn't start with CSPM. So, this part of the story is interesting. So, and I think it complements what you said. You may say no to something and then in 2 years, you are the best at that because you said no for now and then you really focused hard on that and build the best that.

Yeah.

This is actually an interesting point about CSPM, like US CSPM. came later than say, I don't know, Evident.io or whatever it was from the earliest batch, but it became like many orders of magnitude better.

Yes.

Like we are being kind of objective here, Tim. We are objective, right? You can be objective. You're a former SEC PM.

But also I have to mention on this, like we had this saying that if we say that we are doing something, we have to be the best at it. And if we cannot be the best of it, let's say we don't do it. And this actually really focuses you and you're going back to the team and you're asking them, If we do it, can you actually be the best? And then you realize that maybe no, because we don't have enough infrastructure to do it, engineers to do it, knowledge like research to do it. And it actually helps you to focus on what you actually can be the best at.

Okay, let me ask— this is gonna sound like a really dumb question, but my PM listeners will appreciate that this is not in fact a dumb question. Why did you decide to be the best at things and not be the 80th percentile at things? Because you could do a company either way. Why did you choose the path of being the best at things and not the 80th percentile?

There are many reasons for it. And I think historically, like, we've been in companies that were good enough. And when we came to Wiz, we wanted to do something different. We wanted to sell to the Fortune 100 very early. And we set the bar at, like, at a place that Basically, we couldn't have done otherwise. And this is maybe a decision. It was a very informed decision in how we built Wiz or where we aimed with Wiz in the very first days. And that was a consequence of that. It's not the right choice for any startup anywhere, but for us at that time, especially when it's a very, as I said, a very red ocean and very hard To explain why do I need a different tool. So, being really good at that toxic combination thing and showing value immediately, that's a really good way to get a foot in the door for the Fortune 100.

Why do I need a new tool? Because this one is the best. That's a pretty straightforward answer.

Exactly.

That one thing, and you don't have a tool that does it, only Wiz.

I like that.

So, I want to actually double down on some of this and basically remind you that, well, Kind of no need to remind you of it, but your team delivered speed, you delivered clean UX, and you delivered kind of like you obtained happy clients. And to me, what I've seen again in my Gartner days, I've seen people who deliver quickly, but their stuff is kind of unfinished, or they make customers happy by the power of consulting, but then lack scale. My assessment, again, maybe not very objective, but is that you kind of delivered on all 3. It's kind of one of those—

Yeah.

These are the 3 things, pick any 2, and you picked all 3, and actually, it worked out. So, I'm still looking for some kind of a deep, dark secret about how it was achieved, whether it's a PM secret or eng secret, or maybe a marketing secret. I mean, you are also well-renowned for your marketing, which is kind of cool but tasteful. I'm thinking of soups at RSA 2024. So, if there's a secret, please tell us now. It's okay.

There is no secret. I think that basically you have to create teams that are excellent at what they do. And I feel like it's not enough to have teams that are excellent at what they do. You need to develop an operating model that actually maximizes their ability to execute. And I think that at Wiz, what we've done from very early, we created this concept of a feature team. A feature team is like ICs, an engineer, a frontend, backend, a PM. an analyst, a researcher, and then basically they collaborate on a single feature set, on a single market, and they go as deep as they need. We don't try not to move people to avoid context switches, and they need to excel at what they do, and they run together as a team. We are a very flat organization in that sense, very little management overhead, so the team decides. And in a way, I think it helped us not only to excel in one thing, it allowed us to scale scale horizontally into many, many other markets in the same model. So today we have many dozens of feature teams. But the other thing, that's the operating model on top of it. You cannot have, you know, it's not each team for itself. It's actually a very organized form of development where if you need, the infrastructure is shared, whether it's a UI, whether it's a security graph, whether everything is actually a shared infrastructure. And if one team comes up with a new construct or a new component and the next team cannot say, you know, I'm going to rebuild it for my needs because not invented here. So we eliminated the not invented here concept and we said, if you need more functionality from that infra, you go and you develop it to meet your requirements as well. And in that way, we doubled down on the same infrastructure elements again and again until they became excellent and then they were Like basically usable across a tool. The operating model behind it says that you need to run a very tight ship behind it. So you need to identify, you need to be very focused on identifying the forks and then say, uh-uh, you cannot go that way. Let's remerge. And now you need to use that infra. So I think this feature team flat organization alongside the operating model to herd all of the feature teams, and we keep doing it until today. This is maybe if you're looking for a secret, I don't think it's a secret, but that's maybe what can explain the excellence across so many areas.

I mean, I got to say, I feel like back in the day when I was on SCC, I felt like every time I turned around, Wiz had another cloud covered. And I was like, how do they keep adding new clouds? How is this possible? And so this at least makes me feel a little better about that experience I had. I want to touch on the graph. You mentioned the graph. Obviously, Wiz has crushed it with their graph. Is graph actually better or does it just look really good in demos? And where do we go with graph in the future? It's pretty to look at.

Yeah, I'm a big fan of a graph, but not for the reasons typically. Listen, if I look at the security graph in Wiz, it's a language. It's a language that allows us to describe cloud environments, risks, and how they relate to each other. It allows us to simplify the search for an attack path, but also to visualize it in a way that is intelligible to humans and easy to understand, even if you're not coming from security. One of the key challenges that we've had in cloud security is not necessarily how to explain the problems to the security team, but actually how to make the development teams respond to them faster.

Mm-hmm.

And I think that the ability then explain very clearly, okay, if you expose that application and you have that vulnerability and you granted that resource, that permission to this sensitive data, well, that's a toxic combination. And seeing it on a graph makes it clear immediately. And I think this concept of democratizing the deep understanding of cloud security was relying on the graph, but also the ability to describe that environment. And if we look at the AI transformation we're all going through today, so Wiz came with the— we announced, like, the agents. We have a red agent for red teaming, green agent for remediation, and a blue agent for investigation and response, like a blue team. But the first thing, when we started building these agents, we were actually thinking, okay, what is it that we have as defenders that we can benefit from that the attackers don't have, that will be really hard to replicate? What's the moat? And the moat is actually the security graph. And the first thing we had to do is to teach the agents to read the graph.

Hmm.

And this is why I think that we are now at the brink of a unique transformation in terms of security. The graph that essentially started as a way to describe risks in environments and look for attack paths and then became a layer of visualization. Now it's becoming the shared language, the shared model between agents and humans as they operate to secure environments. And that's why I think that graphs— it's not about the graph. It's actually about the ability to describe an environment in a way that is useful for so many purposes and for so many different types of users.

I think the insight that You're not just communicating to the security team, you're also communicating to the developer is really interesting. That's like a core PM insight. How did you guys realize that, that you weren't just building for the user that bought you, but the user that they're dealing with on their side?

So we ran cloud security back at Microsoft. So a bit of history. So we started as a team like 25 years ago. We had another startup, Adallom, that was acquired by Microsoft. In Microsoft, we basically ran the cloud security group. But we also had deep insights into the, let's call it, the dynamics between the cloud security teams that are essentially seeing the environments and maybe identifying what needs to be remediated or fixed. But in the end, they cannot do anything about it. They have to pick up the phone or send an email or create a Jira ticket and ask the cloud team to actually do it. And this dynamic was painful because in the end—

Miserable.

Miserable, painful.

Torturous.

Exactly. Think about it. You send a typical security team— I'm talking about 2020, right? Like today, I don't know if it's still anybody's doing it, but back in the day, you would have a list of, you know, thousands of vulnerabilities. You would export a spreadsheet and you would send a CSV to the team saying, hey, here are 3,000 vulnerabilities I want you to fix. And guess how many vulnerabilities were fixed from that list?

Zero. No, 3. I think it's 3.

3, not zero.

Okay.

No, no, no, no. They would always take the top 3. To say that they've done their duty.

They open the CSV and then they say, you need to tell me where do I need to focus? I cannot even read this. And I think this dynamic in the end, when you want to really understand cloud security, this is the core of cloud security. And we said, if we are able to solve it and actually help the security teams to drive an action, that's going to be success. So in the end, and we can talk about the product management insights, but I'm never driving products from technologies. It's always about the human and the team and the operating model behind it. And the value is in changing that operating model. So we coined the term like democratizing cloud security because we said, okay, maybe the security team, of course they are excellent, they know what they do, but we need to make sure—

In the cloud, they often don't.

Yeah, in the cloud, it's harder for them to see what's going on and prioritize. But once they do, see and prioritize, then we want them to help to drive action. And that's basically the democratization. It's not only, by the way, about the graph and visualizing the risk to the dev teams.

Mm-hmm.

It's actually about a whole role-based access model that we've built in the platform from day one that allows engineering teams to log in and see only what they own. And the security teams that are typically centralized teams, they can see everything. So it goes far beyond the experience in the product. It's like in the details of how do you explain an issue, how do you log in, how do you create permissions, and so on.

I think that reminded me of something we've been meaning to ask but never did. And that was the question of, based on your description, it does sound like some of the magic is kind of in the way you run PM, not say in engineering or sales. And even though your marketing is amazing, it isn't the secret. So back in my day when I was at startups, people would often debate whether this is a sales-led company or engineering-led company. And for some really strange reason, the PM-led company was seen as something kind of really cool, but really odd and rare. Like, it sounds like you're describing largely a PM-led company, right? Is that fair? Or is this whole system of opinion about companies just not right? What do you think, if I may ask? I'm sorry for asking the PM question, Tim.

Yeah. And I think that in the end, okay, so what's a PM-led organization? So if I'm trying to parse how to answer this, essentially, the question is, who do we go to in order to solve a problem? And in Wiz, it was the PM team, right? So first the PM team, whether it's a sales issue, whether it's an engineering issue, in the end you go to the PM team and then you basically find a solution within the product. A lot of what we have done is solving problems that are not features through the product, whether it's creating support tickets, whether it's doing documentation that is embedded into the product, whether it's driving in product trials, whether it's troubleshooting, like all All of this stuff, if you go through a product-led organization, basically these are solved as part of the platform. And then my belief is that if you solve it in the product, you basically democratize the solution. If you create documentation that is accessible to everyone in the product, you democratize the knowledge, and so on and so on. By the way, in Wiz, you can see the roadmap in the product. We have democratized the roadmap.

Wait, what?

No. Yes, you can.

The actual roadmap product is showing in the product?

No.

Exactly. You have a roadmap tracker. For real, you have a roadmap tracker. You can log in, you can see the features that are highlighted. You can track features. And you can be basically notified when they are released. You can suggest features.

Why am I the last one to know this? This is like actually a big secret.

They didn't Osborne effect themselves either, because they weren't saying buy a new thing. They're saying your thing's gonna keep getting better next week. It's incredible.

Whoa.

There's a reason I wanted to have these guys on the show.

I mean, sorry, I'm not very often sold.

Anton is like losing his mind over there.

Yeah, I'm losing my mind.

Well, we'll let Anton lose his mind over there. I want to ask another graph question. Do you see graph coming for on-prem as well? Do you think we're going to have like graph as the center of the security universe on-prem?

Yeah. Now we are actually, if you look at the history of Wiz, the easiest way to describe the evolution is through the expansion of the graph. So the graph started as a cloud one, then we expanded it to runtime describing processes, network traffic. Then we expanded it to the left, to the code, CI/CD pipelines. And now we are expanding it to SaaS, on-prem, anywhere, right? Basically, we have recently announced onboarding at Google Next. We announced onboarding SaaS platforms that are agent platforms like AgentForest, Copilot Studio. And basically they are also embedded into the graph. So now The graph describes SaaS. And on the other side, we have a runtime sensor. We have connectors to more than 200 tools that we collect assets and vulnerability and risks data from. And we basically reconstruct the graph for these environments, on-prem included.

Yeah, that sounds like a yes.

I'm still processing the fact that some people made you sign 5 NDAs and sign in blood on your first, second, and third-born children to see the roadmap. But you had it in the product.

Yes, you can.

I mean, this takes some— I haven't found my mind yet. I'm still looking for it. Sorry, but this is kind of amazing.

Nobody's broken Anton this hard in a while, so I'll ask the next question since he's unable. I want to talk about AI and agents. What do you see as the future there? You guys obviously eliminated security agents, but now we have to secure agents. So there's good irony, but where are we going here? What's the Wiz plus agent story?

I think that's a transformation that any security tool will go through now. One, we need to secure AI, whether it's agents, whether it's MCPs, whether it's AI development. So every security product will need to extend the logic in order, or the capabilities to secure their, let's call it AI estate. In Wiz, it's AI development process and the agent Or AI workloads, let's call them. And on the other end, we need to arm the security teams with agentic capabilities to run quicker than the developers and more importantly, quicker than the attackers.

Wait, wait, security run quicker than developers? Is that—

It is.

That is even possible? I mean, sorry, my mind barely recovered, but this one is like the guest on our show basically told us Ops is 10 years behind dev, security is 10 years behind ops. So by her classification, security is 20 years behind dev. But you actually somehow magically can make security run faster than dev?

Yeah. Today with the platform, think about it. When a security team uses Wiz today, they already have really good visibility into the development processes, the code that is generated, the deployment processes, the actual cloud environment. And basically, let's say a development team that develops an agent and deploys it into their cloud environment. is already protected by— with visibility as it is. And one of the unique things, Anton, to your point, that I think is exciting about AI is that it's almost the first time in history, maybe correct me, that there is a new technology that developers start using. And then at the same time, security is actually catching up with it and providing tools to leverage it against bad guys and in order to secure the internal development. And I think it's a really unique It's exciting for security to be at this point of being an enabler for the business rather than wait, you know, we need to look into it, we need to decide. And security became— I think this is the prime example for security to become really a leader and enabler in the technology that the business can use and not a blocker. So it is exciting and you can do it with Wiz today. But again, to the question, we need to secure AI workloads. We need to create visibility. into AI components that are used, whether it's MCP servers, whether these are agentic platforms that are now being developed. We even need to secure other types of platforms that are not serving developers. You have now low-code, no-code agents that can be ultra-powerful, and we need— although they are not developers, we need to think about securing the agents that they create. Yes, we have to think about the expanded estate now with AI that we need to protect. We see it as a natural evolution from CNAPP to what we call AI App. And so that's one aspect. The second thing is leveraging agent capabilities. And this is where we launched the 3 agents that I mentioned, the red, green, blue.

Mm-hmm.

I really think it's the beginning of a beautiful friendship because I think it really extends the different teams in security and it allows us to think for the first time on a model that security is happening invisibly behind the scenes and creates a security environment that can scale. And this is why I'm super excited about it. I know that most of the organizations today react to the fear from AI threats, and actually they should because attackers are already using AI and we need to move fast. But I think that the outcome will be a dramatically improved security posture for our technologies. I think this is the silver lining that I'm clinging to. If we are able to automate the security process we use, we do today, security will be much better tomorrow.

That's my sincere hope as well. Anton and I were talking about this on the walk to the studio that we're both in right now. I think, in 10 years, we're going to look back and say, wow, we used to spend a lot of energy and time on security. that we don't spend today. So I'm super stoked.

Exactly. Maybe 2 years.

All right, well, more optimism than I've got. But this conversation has made me really stoked to be on this journey together. I have to do my least favorite part of the show, which is ask our traditional closing questions. So one, what's your advice to the people building the next generation of security technology? And 2, I see some books on the shelf. Do you have recommended reading for people? And it can be anything except Anton's blog. And you already said go read our roadmap and the product, so it can't be that either.

I'll start by saying on building the next generation of products, I'll go back to the concept of the graph, and maybe I'll do it a bit more philosophical than just an answer. But I think that what made AI successful in code before anything is the ability to collaborate on a language that is interoperable between humans and machines. And I'll explain that, like, humans can write code. To describe how they want an application to behave. Agents can read code, produce code, and then humans can verify the code on the other end, and then it compiles and becomes an app. And I think that this ability to have a single language that allows to collaborate is what enabled AI to be successful in coding first. And that's the same, let's say, behavior we're seeing now with our agents around the security graph. Why do I mention this? My advice to the next generation of security startups is actually to focus on the data model that they want to create in the core of their product. And how do they actually surface it to humans? And how do they teach agents to read it? And if we actually build products, not from a sense of the, you know, the UI now is easy, features are easy, code, it's easy, but Building a data model that is actually excellent in solving a problem space. I think that's my number one recommendation because that's a real moat moving forward. And yeah, so I think that's going to be what differentiates the amazing companies in the future. And recommended reading, you know, with everything that is happening, I'm finding a lot more myself reading a lot more of the classics, to be honest. And I'm going back reading classic from Don Quixote to Really fundamentals. It started because I had a lot of time with my newborn and she doesn't care what I read, but it feels weird to read to her like books about management and technology and AI. So I said, what do I need to read? So I took all of the fundamentals and I'm actually finding it amazing to go back and revisit the old books that we grew up on. And that's my recommendation. Be nostalgic.

Oh, that's great advice. I've got— my daughter will be born in August, so I will read her some classics when she arrives. Inan, thank you so much for joining us today. This was truly a delight, and I'm sorry it took us this long to get together.

It's amazing. Thank you for hosting me. It's amazing. Thank you.

Yeah, thanks for being on the show.

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/podcast. You can argue with us on the Google Cloud Security Community site, googlecloudcommunity.com.

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.