What the $32B Google-Wiz deal says about cloud-native security

A look back at cloud-native development's security challenges

Traditional software applications had monolithic architectures, built as a single unit and there was a linear approach to development. The applications were built, tested and released. Updates and product launches would happen periodically -- maybe every six months, once a year, or more frequently if an urgent security update was needed.

In the 2010s, AWS pioneered the use of microservices for its e-commerce applications, and Netflix was a famous early adopter of microservices to scale and drive massive growth. By migrating its streaming services from private data centers to public cloud services and using microservices, it could more quickly make updates and release them. Other companies, including Spotify and Uber, took advantage of microservices to innovate and scale.

We also saw the emergence of containerization. While Google had internally used container technologies and orchestration tools, Docker's emergence in 2013 made containerization accessible. Instead of provisioning virtual machines, servers and hardware to build applications, containers were the right form factor for microservices; they allowed IT pros to easily spin up and down resources to build sophisticated applications and deploy them on cloud platforms.

This also started the new trend of shifting IT and operations left with DevOps processes, empowering developers to provision their own infrastructure so they could build and deploy their apps to the cloud. This also brought a crop of new "born-in-the-cloud" companies that didn't need large IT, operations, or security teams; they just needed to hire developers who could build and deploy innovative applications to a cloud platform.

What did this mean for security? The good news was that cloud security providers (CSPs) were responsible for securing the hardware and cloud environments, but organizations were responsible for securing what they put into the cloud -- the applications and workloads.

Traditional application security tools that worked for monolithic application development cycles, such as web application testing and scanners, typically done by security teams, created bottlenecks or friction that disrupted development. Security teams also faced challenges in gaining visibility of workloads with cloud infrastructure and components that could be spun up and down as needed.

There was discussion of shifting security left to empower developers to secure their applications, but this was challenging for security teams as developers didn't want to use security tools outside of their developer tools and workflows. At the same time, developers were trying to find or build security tools they could use to catch software issues. This led to a wide variety of open source tools, with the advantages of IT communities contributing to the tools -- and they were free.

Cloud-native security vendors emerge

Around 2015, we saw the emergence of startups focused on securing these cloud-native workloads. Companies like Aqua, Twistlock (acquired by Palo Alto Networks), StackRox (acquired by Red Hat), and Lacework (acquired by Fortinet) emerged to address container and workload security. We also saw companies, such as Redlock (acquired by Palo Alto Networks), Trend Micro, and CloudPassage address security posture, such as hardening and scanning for configuration issues and vulnerabilities.

At that time, born-in-the-cloud companies needed security. Developers, DevOps teams, possibly a site reliability engineer (SRE), but more often a volunteer developer or DevOps team member would be tasked with security. They had varying security experience and would be reluctant to force developers to use security tools.

Snyk and a few other startups focused on security for developers, but they faced the challenge of developers not having budget for security tools, making freely available testing and linting tools more attractive for developers.

So the developers used open source tools or custom solutions to secure their code and cloud infrastructure, and security teams could buy security software to monitor and catch security issues in runtime, but they had little visibility into development and little control in consistency in developer security processes and tools to secure developer applications and cloud infrastructure.

At Enterprise Strategy Group, now part of Omdia, our research on cloud security maturity showed the challenges organizations face securing their cloud-native workloads.

Our survey respondents knew their cloud-native applications required a different approach and a majority had suffered from cybersecurity incidents from misconfigurations and access issues which should be preventable with better controls and policies in place and visibility of cloud-native environments.

Around 2020, two Israeli startups emerged, Orca and Wiz, that were focused on cloud-native security, providing security teams with the visibility and control they needed to better manage risk.

While the descriptions of cloud-native security evolved from cloud workload protection platforms to cloud security posture management, these were two new and exciting vendors that seemed poised to address cloud-native needs.

Also, along with Lacework, they attracted sizeable investments. (At that time, I worked as at a startup in the space, Soluble, which focused on developer security, specifically infrastructure-as-code, and Soluble was acquired by Lacework.) While other startups were being acquired, these were the companies building cloud-native security platforms, and they've been the ones to watch for possible IPOs.

Wiz' wins

Wiz' strength was in its focus on meeting the needs for cloud-native security. As new security categories evolved, Wiz defined itself as the platform that organizations should use for cloud-native security. It was aggressive with integrations and partnerships with CSPs and other security vendors.

Another strength has been its focus on supporting the diverse IT staff who might be charged with securing cloud-native environments, including developers, DevOps, SREs and traditional security teams at larger companies.

As Wiz continued to extend its platform into areas such as cloud detection and response and cloud threat exposure management, it has shown a flashy marketing presence at key industry conferences. Most importantly, it grew revenue and continued to receive funding rounds. Driving revenue has been a challenge for some competitors, including Lacework.

The Google-Wiz deal

While we always see acquisitions as successful exits for startups, many of us were rooting for Wiz to IPO. It would have also been exciting to see it become a major contender against some larger, more established vendors, such as Palo Alto Networks, or vulnerability management heavyweights like Qualys and Tenable.

However, with such a large price tag paid by Google, this is a successful exit. This is not a case of a startup going somewhere to die; Wiz needs to continue to execute because Google will need its investment to pay off.

This acquisition should help Google optimize efficiency for security teams, allowing them to manage risk and stay ahead of threats and attacks. It also brings more multi-cloud support to Google customers who need to manage security for workloads across computing environments.

My latest research, "The State of Cloud Security Platforms and DevSecOps," revealed that many organizations will opt to buy security tools from their CSPs. I am also seeing the trend of CSPs taking care of more security capabilities and features to support their customers' needs, including multi-cloud support, which is usually the driver for the use of third-party vendor tools.

I'm looking forward to seeing how Wiz continues to build out its capabilities as part of Google.

Melinda Marks is a practice director at Enterprise Strategy Group, now part of Omdia. She covers cloud and application security.

Enterprise Strategy Group is part of Omdia. Its analysts have business relationships with technology vendors.