From DevOps to AppSec: How Joni Klippert Built StackHawk by Solving the Problem Security Teams Didn't Know How to Ask For

At DevOps Days Enterprise, a pattern kept repeating itself.

Security teams would pull Joni Klippert aside — frustrated, overwhelmed, defensive. They knew software was shipping faster than they could review it. They knew they were becoming a bottleneck. But their only available move was to act as a gate, slowing releases down rather than finding a way to keep up.

Joni wasn't a security person. She was a DevOps founder who had joined VictorOps as the first non-engineering hire and helped bring the product to market. She had spent years automating the messy, manual parts of software delivery. Watching security teams struggle with a process problem she recognized immediately, she had a simple question: why isn't this being automated like everything else?

That question became StackHawk.

The Co-Founder Who Completed the Thesis

Joni's instinct was process-driven. But building a security company required someone who had lived inside security organizations. She found that in Scott Gerlach — a decade as a practitioner at GoDaddy, then CISO at SendGrid through its acquisition by Twilio.

The combination mattered. Joni came at the problem from an engineering efficiency angle: security testing should live in the CI/CD pipeline, automated, the same way unit tests do. Scott brought practitioner credibility and a deep understanding of what AppSec teams needed to trust that shift.

Together, they built StackHawk around dynamic application security testing — runtime testing that simulates how an attacker would approach an application, deployed earlier in the development pipeline where engineers can act on findings before code ever reaches production.

The Structural Problem Hiding Inside PLG Traction

The original go-to-market was deliberate. Build a PLG business — easy to try, easy to buy, land and expand — targeted at developers already thinking about security as part of their workflow. Early signals were strong. About 60% of StackHawk's early logos were engineering-led.

Then Joni looked more carefully at what that actually meant.

When a head of engineering is buying an AppSec product, they probably don't have a dedicated security team yet. High conversion, low ACV, limited expansion path. As Joni put it: "That just wasn't going to be a way to scale."

This is a distinction worth sitting with. The problem wasn't product-market fit — developers were adopting the tool. The problem was buyer-market fit. StackHawk was converting enthusiastic champions who didn't control the budgets required for deals to grow. Volume without ACV expansion potential isn't a foundation; it's a ceiling.

The Enterprise Buyer Who Arrived Ready

While Joni was working through that ceiling, enterprises started finding StackHawk without being targeted. Her instinct was skepticism — a developer-native, configuration-as-code product didn't feel like an obvious fit for large, complex organizations.

Then came the beverage company.

A Fortune 500 organization arrived having already done the hard internal work. They'd re-architected their entire CI/CD toolchain and were on a mission to build what they called "paved roads" — automated security checks embedded into software delivery as an organizational default. They weren't evaluating whether to adopt this model. They'd decided. They needed the tooling to execute it.

"When you start closing logos that are household names," Joni said, "it's something to be celebrated... I was kind of beside myself honestly."

What made this significant wasn't just the logo. It was the profile of the buyer: already philosophically aligned, already invested in the infrastructure, already past the hardest internal debates. StackHawk's developer-native approach — the thing Joni worried would create friction with enterprise buyers — was exactly what the most progressive security organizations were looking for. The inbound came because the positioning was working on buyers StackHawk hadn't designed for.

Rotating Segments When the Market Told Them To

The enterprise pull arrived at a useful moment. As macro conditions tightened, SMB customers in fintech and health tech — strong early targets — started deprioritizing security spend. Survival mode doesn't leave room for new tooling.

StackHawk didn't resist the signal. They rotated toward upper mid-market and enterprise, where security budgets are structurally more durable. This wasn't a pivot — it was active segment management in response to real market conditions.

But not every enterprise buyer was operationally ready for StackHawk's full vision. Many AppSec teams wanted to shift left and automate testing in the pipeline — they just weren't there yet. Their relationship with engineering was still fragile. Their processes were still largely manual.

StackHawk's answer was a bridge product: capabilities that surface familiar interfaces — tools that feel like the legacy software these teams already know — while AI handles the complex configuration on the backend. The goal is to convert aspiration into active usage without requiring organizational transformation as a prerequisite. It's both a product decision and a sales motion: get them using it now, on a path to the full platform.

The Math Problem AI Created for the Competition

The most consequential shift in StackHawk's go-to-market story isn't the enterprise rotation. It's what AI-accelerated development is doing to the broader AppSec market.

Joni's engineering team has 8x'd software delivery in the last six months. Her most senior engineers haven't written a line of code in five or six months — it's pure prompting. That velocity is being demanded across organizations everywhere, driven from the top down.

The downstream effect on security tooling is structural. Static analysis tools — historically the first AppSec purchase, with dynamic testing tools like StackHawk coming second or third — are now generating volumes of findings that no team can manually triage. Many of those findings aren't reachable or exploitable in a live application.

"There are so many static code analysis findings you can't possibly weed through them," Joni said. "And the type of testing we do proves that it's actually reachable and exploitable."

Runtime testing moved from a secondary purchase to a primary requirement. The category Joni built for is now the category the market urgently needs. That's not luck — it's what happens when a product is built around a mechanism (runtime proof of exploitability) rather than a trend (shift-left, DevSecOps) that can be replicated by incumbents.

Owning the Narrative When Analysts Can't Agree

Through the PLG ceiling, the enterprise rotation, and the AI tailwind, one challenge has been consistent: category definition. StackHawk has never fit cleanly into AppSec or API security as analysts have traditionally defined them. As the attack surface expands to include LLMs and MCP servers, the definitions keep shifting.

Joni's response has been to stop waiting for the right quadrant and own the language of the problem directly.

"APIs are what we test. DAST is how we test."

That sentence does more work than any analyst placement. It's precise, buyer-legible, and flexible enough to evolve as the attack surface does. For founders operating in categories that analysts are still trying to define — or redefine — it's the sharper play: anchor to the mechanism, not the label.

Joni Klippert joined us on a recent episode of BUILDERS. Listen to the full conversation at FrontLines.io.