Somewhere in your backlog is a critical CVE that nobody will fix. Not this quarter, probably not ever. Everyone involved knows it, and nobody wants to put it in writing.

Paul Bleicher thinks that call can be defensible if you can prove it. Across Konvu customers, he says between 70% and 90% of scanner findings turn out to be false positives or noise in the environment where they were found.

Paul is co-founder and Chief Product Officer at Konvu, which builds AI agents that sort genuinely exploitable vulnerabilities from scanner noise. On Episode 13 of the Full Metal Packet podcast, hosts Yegor Sak and Alex Paguis pushed him on whether skipping the patch is ever defensible. His answer involves a number most vendors won't give you and, eventually, an auditor.

TL;DR

• Across Konvu customers, Paul says 70% to 90% of scanner findings turn out to be false positives or noise in their specific environment.
• The constraint is arithmetic. One CISO told Paul that clearing the backlog already in his scanners would consume two years of engineering capacity.
• Reachability tells you that a vulnerable function is called. Exploitability asks whether an attacker can actually trigger it, given the application's configuration, sanitization, and inputs.
• When you skip a patch, document why. Auditors in regulated industries ask for a detailed analysis of why a given vulnerability was not fixed. Exploitability analysis can provide the basis for that answer.
• Stop ranking work off CVSS. Paul's advice for what to do instead starts with using an LLM five to ten times a day until you understand where it breaks.

The Math That Makes the Decision For You

Yegor put the uncomfortable version of it directly to Paul. A vulnerability gets flagged, triage comes back with don't worry about this one, bro, no impact here, skip it. "That kind of mindset seems kind of strange to me," Yegor said. If he were on the security team, he'd want it fixed anyway, regardless of whatever Joe who investigated it or "this magical AI box" had to say.

"Honestly, I agree," Paul said. "I mean, it's best practice." Then he explained why almost nobody operates that way. The alternative does not fit inside a fiscal year.

Paul described a conversation with a CISO who had run the numbers. Sending every vulnerability currently in his scanners to developers would occupy the next two years of engineering capacity. Nobody takes that plan to a board.

"Today, every company is a software company. And if you block developers from shipping new features, deploying bug fixes and so on, you're not going to have a business in a year."

This is where Episode 13 picks up an argument from Ben Lipczynski in Episode 10. Patching everything can create the feeling that risk is being reduced while the work that matters gets buried. Paul is trying to turn that observation into a repeatable decision process.

The Number Most Vendors Won't Give You

So the question stops being what to fix and becomes what you can defensibly ignore, which puts real weight on triage accuracy. Alex asked for the breakdown. Paul went after his own category first, saying there is one thing he finds very scary.

"When you see these big marketing, zero false positive, or big statements that are just bullshit."

His own number is a range rather than a promise. Across Konvu customers, Paul says 70% to 90% of findings turn out to be false positives or noise. In a separate estimate, he said the genuinely exploitable share can range from a couple of percent to 20% or 30%, depending on the environment. Those are observations from his customer base, not universal benchmarks, and they are not clean halves of one 100% table.

Reachability Tells You Less Than You Think

Each generation of triage logic answers a narrower question than the last.

Reachability appeared roughly five years ago and was a real step forward. It stopped being enough as volume climbed. "If you're just filtering out all your vulnerabilities based on reachability analysis, you still have too much noise and too many vulnerabilities to triage," Paul said.

Yegor pushed on the obvious question. If the vulnerable code path is never used, why is it in the application in the first place? Paul was blunt about the tooling. Many dependency scanners, in his description, check whether a vulnerable dependency is installed and whether that version has a CVE attached. That test can generate thousands, sometimes hundreds of thousands, occasionally millions of findings a year.

Alex raised the counter-case. Something unreachable today becomes reachable after one configuration change. Paul agreed without hesitation. If something is reachable, patching it is best practice. Volume is what stops best practice from becoming operating reality.

What "Agentic" Means Once You Strip Out the Marketing

Paul's definition is specific enough to check.

