Snyk's Randall Degges on what it costs to know a vulnerability is real

I sat down with Randall Degges at ELC 2026. He leads AI engineering at Snyk — a company that used to scan your code and dependencies for known vulnerabilities and now also hunts for malicious skills and agents running inside your infrastructure. I brought him a problem we had just hit at WorkOS. His answer came down to a dollar figure: what it costs to know a finding is real.

The three layers Degges secures separately: data, the tools an agent can reach, and the infrastructure the agent runs on.

Three places to secure, regardless of company size

Degges splits the problem into three buckets: the data you feed the model, the tools you give it, and the infrastructure underneath.

One is your data, like, is it governed? Who can access it? What can they do with it? Basic stuff like that. The other category are the tools you give AI access to, like your MCP connectors or agent to agent stuff, like whatever it looks like on the backend. It's kind of a similar concept, like who can access it? What can it do? How are you managing keys and rotating credentials and securing all the standard stuff you do in application security with these things?

The third is infrastructure: the instances running in your cloud, and how you build and sandbox agents so they can't do things you don't want. The list doesn't scale with headcount. Degges said he hits the same three problems vibe coding a weekend project that his team hits in large enterprise production software factories.

The backlog is still winning

I asked whether AI has tipped the balance. You can generate far more code now, but you can also find vulnerabilities far faster. Does security get ahead, or does the list just grow? Degges said it's a little more the latter.

The reason isn't capability. Running an audit pass over code you just generated is cheap and available to anyone. Most people skip it, and at larger companies they skip it because they assume somebody else owns that part of the stack: engineering, or a security team, or compliance. Degges thinks that habit now separates engineers. How conscious you are of security, design, developer experience, and agent experience is what marks a good one.

A million findings, almost none exploitable

We had early access to Glasswing and ran a security analysis across our code. A portion of the findings lacked product context and nuance, and when the engineer who actually knew the application dug into them, the risk level was not what the tool had assigned. That was the problem I put to Degges.

He started a step back, with how the industry got its severity numbers in the first place: a researcher discloses a bug to a vendor, it gets fixed, it lands in a registry, and the national vulnerability database assigns it a CVSS score from zero to 10. Teams then go looking for that score in their own code. The score travels; the context doesn't.

if you go into any enterprise with a lot of code, and you look at a security dashboard somewhere, I guarantee you there's like a million vulnerabilities with like super high risk scores. But almost none of them are exploitable. Like they'll be in a dependency that you've imported, but maybe you're not even using. Or maybe it's in a back office system that's not even publicly exposed anywhere.

Context is a compute budget

There is a way to get the nuance back. Point a tool like Glasswing or Daybreak, which Snyk also works with, at every code base in your organization, hand it your docs and your threat modeling, and let it burn tokens until it can tell you what is genuinely fixable. The output is good. The bill is the catch.

Because obviously, if everyone was using Glasswing right now, Anthropic would be like, making $10 trillion a year of revenue, like, it'd be insane. Like, it's just so expensive.

So Snyk's long-running bet has been to reproduce the same class of finding deterministically, for very little money, by parsing code into an AST.

we'll basically parse the entire thing into this AST graph structure. And we traverse the graph to figure out, all right, well, you know, what functions and methods and stuff are actually calling out to potentially reach this vulnerable piece of the code. And if the answer is it's never executed, then you can just safely ignore it, essentially, like it's makes zero difference to you.

Reachability in one picture: the highlighted path is a finding worth your afternoon; the dimmed cluster is a high CVSS score nothing in your code can call.

The method has edges. Service-oriented architectures where calls can't be cleanly mapped break it, as does not having access to some of the code bases involved. Parsers also vary in how conservative they are; with no runtime information, some will look at both sides of an if/else and assume both execute. That's a conservative bias rather than a bug — in security tooling, extra false positives beat a missed false negative.

Live testing closes the remaining gap. Snyk's offensive security tooling runs against the actual application or MCP server, ties those results back to the code scanning results, and produces a trace showing the issue being executed. Static reachability narrows the list; the live run proves the survivors.

