How to Build a Vulnerability Triage Agent for Security Teams

Vulnerability management fails at the same point everywhere: the scanner produces tens of thousands of findings, ranked by a score computed without any knowledge of the environment, and the team remediates whatever it can reach. The consequence is that easy low-risk findings get closed while exploitable ones on critical systems age. An agent that prioritises by actual risk changes that. This guide covers building one, drawing on FISTA Solutions' AI agents work in security operations. It complements the AI security operations whitepaper and ai vulnerability management. This article is general guidance, not legal advice.

What is wrong with severity scores?

They are context-free by design. A base score describes a vulnerability in the abstract: what it permits, how it is accessed, what it requires. It knows nothing about whether your instance is internet-facing, whether the vulnerable function is called, what compensating controls exist, or how critical the asset is.

Prioritising by base score therefore produces a queue that correlates weakly with real risk. Every mature programme adds environmental context; the question is whether that happens systematically or in the head of one experienced engineer.

Factor	Effect on real risk	In base score
Known active exploitation	Very large	No
Public exploit availability	Large	No
Internet exposure	Large	Partially
Asset criticality	Large	No
Code reachability	Large	No
Compensating controls	Moderate	No

Why does exploitation status dominate?

Because the vast majority of vulnerabilities are never exploited, and the ones that are tend to be exploited soon after disclosure. Knowing that a vulnerability is under active exploitation, or that working exploit code is public, changes priority far more decisively than moving from high to critical on a severity scale.

This information changes daily, which means the enrichment must be continuous rather than applied once at ingestion. A finding that was low priority last month can become the most urgent item in the queue overnight.

What does reachability analysis contribute?

Honesty. A vulnerable dependency whose affected function is never invoked by the application is genuinely lower risk, and saying so is more defensible than deferring it silently. For organisations with large dependency trees, reachability analysis removes a substantial share of findings on a principled basis.

It is not a complete answer — reachability can change with a code change, and dynamic invocation defeats static analysis — so the finding should be recorded as unreachable rather than dismissed, and revisited when the code changes.

Why is owner routing the practical bottleneck?

Because findings sent to a generic security queue sit there. Remediation happens when the team that owns the service receives the finding in the workflow they already use, with the specific action stated: upgrade this package to this version, apply this configuration, deploy this patch.

Ownership data is usually the missing input, and it is usually incomplete. Building it — even partially — often produces more remediation improvement than any refinement of the prioritisation model.

How do compensating controls fit?

As explicit inputs, recorded and reviewed. A vulnerability mitigated by a network control, a WAF rule, or a configuration is genuinely lower risk, and pretending otherwise causes teams to ignore the whole queue. Pretending it is eliminated is equally wrong, because controls change.

The right treatment is a recorded mitigation with an owner and a review date, so that a removed control resurfaces the finding rather than leaving it permanently suppressed.

What about accepted risk?

Same principle. Risk acceptance is legitimate and must be explicit: who accepted it, on what basis, for how long, and when it will be reviewed. Findings that are silently ignored are the ones that appear in an incident report, and an agent that makes acceptance a recorded decision improves the programme's defensibility considerably.

How should the agent handle patch reality?

By knowing what is actually deployable. A recommendation to upgrade a package to a version that breaks the application is not a remediation; it is a ticket that will be closed as won't fix. Where the agent can identify the minimum viable upgrade, note breaking changes, or propose a configuration mitigation instead, its recommendations get acted on.

How does it integrate?

With scanners and software composition analysis for findings, asset inventory and CMDB for criticality and ownership, threat intelligence for exploitation status, and the engineering teams' own issue trackers for routing. Security should see the aggregate; engineers should see work in their backlog.

How is it evaluated?

On risk reduced over time, mean exposure time for exploitable findings on critical assets, remediation rate by owner team, and the age distribution of high-risk findings. Tickets closed and total finding count both improve while the dangerous items age untouched.

What does the build sequence look like?

Two weeks on asset criticality and ownership data, which is the limiting factor. Two weeks on continuous exploitation enrichment. Two weeks on the prioritisation model with security team calibration. One week on owner routing into engineering workflows. Reachability analysis and mitigation tracking after the core loop is working.

What goes wrong?

Prioritising by base score. One-time enrichment. No ownership data, so everything routes to security. Suppression without review dates. Recommendations that break applications. And measuring closure counts, which actively rewards the wrong work.

What does it cost to run?

The enrichment and prioritisation are inexpensive relative to scanning itself. The cost that matters is building and maintaining asset ownership data, which is an organisational problem rather than a technical one and which benefits far more than vulnerability management.

What should you do first?

Take your current top hundred findings by severity and re-rank them by exploitation status and asset exposure. The lists will overlap far less than expected, and that comparison is usually enough to change how the programme is run.

How does this apply to container and cloud workloads?

Ephemeral infrastructure changes the remediation model entirely. A container is not patched; it is rebuilt from an updated image, which means the fix belongs in the base image and the build pipeline rather than in a running system. Findings should therefore route to whoever owns the image, and a single base image update often resolves thousands of findings across hundreds of workloads at once.

How FISTA Solutions helps

FISTA Solutions builds vulnerability triage systems with continuous exploitation enrichment, environment-aware prioritisation, reachability analysis, owner routing into engineering workflows, reviewed mitigation and acceptance records, and measurement against risk reduced, through AI agents, AI enablement, and forward deployed engineers. The record behind the approach is 150+ projects for 50+ companies with 99.9% uptime.

To remediate what actually matters rather than what is easiest, message FISTA on WhatsApp, or read the AI security operations whitepaper.