The Workflow Edit
AI Can Find Thousands of Vulnerabilities. Your Team Still Needs a Triage Rule.
AI vulnerability triage is becoming the real bottleneck. The software can find more possible problems than a small team can reasonably investigate at once. The useful question is not, “How many findings did the AI produce?” It is, “Which ones are real, exposed, important, and owned by a person who can fix them?”
Dear Suzannah
Our security tools keep finding more issues. If AI gets even better at this, how are we supposed to keep up without treating every alert like the building is on fire?
Do not start with the alert count. Start with a triage rule. Verify the finding, check whether the vulnerable component is actually exposed, look for evidence of exploitation, connect the issue to business impact, then assign an owner and deadline.
Otherwise, congratulations. You have automated the creation of a much larger panic list.
Here’s the deal
Anthropic’s vulnerability disclosure dashboard, updated August 26, 2026, shows how quickly AI-assisted discovery can scale. Anthropic reports 2,300 disclosed vulnerabilities across 392 open-source projects, with 421 patched upstream as of that snapshot. The company also says human triage and review are the rate-limiting part of the process.
That is the part small businesses should notice. Better discovery does not remove judgment. It increases the need for it.
NIST’s Secure Software Development Framework includes an entire practice group for responding to vulnerabilities. CISA separately urges organizations to prioritize known exploited vulnerabilities rather than treating every CVE as equally urgent. OWASP projects such as DevGuard use risk-based prioritization for the same reason: raw finding volume is not a remediation plan.
What this actually helps you do
Turn a flood of security findings into a short, defensible action list your team can actually finish. That protects client work, reduces wasted developer time, and keeps urgent fixes from getting buried under impressive-looking noise.
Niche use case: a small WordPress and web-development agency
Imagine a five-person agency maintaining 30 client websites. A new AI-assisted security scan flags dozens of plugin, dependency, container, and configuration issues overnight. Some are real. Some are irrelevant to the way the software is deployed. One affects a public-facing component. Another is already being actively exploited in the wild.
The team needs a way to decide what gets patched now, what gets tested and scheduled, and what gets monitored instead of blindly changing every client site before breakfast.
Exactly three benefits
- Faster response to real risk. The team spends its first hour on findings that are verified, reachable, and consequential instead of sorting alphabet soup.
- Less unnecessary rework. Developers avoid emergency changes for findings that do not apply to the deployed environment.
- Stronger client trust. Every high-priority finding has an owner, evidence, a decision, and a documented next step.
Infographic: the four-question AI vulnerability triage path
Validate the finding and affected version.
Check whether the vulnerable path exists in your environment.
Look for trusted evidence such as CISA’s KEV Catalog.
Map the issue to client data, uptime, revenue, or access.
The alert becomes actionable only after the team can answer those four questions well enough to choose a response.
Step-by-step instructions
- Collect findings in one queue. Do not let each scanner create its own private emergency. Give the team one place to review new findings.
- Confirm the affected software and version. Match the finding to the software you actually run. A vulnerability in a package you do not deploy is not today’s fire.
- Validate the evidence. Check the vendor advisory, CVE or security advisory, scanner evidence, and any reproduction details available to your team.
- Check reachability and exposure. Ask whether the vulnerable component is public-facing, reachable from an untrusted network, or protected behind controls that meaningfully reduce exposure.
- Check exploitation status. Review trusted sources such as CISA’s Known Exploited Vulnerabilities Catalog when applicable. Active exploitation should materially change priority.
- Map business impact. Identify what could be affected: customer data, administrator access, payment systems, service availability, internal credentials, or another critical business function.
- Choose a response lane. Patch now, test and schedule, mitigate temporarily, or monitor with a documented reason.
- Name one owner. Every priority finding needs one person accountable for the next action. “The dev team” is not a person.
- Verify the fix. Rescan or retest after remediation. Closing a ticket because someone typed “patched” is not verification.
- Capture the lesson. If the same class of issue keeps returning, fix the development, dependency, configuration, or update process that keeps producing it.
Tips and tricks
- Keep the original advisory link with the finding so reviewers can see the source without hunting for it.
- Record why a finding was downgraded or deferred. Future-you deserves more than “not worried.”
- Use business context alongside technical severity. A moderate issue on a public client portal may deserve more attention than a higher score in an isolated test system.
- Batch low-risk routine updates, but separate anything that changes authentication, permissions, payment behavior, or public exposure.
Common mistakes
- Sorting only by the scanner’s severity label.
- Assuming every AI-generated finding is correct because the explanation sounds confident.
- Patching production first and asking what broke later.
- Closing findings without verifying the deployed fix.
- Ignoring repeat patterns that point to a process problem instead of a one-time bug.
Infographic: three response lanes
Verified issue, exposed system, meaningful business impact, active exploitation, or another clear reason immediate action is justified.
Verified issue with lower immediate exposure. Test the fix, plan deployment, assign an owner, and keep the deadline visible.
Finding does not apply, vulnerable code is unreachable, or evidence is insufficient. Document why and what would cause reconsideration.
A response lane is a decision, not a hiding place. Every lane needs evidence and ownership.
Human review checklist
- Did we confirm the affected product, component, and version?
- Can we trace the finding to a trusted advisory or reproducible evidence?
- Is the vulnerable path actually reachable in our environment?
- Is there evidence of active exploitation or inclusion in a trusted priority list?
- What client, revenue, data, access, or uptime impact could result?
- Does the proposed fix create operational or compatibility risk?
- Is one person responsible for the next action and deadline?
- Will we verify the deployed fix before closing the finding?
How to measure success
Track median time from finding to triage, percentage of high-priority findings with a named owner, time to remediate verified critical issues, reopen rate after supposed fixes, and the share of findings closed as not applicable with a documented reason.
Also watch the ratio between alerts generated and findings that survive human validation. If discovery volume doubles but useful remediation does not improve, you have more output, not a better security process.
FAQ
Should we patch every critical vulnerability immediately?
Not blindly. Critical severity matters, but your team still needs to confirm that the affected component and version are present, understand exposure, and evaluate the safest remediation path. Active exploitation or direct exposure can justify much faster action.
Can AI decide vulnerability priority for us?
AI can help organize evidence, summarize advisories, compare versions, and suggest priority. A responsible person should still own the final decision because the model may not know your architecture, compensating controls, client commitments, or operational risk.
What if the scanner and vendor disagree?
Keep both pieces of evidence. Check the exact version, configuration, advisory language, and exploit conditions. Escalate uncertain high-impact findings rather than forcing a confident answer where the evidence is incomplete.
Do small agencies really need a formal triage process?
Formal does not mean complicated. A shared queue, four triage questions, response lanes, and a named owner can be enough to stop alert volume from running the day.
Glossary
Vulnerability triage: The process of validating, prioritizing, assigning, and deciding how to respond to a security finding.
Reachability: Whether the vulnerable code or component can actually be reached in the deployed environment.
Known Exploited Vulnerability: A vulnerability with evidence of active exploitation that appears in CISA’s KEV Catalog.
False positive: A reported finding that does not represent a real vulnerability in the reviewed environment.
Remediation: The action taken to remove, reduce, or otherwise address the risk created by a vulnerability.
Sources and further reading
- Anthropic Frontier Red Team: Coordinated Vulnerability Disclosure Dashboard, updated August 26, 2026
- NIST: Secure Software Development Framework
- CISA: Known Exploited Vulnerabilities Catalog
- OWASP DevGuard: risk-based vulnerability management
Related Workflow Edit: Connected AI Apps Need a Permission Review, Not Blind Trust and AI Made the Launch Faster. Now Fix the Review Bottleneck.
Practical closing note
AI is getting better at finding what is wrong. That does not mean your team should get better at panicking.
The advantage comes from pairing faster discovery with a boring, repeatable human decision rule: verify it, understand the exposure, connect it to business impact, assign it, fix it, and confirm the fix.
Next action: Take the last ten vulnerability findings your team received and run each one through the four-question triage path. If you cannot explain why something is urgent, scheduled, or closed, the rule needs work.
