For twenty years vulnerability management has worked like a queue. Findings arrive, you rank them, you fix the worst ones, and you report a backlog trending down. Some version of open findings goes to the board every quarter, and the story is that the line is heading in the right direction. That model earned its place. It gave the work structure, it gave directors something to watch, and the assumption underneath it held for two decades.
The assumption was that inbound findings were bounded by human effort. Somebody had to go looking for a flaw before anyone could find one.
That assumption died this summer.
Palo Alto's Unit 42 ran an autonomous vulnerability research system called NOVA across 3,915 open source projects. In two months it produced 14,090 confirmed vulnerabilities, 99.4 percent of them previously unreported. Of those, 5,600 rated High or Critical under CVSS 4.0. The system was particularly good at the category we have spent years telling boards is hard, the semantic and logic flaws around access control, authorization, path traversal and injection, the ones that need reasoning about intent rather than pattern matching on memory corruption.
Read that again as a rate rather than a headline. One system, two months, fourteen thousand findings in software your organisation almost certainly depends on. Nobody had to be paid to look.
Two rates, and only one of them lost its ceiling
Every vulnerability program is really two rates running against each other.
Discovery inflow, meaning the rate at which new findings arrive in your queue. And remediation throughput, meaning the rate at which your organisation can validate, schedule, test, deploy and confirm a fix.
For twenty years both rates were bounded by the same scarce input. Skilled human attention. Researchers had to look, and engineers had to fix, and both were rationed by headcount. That shared constraint is what made the backlog a sensible thing to measure. If inflow and throughput are governed by the same scarce resource, then a growing queue really does tell you something about how well the team is performing.
Automation removed the ceiling on one of those rates and left the other exactly where it was. Unit 42's own research puts average patching at 55 days, and nothing about an autonomous discovery system shortens the change window, the regression test, the maintenance freeze or the vendor's release schedule.
So the arithmetic changed underneath the metric, and the metric did not notice.
A queue whose inflow exceeds its throughput does not have a backlog problem. It has an arithmetic problem, and arithmetic problems do not respond to effort. Your team can double its output and the line still climbs, because the thing feeding the line is no longer rationed by anything your team controls. The backlog number stops being a measure of performance and becomes a measure of how long the scanner has been running.
What this looks like on a Monday
A security engineer opens the console at nine. Overnight the dependency scanner has ingested a new feed and there are 4,100 additional findings, 600 of them High or Critical. None of them are new code. They are the same libraries that were there on Friday, now looked at by something that reads faster.
The questions start immediately, and every one of them is reasonable. Which of these are actually reachable from our applications? Which of these libraries ship in the product versus sit in a build container? Do we have a fix available, or does this need the upstream maintainer to act first? Does the change window open before the end of the quarter? Who signs off on a patch to the payments service? Is the compensating control we put in place last year still working, and can anyone prove it?
By eleven the engineer has answered maybe forty of the six hundred. Meanwhile the quarterly board deck template asks for one number, total open findings, and that number is now 4,100 higher than the last one for reasons that have nothing to do with anybody's performance.
That is the moment the reporting model breaks. Not dramatically. Quietly, while everyone is working hard.
The objection, which is a good one
The obvious response is that prioritisation already solves this, and the people making that argument are not wrong.
Exploit prediction scoring tells you the probability a flaw gets used in the next thirty days. The CISA known exploited catalogue tells you what is being used right now. Reachability analysis tells you whether your application ever calls the vulnerable function, and in most codebases the majority of flagged dependency findings turn out to be unreachable. Stack those three filters and a five-figure queue collapses into a few hundred items a real team can finish. This works. It is the single highest-return move available in vulnerability management today and any program not doing it should start this quarter.
But look carefully at what prioritisation actually does. It changes which items you work on. It does not change what happens to the items you never reach.
Those items do not disappear when you filter them out of the view. They remain in your environment, unfixed, and someone has effectively decided not to fix them. Right now that decision is being made by default, by nobody in particular, with no name attached, no reasoning recorded and no date on which anyone revisits it. Filtering is not deciding. It just moves the undecided somewhere you stop looking.
The Acceptance Ledger
If you cannot fix everything, and the arithmetic now says permanently that you cannot, then the governable object is no longer the backlog. It is the set of things you have consciously chosen not to fix. Write that down and you have an Acceptance Ledger.
Each entry carries five things. The finding. The named human who accepted it, an individual and not a team. The reason, in one sentence a director could follow. The compensating control, if there is one, and honesty if there is not. And an expiry date on which the acceptance lapses and has to be renewed or closed.
That last field is the one that does the work, because an acceptance with no expiry is not a decision. It is forgetting, with paperwork.
If a finding is fixed, that is an engineering outcome. If a finding is accepted with a name and a date, that is governance. If a finding is filtered out of the view and never thought about again, that is neither, and it is the one your regulator, your carrier and eventually your plaintiff will ask about.
What to ask on Monday
You do not need my framework. You need answers to five questions about your own organisation, and you can get them this week.
How many findings did we consciously decide not to fix last quarter, and can we produce that list on demand? Whose name is on those decisions, and is it a person or a team? What is the median age of an unremediated High finding, and does anyone revisit it on a schedule? When a finding is filtered out by reachability or exploit probability, is that recorded as a decision or does it simply vanish from the queue? And if a regulator asked us tomorrow to show our risk acceptance process, would we send a document or would we start writing one?
The uncomfortable answers cluster. One organisation discovers its prioritisation is excellent and nothing downstream of the filter is recorded at all. Another finds acceptances are recorded but have no owner, so nobody can be asked about them. Another finds owners exist but no expiry dates, so a decision made against a 2023 threat model is still quietly in force. Another finds the whole thing lives in a spreadsheet one person maintains, and that person is the single point of failure for the company's documented risk position.
What changes once you accept the arithmetic
The board metric stops being a count of findings and becomes a description of a risk position. Prioritisation stops being the end of the process and becomes the beginning of a decision that has to be recorded. Risk acceptance stops being an exception workflow buried in the GRC tool and becomes the primary output of the security program. And the question directors ask stops being how many are open and becomes who decided, and when does that decision expire.
None of that requires new tooling. Most GRC platforms already have the fields. What is missing is the decision to treat acceptance as the deliverable rather than the embarrassment.
Start this quarter. Take your top ten unremediated High findings, put a name and an expiry date against each one, and bring that list to your next board meeting instead of the trend line. It will be the first slide in years that survives a hard question, because it is the only one describing something you actually control.
You are never going to fix everything again. The only question your board can still govern is whether you decided what not to fix, or whether it decided itself.
