Vulnerability Remediation Management: Who Actually Fixes the 90,000 Findings in Your Scanner?

The report that started this project

A vulnerability management lead is asked for a single slide before an audit committee meeting. The slide should say whether the organisation is getting safer. What she has is 94,000 open findings across Tenable, Qualys and a container scanner, a number that went up last quarter because the estate grew, and no way to say which of those findings represent real exposure. She knows perhaps a hundred of them genuinely matter. She cannot prove which hundred, and she cannot show that anyone is fixing them, because remediation happens in six different team backlogs in Jira, ServiceNow and one spreadsheet maintained by the database group.

The uncomfortable part is that the scanners are working correctly. They are doing what they were bought to do, which is find things. The broken step is everything after the finding: deduplicating the same weakness reported three times by three tools with three different identifiers, deciding who owns the affected host, deciding whether the finding matters given what else is true about that host, getting it into the owning team's actual work queue, and knowing when it is closed for real rather than closed because the host was rebuilt and the scanner stopped seeing it.

Where Tenable, Qualys and Rapid7 stop being the answer

These are competent scanners and you should keep at least one. Tenable and Qualys have decades of detection coverage and their finding quality is not the problem. What they cannot do is arbitrate between themselves. If Qualys reports a finding on a host by IP address, Tenable reports it by hostname and your container scanner reports the same underlying library in an image, you have one weakness and three tickets, and no tool that owns only its own data can collapse them.

The prioritisation story has the same shape. Every scanner scores against a general model, usually CVSS, sometimes with an added vendor rating. That model does not know that a given host has no inbound network path, that a compensating control blocks the exploitation route, or that the same weakness on a payment processing server is a different conversation from the developer laptop next to it. Exploit prediction scoring and the CISA known exploited vulnerabilities catalogue improve the picture and are genuinely worth incorporating, but they still describe the vulnerability rather than your exposure to it.

The remediation aggregation vendors, Nucleus Security, Vulcan Cyber, Brinqa and Seemplicity, exist precisely because of this gap, and they solve part of it. Where organisations hit their limits is ownership and workflow. Every product ships an ownership model based on tags, and every real estate has ownership rules that are messier than tags: this subnet belongs to that team except for the four hosts the acquisition brought in, container images inherit ownership from the repository that built them, and the cloud accounts follow a naming convention that changed in 2023 and was never backfilled. Encoding your actual rules, rather than the ones a product hopes you have, is the work.

Deduplication is the foundation and it is harder than it looks

Start here because every other number depends on it. A finding is a triple of weakness, asset and location, and each of those three is reported differently by every tool. Asset identity has to be resolved first, the same way it does in any security data problem: hostname, IP at a point in time, cloud instance identifier, MAC address, agent identifier and asset tag all pointing to one object, with a confidence score and a manual merge path for the ambiguous cases. Get this wrong and your dedupe either merges two hosts into one, which hides a real finding, or fails to merge and inflates your backlog.

The weakness side needs a canonical identifier per finding, usually a CVE where one exists, plus a defined way to handle the significant portion of findings that have no CVE at all: misconfigurations, weak ciphers, end of life software, policy failures. Those are the findings most likely to be reported differently by each tool and least likely to deduplicate on their own. Build an explicit mapping table and accept that it needs maintenance, because pretending it does not is how these projects quietly produce numbers nobody trusts.

Ownership is an organisational problem wearing a technical costume

The reason findings sit open for eighteen months is almost never that they are hard to fix. It is that no named human ever accepted them. A ticket routed to a team queue with no individual attached is a ticket that dies quietly.

Build ownership as a rules engine with a resolution order you can inspect: explicit assignment first, then cloud account or resource tag, then subnet or network zone, then the configuration management database, then a fallback owner who is a real person and whose queue is visibly embarrassing. The fallback matters more than the sophisticated rules, because an unowned finding must be uncomfortable for someone or the model has no teeth. Report the unowned rate weekly. It is the single healthiest metric in this domain and it goes down fast once people can see it.

Then push work into the systems the owning teams already live in. A platform that asks a database team to log into a security tool to see their findings will be ignored. Two way integration with Jira and ServiceNow, where the ticket in their board is the work item and status flows back automatically, is the difference between a platform people use and one that generates a monthly email nobody opens.

