Today marks an exciting day for all of us here at Pixee, and maybe in appsec? Excuse me some founder panaché.

The Problem: Proving Exploitability Is Hard

One of the hardest, most detail-oriented, and time consuming things to do with SAST is to try to verify a vulnerability.

Easy ones are easy, but when there’s regexes, string appends, and different APIs all stacked on top of each other in a complicated data flow, it gets hard to reason about it in your head. And when there’s doubt, developers assume it’s safe, and appsec worries it’s vulnerable. Cue the eternal tension.

So, you try and chase it down – you try to find an environment, get credentials, figure out how to access that point in the code, set up the app state… this process could take hours at best, weeks at worst, and possibly never pay off. By the time it does, the code could have changed 3 more times.

It’s just not feasible for you — but attackers don’t have your time constraints.

What if you could scale the hard part, instantly, and get 90% of the value?

Meet Exploit Verification, a new feature of the Pixee platform.

Exploit Verification: AI-Automated PoC Creation & Fuzzing

You might know our focus at Pixee on using AI to triage vulnerabilities. Our agents run investigations on the vulnerable code flow. That means the code is gathered, telescoped, and analyzed — and we reach a conclusion mostly using attention as a medium for analysis.

But, attention has limits. There are limits to how much it can reason about how code and data flows, especially in how it appears to “maintain state” of data over time spanning different files, methods, under different variable names – it’s a real doozy.

Today, we take the first step to expand our capabilities from using attention for analysis to using attention to provide some kinetic proof.

At a high level, our new Exploit Verification feature is simple.

We take the vulnerability. We simplify it. We fuzz it.

Case Study: Regex Bypass Made Easy

CodeQL reports an interesting Missing Regex Anchor issue in the Backstage project:

307:       external: (source, importer, isResolved) =>
308:         /\.css|scss|sass|svg|eot|woff|woff2|ttf$/.test(source) ||

You might be forgiven for impatiently thinking “How is this bypassable? It must start with a ., and it must end with an allowed file extension. Well, let’s see what Exploit Verification has to say:

Uh oh. We verified a bypass! Not only that, but we give you the fuzzer code to verify for yourself:

Then we also show the results of our individual fuzz attempts:

The complete vulnerability report! All it’s missing is for someone to nod, and hit the “send analysis to my dashboard for this issue” button.

Note: I chose this example because this is functionality that appears to only be available to trusted individuals — so no harm in me discussing a bypassable control in this case.

Where Does Exploit Verification Fit In?

This is how I see the spectrum of possible proof techniques:

Nothing beats a production verification, but it’s just not practical at scale. I love where it sits because there’s no additional labor, with a high confidence compared to the SAST result itself.

Here’s where I’ve found it most valuable:

• The less familiar I am with the language / ecosystem APIs

• The harder the vulnerability type is to understand innately just by looking at (e.g., the missing anchor example.)

• The more steps and more complications there are in a dataflow vulnerability (though, this also introduces more opportunity for derangement)

The Limitations

Of course, no technology is a silver bullet, and there are some things it won’t be able to re-capture:

• Authorization constraints

• “Incidental” security controls — things that are not setup to stop attacks, but sometimes do

• It’s LLMs, so there’s always a slight chance of derangement in the path from simplification → translation → fuzz → interpretation

• Language limitations — we can’t fuzz in native languages for all languages yet, so we’ll translate to an intermediate language for fuzzing if we have to.

Summary: It’s Awesome. Humans Still Needed.

This feature has already been proven super helpful — it’s in Early Access now and will become Beta over the next few weeks. I’ll share more examples in the next weeks.

The need for humans still remains.

I can’t wait for the feedback. We are in early days, but this feels transformative. Try it out!