1. Build the checklist. For each vulnerability type, Konvu defines the precise conditions that would have to hold for that CVE to be exploitable.
2. Hand it to an agent. The agent turns those conditions into an investigation plan. Planning is what LLMs are good at.
3. Orchestrate deterministic tools. Code search, code reading, static analysis. These do the actual checking, because they return the same answer twice.

Alex went straight at the objection. The system running your vulnerability analysis needs privileged access to your codebase, and CVE content is untrusted text that could carry a prompt injection. You have added an attack surface in order to reduce risk.

It is the same problem Maxime Lamothe-Brassard raised in Episode 2: cybersecurity has spent years asking customers to accept "trust me, bro" as proof. Calling something agentic does not fix that. The checklist and the deterministic checks are the part you can inspect.

Paul deferred the technical detail to his CTO but gave the operating principle. Running LLMs in production is still software engineering, and software engineering has decades of practice around handling untrusted input. He named two controls.

• Agents have read access only
• Agents have no internet access

An Unpatched Vulnerability Still Needs a Paper Trail

This is what makes the approach defensible rather than merely convenient.

Paul works with financial institutions and other regulated firms whose auditors examine vulnerabilities that were not remediated and ask why a particular vulnerability was not fixed. That explanation has historically been written by hand, one at a time.

Exploitability analysis can produce the basis for that explanation at a volume no human team could match. Leaving a vulnerability unpatched becomes a documented decision rather than an unexplained hole in the program.

That distinction matters. In Episode 9, John Verry and the hosts spent an hour separating a working security program from compliance theater. A paper trail is not automatically evidence. Here, the useful part is that the record captures the conditions that were checked and why the team made the decision.

The Gap Between Teams Using Agents and Teams That Are Not

Asked whether startups or large enterprises are better positioned, Paul described the split he sees every week. Security leaders at smaller organizations are building genuinely interesting things with agents. CISOs at large organizations often have not a single developer using Cursor or Claude Code.

Yegor's argument was that the process of filling that gap is mostly theater. The episode was recorded the day Control D completed its ISO/IEC 27001:2022 and ISO/IEC 27701:2019 certification. The asymmetry he described is hard to argue with.

• An attacker sees a new model ship and is using it that afternoon. No approval process, no paperwork.
• An enterprise defender needs weeks of review and a dozen meetings before the same model is authorized, by which point the capability gap has already opened.

Paul half-conceded. Konvu is SOC 2 compliant, and he called it a lot of paperwork. His defense of regulation is narrower. Regulated industries have a bad cop who punishes companies that ignore security practices, and he thinks that is worth having.

The scale of the gap is not hypothetical. Mozilla's collaboration with Anthropic ran Claude Opus 4.6 against Firefox for two weeks and resulted in 22 CVEs, 14 of them high severity. A later Mozilla project using an early Claude Mythos Preview identified 271 vulnerabilities.

You Don't Have to Hand the Agent Your Data

Paul's caution is that the organizations moving slowly are banks holding your financial data, and you probably don't want swarms of autonomous agents loose in there either. Alex offered the way through. The data itself is rarely what the agent needs. Understanding how the systems around the data are built and accessed delivers most of the value at a fraction of the exposure.

What Paul Wants CISOs to Stop and Start

Stop triaging on theoretical severity. Paul's instruction is blunt. "Stop triaging vulnerabilities just on theoretical severity and theoretical probabilities of exploitation." Severity scores were never a description of your risk. They didn't work ten years ago, and they hold up worse now.

Start using an LLM every day. Paul's early experience with ChatGPT was the standard one. Interesting, wrong too often, hard to trust. A manager told him to stop evaluating it and start using it five to ten times a day until it clicked. It did.

"If you're not using an LLM five, ten, 50 times a day today, I think you're not going to be set up for success."

His specific target is the security leader still building Jira projects and slide decks by hand and asking analysts to pull queries.

Security Has to Get Out of the Way

Konvu's stated mission is to make security invisible, and the case for it ran underneath the whole conversation. AI writes the code, AI finds the exploits, and a human is still opening Jira tickets by hand. "It cannot work," Paul said. "It just cannot work."

