Vulnerability triage is not going away, but the manual part is shrinking. Automated checks can now filter findings by exploit evidence, reachability and exposure, leaving people to set policy and decide the exceptions. Teams that keep sorting long lists by hand are doing work that software can do.
What is triage for?
Triage answers one question for each finding: what should happen, by when, and who does it? Fix now, fix later, accept, or ignore because it does not apply. The goal is to spend scarce engineering time where risk is highest.
For years that meant a person reading a list ranked by severity score and guessing. Severity alone is a poor guide. CVSS describes the intrinsic severity of a flaw, and FIRST, which maintains it, states that it is not a measure of risk by itself. Risk depends on whether the flaw is exploited, whether your code is reachable and what the asset does.
Which signals can be automated?
Several inputs are public and machine readable.
- Known exploitation. CISA's Known Exploited Vulnerabilities catalog lists flaws with evidence of exploitation in the wild. Federal agencies have deadlines to fix them, and the list is a strong signal for everyone.
- Likelihood estimates. FIRST's Exploit Prediction Scoring System publishes a probability that a CVE will be exploited in the next 30 days.
- Reachability. Whether the vulnerable function is actually called from your code, which analysis of the code can estimate.
- Exposure. Whether the affected service faces the internet.
- Fix availability. Whether a patched version exists and is compatible.
Combined, these remove much of the list. A medium score in a function your code never calls differs sharply from a medium score on an internet facing route with active exploitation.
What stays with people?
Judgment about business context and about policy. A machine can say a library flaw is reachable. It cannot know that the service holds regulated data, that a release freeze starts tomorrow or that the owner is on leave.
People should do three things: write the rules that decide default actions, review exceptions and unusual cases, and audit the automation. An automated filter that quietly drops findings needs a regular sample check, or you will not know when it is wrong.
What does the new workflow look like?
A finding arrives. Rules check known exploitation, reachability and exposure. Findings that meet a clear bar open a pull request with a proposed fix or a ticket with a due date. Findings that clearly do not apply are closed with a recorded reason. The small middle group goes to a person with the evidence attached.
Notice that the record matters as much as the decision. An auditor or a customer reading your process wants to see why something was ignored.
A constructed example
A team's scanner reports 640 findings. After filtering for reachability, 70 remain. Of those, 6 are on the exploited list or have a high likelihood score and are internet facing. Those six get fix pull requests this week. The 64 others get scheduled with a date. The 570 unreachable findings are closed with the reason recorded and are re-evaluated when the code changes. The human time went from reading 640 entries to reviewing six decisions and the rules.
What are the risks?
Over-trust. Reachability analysis has limits, such as dynamic calls, so treat it as strong evidence, not proof. Likelihood scores are statistical. And a closed finding can reopen when code or exposure changes, so the system must re-check, not forget.
How to check or apply this
- Count your current open findings and the median age of each severity.
- Add known exploitation and reachability to your ranking.
- Define default actions for each combination in writing.
- Require a recorded reason for every closure.
- Sample automated closures every month.
- Re-evaluate closed findings when dependencies or code change.
- Keep humans on exceptions, policy and customer impact.
Safeguard provides reachability analysis, and autonomous remediation that proposes fix pull requests, which are off by default so a person turns them on and reviews every change.
Quick check
Is CVSS enough to prioritise?
No. It measures severity, not risk. Add exploitation evidence, reachability and exposure.
Should automation close findings on its own?
Only under written rules with recorded reasons and regular sampling, so mistakes get found.
Sources
- CISA Known Exploited Vulnerabilities Catalog
- FIRST: Exploit Prediction Scoring System
- FIRST: Common Vulnerability Scoring System
- NIST SP 800-40 Rev. 4: Enterprise Patch Management Planning
Last reviewed: 18 October 2026.
