When we decided to start Maze, our goal was to be different from every other security company out there. Instead of blindly chasing ARR numbers, we wanted to build a product our users truly love. We believe that the first step to building a great company is solving real pain—not just putting a patch on it and hoping for the best. 

To solve a problem, you first have to truly understand it. That’s why we set out to talk to as many people as we could. Over the past year and a half, we’ve had hundreds of conversations with security leaders at companies of all sizes. The response from the community was incredible and led to many candid discussions about what’s broken, what’s frustrating, and where we—as an industry—are falling short. 

One topic kept coming up again and again: we have a major problem in how we handle vulnerabilities. 

Despite deploying dozens of tools over the years, teams are drowning in noise. And it's not surprising: the number of vulnerabilities is growing at ~40% year over year. Time to exploit is going down faster than ever, from 32 days in 2022 to 5 days in 2023, and with AI this trend is likely to continue. Exploitation of vulnerabilities has now overtaken phishing as the second most common initial access vector—and it's quickly catching up to credential abuse. 

We saw this problem firsthand when leading product and engineering teams at Amazon, Elastic and Tessian. There was always a tension between how much engineering effort should go toward patching vulnerabilities versus building and improving the core product—the one that actually drives business growth. 

Some companies only have the bandwidth to patch critical findings—knowing full well that many dangerous vulnerabilities are lurking in the lower tiers, just waiting to be exploited. 

Others try to patch as much as they can, which often leads to massive investment and growing friction between engineering and security teams. Let’s be honest: most engineers know they’re being asked to patch false positives.

 Then there are companies trying to do the right thing by manually triaging every finding before handing it off to engineering. This approach is admirable—but no security team can investigate hundreds of thousands (or millions) of alerts manually. It's just not scalable. 

None of these solutions work well.

“Shift left” just means engineers end up patching false positives earlier in the pipeline. Legacy tools that "re-score" findings rarely help—you're still looking at the same volume, just with slightly different severity numbers. (And really, what’s the meaningful difference between a 6.0 and a 7.5?)

CVSS was never enough. EPSS is better, but still lacks the most critical component: internal context. The only way to get that today is through manual investigation—and that takes hours per finding. It’s not sustainable, and everyone knows it.

We invest more and more resources to triage and patch vulnerabilities, but it’s never enough. At the same time, we almost never know if we managed to patch the few really bad vulnerabilities that could actually lead to a breach. Unfortunately, many security teams are crossing their fingers and hoping for the best.

At Maze, we’re dedicated to changing how teams understand and act on vulnerabilities—especially in cloud and application environments. Our goal is to bring real context into the decision-making process, so teams can focus on what matters, build trust between security and engineering, and measurably improve their risk posture. 

We’re not just building another tool that generates alerts. We’re building a system that helps teams answer the question: 

What’s the most efficient thing I can do next to make my environment safer?