How to Triage Thousands of AI Vulnerability Findings: A Prioritization and Remediation Guide

AI vulnerability scanning has changed what a security backlog looks like. Since August 2026, Claude Enterprise customers can run Claude Security on Anthropic’s Mythos-class models: scans that trace data flows across files and return findings with a CWE category, severity, confidence and a suggested patch (The New Stack). Frontier scanners find what traditional static analysis misses, including multi-step vulnerability chains.

They also find a lot. When an enterprise points AI-augmented scanning at dozens of repositories in .NET, Java, Python and TypeScript, a first pass returning thousands of findings is normal. Some are false positives. Many share a root cause. A few are chained attacks that matter far more than their individual severity scores suggest. The bottleneck is no longer detection. It is vulnerability triage, prioritization and remediation at volume.

This guide lays out the process we use and recommend, shaped by our solution architecture work on enterprise remediation programs and by conversations with application security engineers who do this every day.

1. Normalize and deduplicate your findings

Before you can prioritize, every finding needs the same shape, whether it came from an AI scanner, CodeQL, a dependency checker or a penetration test. At minimum capture the repository, service, file and line, CWE category, source and sink, scanner confidence, and whether the code is deployed.

Then deduplicate aggressively. The same vulnerable pattern copied across twenty services is twenty findings in the scanner and one decision for your team. Scanners and AI both surface duplicates; your intake process should collapse them before they reach a developer.

2. Root cause analysis: one fix, many findings

The single biggest lever in a large remediation program is root cause analysis. When you group findings by what actually caused them, a two-thousand-item list often becomes a few hundred decisions.

• Shared dependencies. An outdated package can produce the same issue across an entire codebase. One version upgrade closes all of them, which makes it the classic quick win.
• Shared internal libraries. Patching an internal package used by many services fixes the problem everywhere it is consumed. Keep the change backwards compatible, publish a clear upgrade path and add a CI check that blocks merges until each service moves to the fixed version.
• Shared patterns. A helper that builds queries from user input, or an endpoint template that never checks object ownership, repeats the same flaw in every place it is copied. Fix the pattern, then sweep for every instance.

Sort the grouped root causes into quick wins and structural work. Quick wins (library upgrades, configuration changes, a missing authorization check in a shared middleware) build momentum and shrink the backlog fast. Structural fixes need design and testing time, so plan them as projects.

3. Separate real findings from false positives

AI scanners are good, and they still produce findings that need judgment. Three techniques do most of the work.

Reachability analysis

A vulnerable function only matters if an attacker can reach it. Ask whether the vulnerable method in a dependency is ever called, whether the repository is ever deployed, and whether the endpoint is exposed to the internet, to customers or only to a small internal group. A critical finding in a repository that never ships is not critical. A medium finding on an internet-facing endpoint may be urgent.

Repeatable validation, with a deterministic score

Run exploit validation more than once. If an automated attempt reproduces a finding consistently across several runs, confidence goes up; if it never reproduces, it is a likely false positive. Base the confidence score on those observable results, not on a model rating its own output. Model-generated confidence is non-deterministic, so it should inform triage, not decide it.

Human verification, scaled to impact

Match the depth of manual testing to the stakes and the complexity. A simple insecure direct object reference (change an ID in a query parameter, see someone else’s data) is easy to verify automatically. A multi-step chain that could move money or expose regulated data deserves a hands-on test, every time. A useful rule of thumb: the more steps it takes to reproduce and the higher the impact, the more human attention it gets.

Some findings are genuinely ambiguous. A JSON Web Token stored in browser local storage is not automatically a vulnerability. Check what the token contains, how long it lives and how refresh is handled before deciding it needs a fix.

4. Vulnerability prioritization by business impact

A CVSS score describes a vulnerability in general. Your priority depends on your system. Many AI findings are not CVEs at all, so you need a model of business impact to rank them.

• Exposure. A flaw that one million customers could trigger outranks one only twenty employees can reach.
• Business criticality. The same bug on a trading platform that moves billions of dollars a day is a different problem than on an internal audit archive.
• Likelihood. How many steps does exploitation take, and how realistic is each one?
• Cost of failure versus cost of the fix. Quantify where you can. A loss exceedance curve (the probability of losing more than a given amount) beats a red, amber and green matrix when you are deciding where engineering time goes.

This is why threat modeling matters. A good threat model captures business risk, not just software risk, and it has to be built with the people who own the business. Stakeholders may weigh a reputational incident more heavily than a direct financial loss, and long-tenured teams know which systems are truly critical. Talk to them before you finalize the ranking.

