45K CVE Tickets Addressed Autonomously in Just 4 Weeks

01 · Background

A mature platform, carrying over a decade of dependencies

The company sells decision software to banks that run sanctions checks, to intelligence and enforcement agencies, and to enterprises that coordinate global operations. To win and keep that business it has to pass security reviews, and those reviews come often, on the customer's schedule rather than its own.

Under the product sits a large estate of several hundred Java, Python and JavaScript services. Each one carries its own dependency tree, and each one is scanned continuously for known vulnerabilities.

The company holds a SOC 2 Type II attestation. Type II tests whether controls worked over a period of months rather than on a single day, and fixing known vulnerabilities on time is one of those controls. A growing backlog is therefore audit exposure.

The scanners never stop, and new tickets arrive every day. This is not a project with an end date. It is a flow that has to be managed.

02 · The problem

52,488 open tickets that no team could work by hand

Scanners do not file one ticket per vulnerability. They file one ticket per vulnerability, per container, per repository. A single outdated file-upload library produced fifteen tickets in one service, and across hundreds of services the queue reached 52,488 tickets.

Seniority was not the issue here. At this volume the work costs the same very large amount of time, whoever does it.

• Duplication at the source. The same upgrade appeared up to fifteen times, as fifteen separate tickets, each with its own review.
• Tooling that disagrees with itself. Scanners often name different target versions for the same finding. Some findings have no published fix at all.
• Work spread across 560 repositories. Each repository has an owning team, its own CI and its own release schedule.

What the backlog put at risk

The first risk is commercial. Customers expect their suppliers to find and fix vulnerabilities on a regular schedule, and many contracts require it. A supplier that cannot show this record loses trust, and trust is slow to rebuild.

The second risk is technical. Every unfixed vulnerability is an open door, and known flaws are the easiest of all to exploit because the method is already public. The exposure covers data integrity, company assets and system availability.

“When I saw more than 40,000 security tickets, I panicked. We were in the middle of SOC 2, every vulnerability had to be addressed, and the backlog was far beyond what our engineering teams could handle manually.”

VP R&D

03 · The solution

Agents that run where the evidence lives

The first constraint was reach, not ambition. To decide whether a CVE applies, and to prove that a fix works, you need much more than the source file.

You need the internal artifact registry that holds the company's private packages, and the CI system whose build and test logs show whether the change survived. You need the issue tracker carrying the original finding, and the internal databases and services the code runs against. None of that is reachable from the public internet, by design.

So Clears deployed in a hybrid model. Orchestration stays managed. The agent runners execute inside the customer's own Kubernetes cluster, in the customer's own cloud account, where all of that context is a local call away. The security properties follow from the topology rather than from a promise: Clears holds no standing credentials for the customer's cloud account, the appliance writes its own secrets, and the runner's only outbound path to Clears is a single HTTPS endpoint that reports a finished result.

What that buys is context. Before proposing a change, a run reads the scanner ticket and its history, pulls current advisory and release data for the package, and searches its accumulated knowledge. It then reads the code to find every place the dependency is used, and resolves the real dependency tree against the private registry rather than a public mirror. The fix is the last step, and the smallest one.

The pipeline runs in four stages, with no human hand-off between them.

Consolidation is what makes review survivable

Grouping the tickets is not just bookkeeping. The system collects every finding that a single upgrade resolves, so all the edits one repository needs land in one place: one change to one manifest file, in one commit, in one pull request.

In four weeks the system opened 560 pull requests, one per repository, carrying tens of thousands of grouped tickets between them. Without that grouping, the same work would have reached the team as thousands of separate reviews.

The thousandth ticket gets the same attention as the first

Assessing CVEs one at a time is repetitive work, and repetition is where accuracy quietly goes. The thousandth advisory gets read less carefully than the first. A version number gets copied from the ticket without a check. That is not a lack of skill. It is what happens to anyone asked to perform the same careful check several thousand times.

An agentic process does not get bored. Every ticket receives the same assessment, and that consistency shows up in the output. The system has caught tickets whose stated fix version was wrong, where the specified upgrade would have left most of the listed vulnerabilities open, and shipped the correct version instead. It also grades findings by whether the vulnerable code path is genuinely reachable, so review attention lands where the risk is.

Equally important is what the system refuses to do. Some findings have no published fix, sometimes two scanners disagree on which version clears the vulnerability, and sometimes an upgrade collides with another dependency. In those cases it does not guess, and it does not quietly close the ticket. It reports the conflict, explains the reasoning, and hands the decision back to the people who own the risk. 7,443 tickets sit in that state today, each with its blocker named.

“Vulnerability remediation is repetitive, time-consuming, and a challenge every engineering organization faces. Having a system that can continuously work through the backlog changes the equation completely.”

VP R&D

04 · What it saved

Four weeks of agent time, against four months of engineering

Nobody clears 52,488 tickets one at a time. The realistic in-house alternative is a senior engineer building the automation to do it, and we estimate that at about four months of full-time work. Even then, the changes still have to land in 560 repositories owned by dozens of teams.

At a loaded salary of $180,000 a year, four months of senior engineering time represents roughly $60,000 in engineering cost alone, with model usage adding further cost.

The first run delivered in four weeks rather than the estimated four months required to build the automation in-house. That returned roughly four months of senior engineering capacity to the roadmap, while bringing the date of clean SOC 2 evidence forward.

The work does not stop

New vulnerabilities are published every day, the scanners keep running, and new tickets keep arriving. A one-time clean-up would not hold, because the same backlog would rebuild within months.

Keeping up in house would require an estimated third of a senior engineer's time, roughly $50,000 a year, plus ongoing model usage and the cost of maintaining the automation.

The loop now runs continuously, picking up new tickets as they appear and carrying each one through triage, fix, validation and merge.