The number nobody calculates
Ask a CISO what their organisation spends per vulnerability finding and you will usually get a blank look. Not because the question is unfair, but because nobody has done the arithmetic. Security teams measure backlog size, mean time to remediate, severity distributions, and a dozen other things, but the unit cost of triage is almost never on the dashboard. It should be. Without it, you cannot tell whether your program is getting more efficient or just busier.
Cost per finding is straightforward to compute. Take the fully loaded cost of every person who touches the triage workflow, including security engineers, application developers pulled in for context, the analyst who routes Jira tickets, and the manager who runs the weekly review. Add tooling costs amortised over the volume. Divide by the number of findings closed in the period. The result is usually somewhere between 80 and 250 dollars per finding for organisations that have not actively optimised, and it climbs steeply as backlog age increases.
That number, multiplied by the volume of findings flowing through your environment, is the actual cost of your vulnerability management program. For a team handling 10,000 findings a year at 150 dollars each, the answer is 1.5 million dollars. Most security leaders, when shown that calculation for the first time, push back. Not because it is wrong, but because nobody asked them to defend a number that size.
Where the time actually goes
Once you start instrumenting triage time, the distribution is rarely what people expect. The popular intuition is that the heavy cost sits in deciding whether a finding is exploitable. In practice, that decision is a small fraction. The dominant cost is context reconstruction.
Context reconstruction is the time an engineer spends figuring out which service uses the vulnerable component, which version is deployed where, who owns it, whether there is a fix version, and whether the fix introduces breaking changes. None of that is security work in the strict sense. It is information retrieval. And it gets repeated for every finding, because most tooling treats each advisory as a fresh page rather than as part of a connected graph.
The second-largest cost is hand-off. Security identifies the issue. Engineering owns the fix. The handoff usually goes through a ticketing system, which strips most of the context security already gathered. The receiving engineer rebuilds it, often by asking the security engineer the same questions in a Slack thread. That round trip is invisible in any dashboard but extremely visible in calendar time. We routinely see findings where the actual fix takes 30 minutes and the round trip takes three days.
The third cost is duplication. The same upstream CVE shows up in three different scanners, sometimes under three different identifiers. Each one generates its own ticket. Each one gets investigated independently. By the time someone notices they are all the same issue, several engineers have already spent an hour each on it.
What reachability does to the unit cost
Reachability analysis attacks the cost equation at its base. If 70 percent of incoming findings are not reachable from your application surface, then 70 percent of the volume can be triaged in seconds rather than minutes. The marginal cost of an unreachable finding, with proper tooling, is close to zero. The system tags it, sets the priority, schedules it for the next dependency refresh, and moves on. No engineer reads it. No ticket gets routed. No Slack thread happens.
This is not a quality compromise. The unreachable findings still get fixed when their host package is upgraded, which usually happens within a quarter as part of routine maintenance. What changes is that they stop consuming triage budget. The engineering hours saved are real, and they show up directly in the cost-per-finding metric.
In the data we see from teams that have rolled out reachability scoring, the cost per finding for unreachable items drops by 90 to 95 percent. The cost per finding for reachable items stays roughly the same, because those still require human investigation. But the weighted average drops dramatically, because reachable findings are the smaller share of the queue.
Automation as cost compression
After reachability, the next lever is automated remediation. The cost of a finding where a clean fix version exists and the dependency bump can be opened as a PR is dominated by review time, not investigation time. Generating that PR automatically, running CI, and assigning the right reviewer compresses the workflow into the engineer's normal code review flow.
The economic effect is twofold. First, the security engineer's time is no longer spent on routine fixes. Their hours move toward the harder findings, which is the work they were hired for. Second, the developer's review time is bounded by the size of the diff, not by the size of the queue. A small dependency bump takes a few minutes. The engineer reviews, merges, and the finding closes. There is no separate triage call, no Jira hand-off, no context reconstruction.
Teams that have wired reachability filtering into auto-PR generation typically land cost per finding somewhere in the 15 to 30 dollar range, down from the 150 dollar starting point. That is not a 20 percent improvement. That is an order of magnitude.
Griffin AI and the long tail
The findings that resist both filtering and automation are the ones where context matters in ways the tooling cannot infer. A vulnerability whose exploitability depends on whether a particular feature flag is enabled. A CVE that only triggers under a specific deployment topology. A library that has been forked internally with backported patches. These are the cases where a senior engineer historically spends an hour or more, and where the cost-per-finding metric stays stubbornly high.
Griffin AI compresses this tail by doing the context reconstruction the engineer would otherwise do. It reads the advisory, scans the codebase, checks deployment configuration, looks at historical resolutions of similar findings, and produces a recommendation with reasoning attached. The engineer reviews the recommendation rather than building it from scratch. In our deployments, the average engineer time per ambiguous finding drops from 60 minutes to between five and ten.
The cost effect at the program level is significant. The long tail of high-cost findings has historically been where vulnerability management programs spend their budget, even though those findings represent a small fraction of total volume. Compressing that tail with AI-assisted triage is what takes a program from operationally expensive to financially sustainable.
A defensible number for the board
Once you have the unit cost calculation and the levers in place to drive it down, you have a story you can tell to a board or a CFO that does not depend on fear. You can show the cost per finding before optimisation, after reachability filtering, after auto-PR rollout, and after Griffin AI integration. You can show the projected annual cost at current finding volume. You can show what each additional capability would save.
That is a different conversation from the one most security leaders are stuck having, where they argue for headcount on the basis of risk vague enough that finance cannot evaluate it. Cost per finding is a number finance understands. Driving it down by an order of magnitude is a number that gets approved.
How to instrument the metric without slowing the team
The objection most teams raise when introduced to cost-per-finding is that capturing the data will create even more overhead than they already have. The objection is fair, but the implementation is lighter than it sounds. Most ticketing systems already capture status transitions with timestamps. Calculating triage time from those timestamps requires no manual logging, only a small reporting layer that joins ticket data against the salary cost of the people who handled the tickets.
The accuracy does not need to be perfect to be useful. A cost-per-finding number with plus or minus 20 percent error is more than enough to make decisions on. The trends matter more than the absolute number. If the metric drops by 60 percent quarter over quarter, the magnitude of the improvement is unambiguous even if the precise dollar figure is approximate. Teams that wait for perfect instrumentation to start measuring usually never start. Teams that start with rough numbers and refine as they go end up with both the metric and the operational improvement that the metric makes visible.
The other practical instrumentation point is to separate one-time investigation costs from recurring touch costs. A finding that gets investigated once and closed has a different cost profile from one that bounces between security and engineering five times before resolving. Treating both as a single number obscures the bouncing pattern, which is precisely the pattern that automation and AI triage are designed to eliminate. Decomposing the metric into investigation, hand-off, and resolution segments gives the team specific places to apply the levers.