A DNS Policy Still Needs a Paper Trail

Paul's standard for an unpatched vulnerability is simple: show your work. A DNS policy records what the team intended to happen. These Control D tools provide evidence of what happened in the environment.

• The DNS Leak Test identifies the resolvers actually receiving DNS queries.
• The DNS Rebind Test checks how the current resolver handles DNS rebinding.
• Dragonfly exposes the classification, DNS, TLS, WHOIS, and supporting data behind a domain verdict.
• Analytics shows activity across DNS traffic.
• Administrative Action Logs preserve configuration changes and who made them.
• SIEM data streaming moves DNS activity into the systems where security teams already investigate and retain evidence.

That gives the security team what Paul keeps returning to in Episode 13: a decision grounded in the real environment, with enough evidence for somebody else to examine it rather than accept it on faith.

Continue the Argument

• Episode 10: Navy Officer Reveals the Threat Modeling Mindset Most Cybersecurity Teams Are Missing examines why patch volume and theoretical severity can create false confidence.
• Episode 2: "Trust Me, Bro" Isn't a Security Strategy asks what security looks like when customers demand evidence instead of promises.
• Episode 9: Why Your Audit Passed but Security Failed separates operational security from compliance theater.

Browse every published article in the Full Metal Packet series, or try the Control D tools used to inspect and verify DNS behavior.

Common Questions Answered in Episode 13:

Can a security team justify leaving a critical vulnerability unpatched?

Yes, when the decision rests on evidence rather than scanner severity. Patching remains best practice. If the required exploit conditions are absent and the team documents what it checked, the decision becomes something another security leader or auditor can examine.

What is the difference between reachability and exploitability?

Reachability asks whether the application calls the vulnerable function. Exploitability asks whether an attacker can trigger it under the application’s actual configuration, sanitization, and input conditions. Reachability is one useful part of the analysis, not the final answer.

How much scanner output is noise?

Across the customers discussed in the episode, 70% to 90% of scanner findings can be false positives or environmental noise. A separate estimate places the exploitable share between a couple of percent and 20% or 30%. These figures describe one customer base, not a universal industry benchmark.

Why not patch everything anyway?

Because the backlog can consume the engineering organization. One CISO calculated that sending every existing scanner finding to developers would require two years of engineering capacity. Fixing reachable vulnerabilities remains best practice, but no serious operating plan can treat every finding as equally urgent.

What does “agentic vulnerability triage” actually mean?

The process starts with a checklist of the conditions required to exploit each vulnerability type. An LLM turns those conditions into an investigation plan. Deterministic tools then search and read the code, run static analysis, and test the conditions. The LLM plans the investigation, while repeatable tools perform the checks.

Does the AI agent create another attack surface?

It can, especially when the system reads untrusted CVE content and has access to a codebase. The episode treats this as a software-engineering problem around untrusted input. Read-only access and no internet access are two controls discussed. The complete technical architecture was not covered, so the episode establishes no broader security guarantee.

Can AI automatically patch the vulnerabilities it finds?

Reliable autofixes at scale still need work, especially when a patch can break the application. The target is a complete process that triages the vulnerability, applies the patch, tests it, and proves that the application still works. The episode presents that as the direction of the industry rather than a solved capability.

What should CISOs change now?

Stop ranking vulnerabilities from theoretical severity and CVSS alone. Start using LLMs often enough to understand where they help and where they fail. The practical recommendation is five to ten uses a day, especially for work that still depends on manually created Jira projects, presentations, and analyst queries.

Paul Bleicher is co-founder and Chief Product Officer at Konvu, which builds AI agents for vulnerability triage and remediation. He previously worked on product and go-to-market at Codacy, Sqreen, and Athenian.

Full Metal Packet is hosted by Control D co-founders Yegor Sak and Alex Paguis. Watch Episode 13 on YouTube, listen on Apple Podcasts or Spotify, or follow the complete Full Metal Packet series.