The findings you already have from scanners, pentests, audits and compliance checks, and deciding which ones matter.
Findings are cheap to produce now. Scanners were the old reason, AI-assisted review and AI-authored pull requests are the new one, and past a certain point the list stops being useful. Most organisations we work with can fix a small fraction of what their tools report, so the real question is which findings an attacker could use, and who is going to fix them. Severity scores are a weak guide to the first half of that: we published an unauthenticated remote code execution flaw that had been scored CVSS 5.1, asked twice for it to be rescored, and got no answer.
Each bar is what survives the step above it. The last two are the same width because prioritising does not remove anything. It puts a name against what is left.
Illustrative proportions.
The findings already exist: scanner output, pentest reports, audit and compliance results. The work is deciding which of them are genuinely reachable and exploitable in your environment, and putting a named owner against each one that is. We have run this over estates of more than 200,000 hosts. The number of things your teams are asked to fix each week should be small enough that they fix them.
Where a programme needs a number to steer by rather than a one-off list, we score it on five dimensions: whether every host is scanned at all, whether the critical ones are scanned often enough, whether business criticality changes what gets fixed first, whether findings below critical are ever addressed, and whether patches land inside your own remediation deadlines. People will work to whatever the metric rewards, so the weighting is published, along with how the score moves and what to do about it.
A month after the security alert, about 40% of the Parity Ethereum nodes in Ethernodes.org data were still unpatched. The flaw let any node be crashed remotely, which lowers the compute needed for a 51% attack. The reason it spread so slowly is the part worth knowing: the bug had not been marked critical on Parity’s own update track, so clients running default settings never fetched it. How long a patch takes to land is part of the risk, not an operational detail.
How
Node versions read from their announced headers in data from Ethernodes.org, acquired on 21 March 2019, a month after the security alert for the remotely triggerable integer overflow we disclosed to Parity that February. Ethernodes.org scans the network through the Ethereum discovery protocol and saw close to 11,000 nodes at that time.
The blockchain ecosystem has a patch problemThree flaws in one IT service management product, none of them individually a crisis, chained into unauthenticated remote code execution: an HQL injection to read the database, a weakness in the single-sign-on implementation to log in as an administrator with what the first flaw returned, and a path traversal to upload a web shell. They were assigned CVE-2021-28022, 28024 and 28023. A list that scores each of the three on its own never shows you that path.
Chaining three zero-days in ITSM software for remote code executionLLMs lowered the cost of producing code and the cost of producing findings at the same time, which moved the constraint to verification. Under heavy automated reporting, maintainers began optimising for reducing inbound noise rather than for the underlying risk, so reported counts rose without outcomes improving. Vulnerability counts do not become CVEs, releases or risk reduction on their own.
How
Analysis of LLM-assisted disclosure practice against maintainer response, including the oss-security exchange following a high-volume AI disclosure campaign.
What it does not support
An analysis of disclosure practice and published industry data, not a controlled measurement. It shows the bottleneck moved, not by how much, and the oss-security exchange is one case rather than a survey of maintainers.
AI-generated code, AI-generated findings, and the verification bottleneckWe bring every source into one list and take out what does not need a decision.
We rank what is left by what an attacker could do with it here, not by score.
We stay involved while your teams fix things, and we check the fixes.
A prioritised list decays. What survives an engagement is a number each team can see, built so that the cheapest way to improve it is to do the thing you wanted anyway. Five dimensions, and each one is a behaviour rather than a count of findings.
Visibility
Every host is scanned, not every host someone remembered.
Counts against you:A host that is known to exist and has never been scanned.
Moves it back:Get it into the asset register, confirm it is reachable, put the agent on it.
Regularity
The hosts that matter are scanned on a schedule, not when someone asks.
Counts against you:A business-critical host that has not been scanned in the last seven days.
Moves it back:Enrol the critical estate and track it, then investigate a gap the week it appears.
Criticality
A finding is weighted by what it sits on.
Counts against you:A finding on a business-critical host counts double.
Moves it back:Fix on the critical hosts first, and keep the criticality classifications current.
Sensitivity
Everything counts, not only the criticals.
Counts against you:Every finding and every severity contributes, so a long tail of lows is not free.
Moves it back:Clear the low and medium findings in broad configuration changes rather than one at a time.
Reactivity
Things get fixed inside the deadline your own policy sets.
Counts against you:A patch that took longer than the remediation policy allows for its severity.
Moves it back:Work the queue by severity, business criticality and age together rather than by severity alone.
People will game a metric, so it is worth building one worth gaming. Every team can see what its own number is made of and what would move it, which is the difference between a score that steers work and a score that gets argued about.
We start from the findings you already have. On one estate of more than 200,000 hosts that was several years of scanner, pentest and audit output, and producing more of it was never the constraint. Everything gets one of three outcomes: fix it, accept it with the reason written down, or it was never reachable in the first place. We keep the discarded findings and the reasoning, so an auditor can see why something was set aside and so we can revisit it if the architecture changes. Then we work through the list with your teams, week by week.
Tell us what you are building and what you need looked at. You will get an answer from the people who would run the engagement, and if another firm is the better fit for what you are asking, we will name one.
Security Research Labs is a member of the Allurity family. Learn more(opens in a new tab)