Finding and Fixing Vulnerabilities Using AI

5.5 Triage

Most projects must perform triage; that is, they must prioritize reports.

Ideally, all vulnerabilities would be fixed immediately, but when there’s a lot to do, that’s often impractical. When handling everything immediately is impractical, findings must be prioritized so the most important vulnerabilities are addressed first. This is best done after validation, though if the validation process is overwhelmed, you may need to do some triage before validation.

Triage is fundamentally a risk decision. Risks, by definition, are important based on their:

1. Likelihood. In particular, consider the preconditions necessary for the vulnerability to be exploitable and what is required for an attacker to exploit it [Yan2026]. A vulnerability that an unauthenticated attacker can exploit remotely is more likely to be targeted than one that requires a local authenticated user.
2. Impact. A remote code execution (RCE) vulnerability is typically considered an extremely high impact because often an attacker can make the system do almost anything. In contrast, a vulnerability that can only reveal public or unimportant information would have low impact.

Most systems have some sort of “severity rating” classification system to help you identify the vulnerabilities most needing to be addressed [Rogers2025]. Unfortunately, many report that AI systems aren’t very good at estimating the severity of a vulnerability (they often report both too high and too low), so if you use an AI to estimate in a way that matters, have a human review the estimates.

You can make AI severity estimates more reliable by giving the AI your threat model and having it answer specific questions building on that before it assigns a severity.

• [Yan2026] suggests asking about reachability (can an attacker reach this code from a real entry point?), attacker control (does untrusted input reach it intact?), preconditions (does it need non-default settings or a narrow timing window?), authentication (can an unauthenticated attacker trigger it?), read versus write access, and blast radius (who is affected?).
• They suggest that “zero preconditions with unauthenticated remote access is critical or high severity. One or two preconditions, or an authenticated path, is medium. Three or more, or local-only, is low. Adjust the thresholds to your system.”
• That report argues that “going through the evidence first keeps the model from anchoring on the bug class (‘SQL injection, so critical’) and then inflating the severity to match.”

Modern AI systems have become increasingly good at chaining many defects together into vulnerabilities. Something that appears unexploitable may, when combined with other defects, constitute a serious vulnerability. Thus, it’s reasonable to triage the “most dangerous vulnerabilities” first, but do not ignore other defects that appear unexploitable. Fix the other defects, as resources permit, so they don’t become part of a chain leading to an exploit.

Don’t assume an AI-found vulnerability will stay unknown for long. When many people use similar AI tools on the same code, they often find the same bugs around the same time. The Linux kernel security team reports that bugs found with AI assistance “systematically surface simultaneously across multiple researchers, often on the same day” [Linux-SecurityBugs].