Exception handling is what makes the backlog honest

Some findings will not be fixed, and pretending otherwise is why backlogs grow forever. The vendor no longer supports the appliance. The application will break. The system is being decommissioned in nine months. Those are legitimate outcomes and they need a first class workflow: a documented compensating control, a named risk acceptor with the authority to accept it, an expiry date, and automatic reappearance in the queue when the exception lapses. Without that, exceptions live in email and the same finding is rediscovered and re-escalated every quarter by whoever is new.

This is also what turns the board slide into something defensible. The honest statement is not that the backlog shrank. It is that of the findings meeting your risk threshold, this many were remediated within the target window, this many are formally accepted with named owners and expiry dates, and this many are overdue and here is why. Regulated organisations get a second benefit: PCI DSS expects critical patches within a defined window, and cyber insurers now ask remediation timeframe questions on renewal, so having the evidence generated rather than assembled is worth money at renewal time.

What a custom build must include

• Connector layer pulling from each scanner on its own schedule, tolerant of partial scans and API rate limits.
• Asset identity resolution with confidence scoring and manual merge, feeding from your configuration management database and cloud inventory.
• Deduplication to one canonical finding per weakness per asset, including the non CVE findings that will not deduplicate themselves.
• A risk model you control, combining severity, exploit intelligence, asset criticality, network exposure and compensating controls, with the ability to explain any score.
• Ownership rules with an inspectable resolution order and a visible fallback owner.
• Two way Jira and ServiceNow integration so work lives where the fixing teams already work.
• Exception workflow with named acceptors, compensating controls and expiry dates that automatically reopen.
• SLA clocks by risk tier, with reporting that is generated rather than assembled.

What it costs and how long it takes

From the projects Digital Heroes has delivered, a first release covering scanner connectors, asset resolution, deduplication, the ownership engine and Jira or ServiceNow integration runs $80,000 to $160,000 and ships in 12 to 18 weeks. That version already gives you a trustworthy backlog number and a named owner on every finding, which is most of the value. The full platform adding your own risk scoring model, exception workflow, SLA tracking, executive reporting and container or cloud posture sources runs $200,000 to $450,000 phased over 6 to 12 months.

What drives cost up: the number of scanning tools, since each connector is real work and several have unpleasant pagination and rate limiting. The state of your configuration management database, which is the single biggest schedule variable, because ownership rules built on a stale asset register produce confident wrong answers. Multiple business units with different SLAs and different risk appetites. And any requirement to include operational technology or medical device estates, where scanning itself is constrained and the data arrives differently.

What keeps it down: start with the two scanners that produce most of your findings and the three teams that own most of your estate. Long tail sources can wait a quarter.

When you should buy instead

One scanner, a few hundred assets and one infrastructure team means you do not have an aggregation problem. Tenable or InsightVM with a maintained asset register and a monthly review meeting will serve you better than any build, and we would say so.

If you have the multi scanner problem but a fairly clean asset register and conventional ownership, evaluate Nucleus or Vulcan honestly before building. They are good at what they do and a subscription beats a project when the shoe fits.

Build when your ownership rules cannot be expressed as tags, when you need a risk model that reflects compensating controls specific to your architecture, when regulatory evidence requirements shape the workflow, or when you have already bought an aggregation product and are maintaining a spreadsheet next to it. That last one is the reliable signal.

How to choose a developer

Ask how they will deduplicate a finding reported by two scanners using different asset identifiers, and expect a real answer about identity resolution rather than string matching on hostnames. Ask what they will do with findings that have no CVE, since that is where naive dedupe collapses.

Ask how the ownership rules engine handles the case where no rule matches. If the answer is not a named fallback human with a visible queue, they have built a system where findings can disappear.

Ask specifically which scanner APIs they have worked with and what broke. Anyone who has integrated Qualys or Tenable at scale has an opinion about pagination and incremental sync. A developer with no war story here has not done it.

Ask what happens when a scan is partial or fails, because a missing scan must not silently look like remediation. Findings that vanish because a scanner could not reach a subnet are the quiet failure mode of every platform in this category.

Get code ownership in writing before kickoff, covering the repository and the infrastructure accounts. At Digital Heroes the client owns the code from the first commit. A system that holds your exposure data is a poor thing to rent from a supplier you cannot replace.