Clearing a 100,000+ Vulnerability Backlog for a Large State Government Agency

The Challenge

A large state government agency had recently completed a major migration from on-premises infrastructure to AWS. The environment supported critical infrastructure services and was substantial in scale - more than 1,400 applications, AWS EKS clusters, Oracle and Microsoft SQL Server databases, and more than a thousand Linux and Windows servers.

During the migration period, vulnerability remediation and patching activity had slowed or stopped across parts of the environment. By the time the issue was escalated, the organisation had accumulated a backlog of more than 100,000 vulnerabilities - and the volume of findings continued to increase each month, despite three separate patching cycles being carried out regularly.

Before establishing Pyneora, our principal architect was engaged to lead the investigation and remediation of this backlog. The first finding was the most important one: this was not simply a lack of patching effort. Three monthly patching cycles were running, yet the backlog kept growing - something structural was wrong.

Investigation revealed multiple compounding issues:

• Asset inventory misalignment. Some active assets were missing from the patching inventory entirely and were therefore never being patched.
• Decommissioning noise. Other systems remained in the active patching process even though they had already been marked for decommissioning - consuming remediation effort on assets that didn't need it.
• Silent patch failures. In a number of cases, patches were failing without visibility, caused by unidentified dependencies or application-specific constraints.
• Stakeholder risk appetite. Many product owners were reluctant to approve database patching due to the perceived risk of breaking critical applications - creating a standoff between cyber risk and operational continuity.

Resolving the backlog required balancing cyber risk, operational continuity, emergency change control, and longer-term ownership of patching across application, database, infrastructure, and security teams simultaneously. No single team owned the full problem.

The Approach

Root Cause Investigation

The vulnerability backlog was reviewed systematically to identify patterns, root causes, affected platforms, and remediation blockers - rather than treating the backlog as a flat list of findings to work through. This investigation specifically asked why vulnerability counts were increasing despite regular monthly patching cycles, which led directly to identifying the asset inventory and patching inventory misalignment.

Inventory Reconciliation

Asset inventory, patching inventory, decommissioning records, and vulnerability management reporting were cross-referenced to identify where the gaps actually were. Active assets missing from the patching inventory were identified and brought into scope; assets still being patched or reported against despite being marked for decommissioning were identified and removed from active remediation effort; and patch failures caused by dependencies, application constraints, unsupported components, and silent remediation failures were investigated individually.

Cross-Team Coordination

Asset ownership and remediation responsibility were confirmed by working directly with infrastructure, security, product, and application stakeholders. This was as much a coordination exercise as a technical one - without clear ownership, vulnerabilities sit unaddressed regardless of how good the tooling is.

Accelerated Remediation Cycle

Additional Linux engineers, Windows engineers, and database administrators were coordinated to increase remediation capacity over an accelerated three-month cycle. Temporary additional resources were secured specifically to support root cause analysis, inventory correction, patch execution, and emergency remediation activity. Emergency change control processes were used to remediate high-risk vulnerabilities where standard patching windows were insufficient to address the risk in time.

Risk-Based Prioritisation

Where database patching presented unacceptable short-term operational risk to critical applications, this was worked through directly with product owners as a risk acceptance discussion rather than forcing patches through against operational objection. Vulnerabilities were separated into those requiring immediate remediation, those requiring formal business risk acceptance, those requiring application testing before a patch could be safely applied, and those suited to longer-term remediation planning.

Long-Term Strategy

The basis for a 12-month vulnerability and patch management strategy was developed to address the recurring causes of the backlog - inventory accuracy, ownership clarity, and risk acceptance processes - rather than only clearing the existing backlog and leaving the same conditions in place to recreate it.

Backlog remediation results:

Metric	Outcome
100,000+	Vulnerabilities reviewed - analysed for root cause, ownership gaps, patching failures, and remediation priority
3 months	Accelerated remediation cycle - additional Linux, Windows, and database resources coordinated for intensive remediation
12 months	Long-term strategy developed - addressing recurring inventory, ownership, and risk acceptance issues at the source

Lessons for Australian Businesses

A growing vulnerability backlog is rarely a patching problem on its own. It's usually a symptom of inventory drift, unclear ownership, or risk-acceptance processes that haven't kept pace with the scale of the environment.

This is particularly common after large infrastructure migrations. The migration itself consumes operational bandwidth, patching cadence slips, and by the time it's restored, the asset inventory and the patching inventory have quietly diverged. Without reconciling the two, remediation effort gets spent on the wrong assets - patching decommissioned systems while live ones go untouched.

Clearing a backlog of this size requires more than additional patching capacity. It requires identifying why the backlog exists in the first place, fixing the structural causes, and building a sustainable vulnerability management process so the same conditions don't recreate the problem months later.

Engagement details have been anonymised. This engagement was delivered by Pyneora's principal architect prior to the establishment of Pyneora as an independent advisory practice.