Exposure caught us out on our own website. A screening of our previous site found no exotic code flaws, but it did find an end-of-life operating system, PHP version and database, a content management system four years behind, no backups and an unused remote desktop port open to the internet. Within hours of putting the replacement online, automated scanners were already probing for /.git/config and xmlrpc.php. The exposed, outdated basics were the real priority.

5. Resolve disputes with evidence

Sooner or later a developer will insist a finding is a false positive, or a security engineer will be sure a finding the developer dismissed is real. Settle it with evidence, not authority.

• To close a finding as a false positive, document the reproduction attempts: the techniques tried, the payloads, the roles used and the results. For an access control finding, log in as the wrong role, attempt the action and capture proof that it fails.
• To prove a finding is real, build a proof of concept, the same standard any serious bug bounty report requires. Few arguments survive a working exploit.
• When an owner chooses not to fix, record an explicit risk acceptance signed by the accountable leader, including the impact on the wider company, not just their service.

Approach these conversations as engineering, not enforcement. Developers who understand why something is exploitable write better code next time.

6. Remediate safely and prove it worked

Let developers write the fix

Security engineers can open pull requests, but in a large program it usually scales better for the owning developer to write the fix and for security to review it. The developer learns the pattern, and the approval is a real review rather than a rubber stamp. Teach the team to fish.

When the vulnerability is in third-party code

1. Ask the vendor to fix it. Leverage depends on the relationship, so raise it early.
2. If they cannot, mitigate on your side: wrap the integration behind your own interface, validate and sanitize what crosses the boundary, and stop sending data the vendor does not need.
3. If neither is possible, document the residual risk and get it formally accepted.

Legacy code with no tests

Use AI for a fast first pass to spot a quick fix, then invest in reproduction. Work with the team that owns the feature to learn how it is really used, and capture real request payloads with an HTTP interceptor so you have reliable reproduction data. Testing is usually harder than the fix.

Shipping fixes to live, high-stakes platforms

For financial and other critical platforms, changes that alter user-facing behavior need a careful path to production: a staging environment, sign-off from stakeholders who know the domain, feature flags, staged rollouts that limit the blast radius, deployment slots for zero downtime and a tested rollback plan.

Verify the fix, not just the scan

A clean rescan is necessary but not sufficient. Re-run the original exploit against the deployed code and record the result. Treat it like any bug fix: the reproduction steps should now fail.

7. AI-generated remediation, with guardrails

Agents can generate remediation pull requests at volume. Without guardrails they can also introduce new vulnerabilities while fixing old ones, or bury the codebase in plausible-looking code nobody understands. Fixing that later costs more than writing it cleanly the first time.

• Keep a human gate. A person approves every AI-generated change before merge.
• Tier by test coverage. Allow more automation where CI and test suites are strong; require closer review where a single error could be expensive.
• Fence off critical paths. Production access, anything that moves money, and authentication or identity logic stay off-limits to unsupervised AI changes.
• Write the rules down. Spec-driven instructions define what an agent may change and when it must stop and ask.
• Check the checkers. Validation suites and independent agents reviewing each other catch errors early, but they supplement human review rather than replace it.
• Use zero data retention. Your source code is intellectual property, and real secrets sometimes hide in it. Run scanning and remediation models under zero data retention terms.

What can a triage pipeline auto-close?

Full auto-closure is where many programs want to end up. Start narrow, with findings whose dismissal you can explain in one sentence and verify mechanically:

• A vulnerable dependency where reachability analysis proves the affected function is never called.
• Placeholder credentials in mocks, fixtures or seed scripts that never run in production.

Then sample the auto-closed findings for human review, label any mistakes as false closes, and tighten the rules. Trust is earned one category at a time.

8. Shift left to the IDE

The best vulnerability is the one that never reaches a pull request. Shifting left now means moving security checks onto the developer’s machine, not just into CI:

• Run AI-assisted security checks in the IDE so issues such as unvalidated object access or user-controlled string interpolation are caught while the code is being written, with an explanation of how to fix it.
• Give coding agents explicit instructions never to introduce OWASP Top 10 issues, and enforce them with checks.
• Keep CI gates for what gets through, including longer-running custom scans that would be too slow on every keystroke.
• Build a security champions program so every team has someone fluent in secure coding.

This is not a one-time cleanup. As more code is AI-generated and scanners keep improving, remediation becomes a continuous program with tooling, not a project with an end date.

Frequently asked questions

Facing a backlog of AI-generated findings, or want to set up scanning, triage and remediation before the backlog arrives? Talk to our team.