The framing I took away: context isn't a prompt engineering problem. It's a compute budget, and the engineering work is getting the same answer for less.

What it took to let the fixes merge themselves

Once an agent proposes a fix, is anyone letting it ship unreviewed? Degges's own teams are, after years of testing and evals aimed at finding breakage, and only recently.

I think we're just now in the last quarter, probably, finally to the point where we can turn these things on autonomously, and not and be able to sleep at night, you know. And I think having that confidence takes a long time to build out because nobody wants to be on the hook for merging a PR to fix something and then actually breaking or causing severe distrust.

Four or five months of running it, on top of years of evals, to get to the point of sleeping at night. He didn't say what broke along the way, only that the confidence took that long to build. If you're planning to turn on autonomous remediation next quarter, that's the shape of the runway.

From one spreadsheet a year to every push

Security used to be a tax paid twice a year. Degges described getting an email from the security team once or twice annually with an XLSX attached, a row per finding with project name, line number, file name, and a one-line description, and a request to tick each one off as you fixed it.

And basically, no one ever did anything with it, they just kind of ignored it.

A large central security team then spent the rest of the year chasing those findings down, producing roughly two security scans per year. Today every push gets analyzed, fixes arrive as automatic PRs, and teams doing this well run a fully agentic AppSec program that remediates in the IDE or inside a Claude prompt. The relationship between security and velocity changed when the unit of work went from a spreadsheet to a commit.

The weakest spot is the agent's own toolchain

All of that covers the code an agent writes. I asked about the agent itself: the tools it calls, the skills it installs, the commands teams share around.

I think that's a weaker spot across the industry today.

Part of the reason is that the controls teams do put in place get bypassed. About a month before we talked on October 14, 2026, Anthropic made auto mode the default permission mode in Claude Code and Claude Desktop, so it stops asking for approval on everything and prompts only when an operation looks risky. Degges turned it off within two days and runs with dangerously skip permissions.

I think it's actually more hurtful to release an auto mode, than it is to just have dangerously skip permissions to just tell people, you're doing something risky. And just let people know like there isn't inherent risk to this. That's okay to know. But like, having an auto mode that makes like, almost like falsifies a sense of security that people just kind of ignore is like almost worse in my mind, personally.

The mechanism checks out: once a prompt fires on every risky action, nobody reads it anymore. Counting that as a control is the uncomfortable part, and plenty of architecture diagrams do. Which leaves the industry owing developers tools that fix these things automatically, because asking humans to stay patient with repetitive prompts has never worked.

The loop that rewrites itself

Snyk's coding and product-building workflows have been mostly automated for at least a year. The more recent change Degges points to is making evals and feedback loops first-class parts of the products themselves.

His team builds Snyk Assist, an API service with an MCP attached, a RAG component pulling from product information, docs, and telemetry, and connectors that query things like customer logs in real time, exposed as a chatbot in the Snyk dashboard. There's no eval that declares a chatbot finished, so they grade the transcripts instead.

you can take every chat session that you have, you can analyze it with an LLM. And you can basically say, with an LLM as judge, like do we think we answer this? And if not, why?

The answer routes two ways. The agent prompts get updated autonomously, or the team traces the bad answer back to the source record and asks why that source was misleading in the first place, a mix of human analysts and autonomous updates. My read is that the second path compounds, because it fixes the documentation instead of teaching the model to patch around it.

Security in service of something else

Degges's stated hope was that a year from now we could agree security is a solved problem.

I feel like security is something that, you know, even as someone who's worked in the industry, like almost my whole life as a developer security person, like, I don't like it. Like, I don't think anyone genuinely likes, like, it's interesting. But like, it's not like you want to spend all your time doing it. It's in service of bigger goals.

The version he wants in five years is that you build whatever you want while an agent in the background finds an issue, fixes it, and never asks you to do anything about it. He thinks the systems and tools now exist, and the remaining work is getting over the confidence hurdles to fully autonomous improvement loops.

Until then, start with the question his AST work answers: for every high-severity finding on your dashboard, can anything in your code actually reach it? That answer is cheaper than a full-context analysis of every repository you own, and it's the one that decides what your team does tomorrow.