Field note
What to do when you inherit 223,596 findings
Volume is the symptom, not the problem. On versioned baselines, exploitation-based prioritization, and why the first real fix is asset ownership tagging.
The baseline was 223,596 open findings across 1,975 assets spanning twelve asset categories.
That number is the least interesting thing about the situation, and leading with it is a mistake I want to help you avoid. Large numbers invite the wrong response — more scanning capacity, more engineers, an escalation to leadership about the size of the problem. None of that helps, because volume was a symptom.
The actual problem was that there was no remediation process. Not a weak one. None. No intake, no triage, no risk tiering, no verification, no defined ownership. Findings were generated by the scanning platform and landed nowhere.
What that meant in practice
Three structural failures compounded each other.
Cluster resources carried no ownership or environment tags, so a large share of container findings were structurally orphaned — nobody could be assigned them even in principle. You cannot route work to an owner you cannot identify, and no amount of process design fixes an asset inventory that does not know who owns what.
There was no governed path to formally accept risk on findings with no available fix. So unfixable findings aged in place, permanently, inflating the count and steadily eroding anyone's belief that the number meant anything.
And for leadership, the practical consequence was that posture was unreportable. You could produce a count. You could not answer whether risk was going down, who owned what, or what needed deciding — which are the only three questions an executive actually has.
Version the baseline before you touch anything
The first thing we did was version the baseline. This sounds like administrative overhead and it is the load-bearing decision in the entire program.
Without a controlled baseline you cannot prove closure. And unprovable closure is worthless — to an auditor, and to a CIO who is being asked to believe that a number went down. Every subsequent claim in this program rests on being able to say precisely which population we were measuring, at what point in time, and what happened to each finding in it.
Prioritize by exploitation, not by severity
The governing rule became known exploitation rather than CVSS base score. Actively exploited vulnerabilities were expedited ahead of the general backlog regardless of score.
Against a backlog of that size, ranking by base score produces a queue nobody can execute while leaving the findings actually being weaponized sitting behind higher-scoring findings that are not. That is not a theoretical concern; it is what a severity-ranked queue does every single day it exists.
The arithmetic on our baseline is worth showing, because it is not what people expect. Of 787 CVEs, 421 sat on virtual machines already slated for decommission — those retired with the hosts rather than consuming patch cycles. That left 366 to triage. Of those, 126 were rated as actively exploited, and those went first.
Distinguishing remediation from elimination is a judgment a lot of vulnerability programs never make. They patch everything, because the scanner said so.
Move accountability to the asset owner
We designed a RACI across the full lifecycle — discovery, triage, prioritization, assignment, execution, verification, exception handling, reporting — spanning vulnerability engineering, application teams, and cloud subscription owners.
One detail mattered more than the document: it was socialized individually with each team lead before publication, so nobody first encountered their obligations in a group forum. A RACI that surprises people in a meeting gets litigated in that meeting.
The load-bearing principle is that accountability for unremediated risk sits with the asset owner, not with the security team. That reframing is the entire program in one sentence. It converts remediation from a security request — which competes with the owning team's roadmap and usually loses — into a business obligation the owner carries. Formal adoption then produced a two-track routing model that made assignment automatic rather than negotiated each time.
Then do the unglamorous thing
We implemented ownership and environment tagging across cluster resources.
This is the least interesting sentence in this article and the governance model depended entirely on it. A RACI is only as good as your ability to identify who the responsible party is for a given asset. Findings that had been unassignable in principle became routable, which is the difference between a process that exists on paper and one that runs.
Build a defensible acceptance path
For findings with no available fix, we built a governed risk-acceptance path with GRC. Acceptances are packaged at CVE-asset decision grain, each with a named compensating control, a named owner, a full audit trail, and a scheduled re-review.
Not bulk category-level acceptance. A blanket acceptance is indefensible under examination and everyone involved knows it; a CVE-asset acceptance with a documented compensating control and a review date is a risk decision somebody made on purpose. Over the program that came to 55,532 governed acceptances alongside 129,825 remediations — and the distinction between those two numbers is one I would want any assessor to interrogate, because it holds.
Report from one source
Executive reporting was rebuilt around monthly CIO reporting on disposition, velocity and exploitation posture, published from a single governed source with data-integrity checks applied before publication.
The integrity checks matter. A reporting line that produces a number leadership later discovers was wrong does more damage than no reporting at all, because it costs you the thing you were trying to build.
What I would tell the next person
The baseline closed one hundred percent — all 223,596 findings dispositioned to zero open across 1,975 assets and twelve categories. The program now runs a governed weekly steady state with named owners.
But the forward-looking finding is the one worth passing on. Monthly inflow was accelerating as scan coverage expanded — roughly 11,500 in one month, 14,900 the next. Steady-state capacity has to be planned against a rising flow rate, not against a fixed backlog. Programs that size themselves to clear a backlog succeed once and then quietly fail, because the backlog was never the thing they needed to survive.
If you have just inherited a number like this: do not start by attacking the number. Start by establishing who owns what, what a controlled baseline looks like, and how a finding that cannot be fixed is allowed to be closed. The number takes care of itself once those three things exist.
← All writing