CVSS was built to answer one question: how bad is this vulnerability in the abstract? It scores exploitability and technical impact on a 0 to 10 scale, assuming a generic target. That is genuinely useful for triage at the individual-finding level, and it is the lingua franca every scanner speaks. But CVSS was never designed to answer the question a security leader actually has to answer on Monday morning, which is: of the four thousand open findings in my backlog, which handful should my team fix this sprint to protect the business the most? Severity is an input to that decision. It is not the decision.
The gap shows up the moment you put two findings side by side. Consider a CVSS 9.8 remote code execution flaw on a staging server that holds synthetic test data, sits behind the VPN, and connects to nothing of value. Now consider a CVSS 6.1 broken-access-control issue on the checkout service that processes every dollar of online revenue, touches the customer PII store, and is reachable from the public internet. A backlog sorted by CVSS puts the 9.8 on top and the 6.1 somewhere on page three. A backlog sorted by what the company stands to lose inverts that order. The severity score is correct in both cases and useless for the comparison, because it has no idea what either asset is worth.
The missing variable is exposure: not network exposure, but financial exposure. A vulnerability does not cost anything by itself. It costs something only when an attacker uses it to reach an asset, and that asset is tied to revenue, to EBITDA, to a regulatory obligation, or to a contractual commitment. The same SQL injection finding is a rounding error on an internal wiki and a material event on the system that runs your billing. CVSS holds the asset constant at 'generic.' The real world does not. To rank a backlog by business impact you have to break that assumption and carry the value of the protected asset all the way through the calculation.
Mapping a finding to the money it exposes is a chain of joins, and each link is an honest engineering problem rather than a magic score. The first link is finding-to-asset: a SARIF result or scanner export names a file, a repository, a service, or a host. You resolve that to a logical application or business capability, the thing the org actually thinks of as 'the payments service' rather than 'repo seventeen.' The second link is asset-to-value: that capability supports some slice of revenue, some volume of sensitive records, some uptime commitment. The third link is value-to-loss: if the finding were exploited, what is the plausible range of dollar loss given the data it exposes, the downtime it could cause, the records that could be breached, and the regulatory exposure that follows.
None of those links is precise, and pretending otherwise is how risk quantification earns its bad reputation. Asset value is an estimate. Breach cost is a distribution, not a number. Exploit likelihood is a judgment informed by exposure and exploit availability, not a measured frequency. The right response to that uncertainty is not to retreat to CVSS because it feels more objective. It is to model the uncertainty explicitly. This is what FAIR-aligned Monte Carlo methods are for: instead of asserting a single loss figure, you express each input as a range, run the simulation many thousands of times, and read the output as a distribution, a P10 low case, a base case, and a P90 high case. The honest answer to 'what does this finding expose' is a band, and a band is what a CFO or an investment committee can actually reason about.
That reframing also fixes a quieter problem with CVSS-driven programs, which is that they optimize for severity throughput rather than risk reduction. A team can close a hundred high-severity findings on low-value assets and move the company's actual exposure by almost nothing, while the one medium-severity finding sitting on the revenue path stays open because it never bubbled to the top of a severity-sorted queue. Boards and operating partners do not care how many criticals you closed. They care how much loss exposure you removed and what it cost to remove it. Those are different scoreboards, and only one of them maps to enterprise value.
The metric that connects remediation work to enterprise value is EBITDA recovered per dollar of remediation. For each finding, estimate the reduction in expected loss if you fix it, which is roughly the loss exposure it carries multiplied by the probability of the event it enables. Then estimate the cost to remediate it in engineering hours, change risk, and any tooling. Divide the first by the second. Now you have a ratio that ranks every item in the backlog on the same axis the business uses to allocate any other capital: return per dollar spent. The 9.8 on the staging box might recover almost nothing per dollar because the protected asset is worth almost nothing. The 6.1 on checkout might recover a large multiple because a modest fix protects a large, exposed loss.
Ranking by this ratio reorders the backlog in ways that are uncomfortable at first and obviously correct on reflection. Cheap fixes on high-value, exposed assets rise to the top, even at moderate severity, because they buy down a lot of exposure for very little. Expensive fixes on low-value assets fall, even at critical severity, because the loss avoided does not justify the spend, at least not this quarter. Some genuinely critical findings stay near the top because they are both severe and sit on something that matters; the method does not fight CVSS so much as give it the missing second dimension. The output is not 'ignore severity.' It is 'severity times exposure, priced.'
A worked intuition helps. Take that medium-severity access-control flaw on checkout. Suppose the loss it exposes, modeled across thousands of simulation runs, comes back as a base case in the low millions with a long right tail, and the fix is a few days of one team's time. The recovered-exposure per dollar is enormous. Now take the critical RCE on the isolated staging box. The loss it exposes, given there is no real data and no path to anything valuable, is small, and the fix may require rebuilding the environment. The ratio is poor. A severity-sorted list and an exposure-sorted list disagree completely on these two, and the exposure-sorted list is the one you can defend to a CFO who asks why you spent the sprint the way you did.
It is worth being explicit about what this is not. It is not an actuarial guarantee, and no honest version of it will hand you a single number and call it your risk. Every figure it produces is a decision-support estimate, carrying its method, its confidence, and its source so a skeptical reader can see exactly which assumptions move it. It is not investment or legal advice. It does not replace CVSS, EPSS, or your scanners' own severity logic; those remain the raw inputs. And it does not relieve you of the judgment calls about asset value and breach cost. What it does is make those judgment calls visible and consistent across the whole backlog instead of buried inside whichever engineer happened to triage the ticket.
Mechanically, none of this requires ripping out the tooling you already run. Valty reads the artifacts your pipeline already produces, SARIF from your SAST and code scanning, exports from your DAST, SCA, cloud posture, and identity tools, and treats them as the finding feed. It does not run scans, sit in your CI as a gate, or try to be your SAST; your existing tools keep doing that, and they do it better than a risk layer ever could. The job here begins after the finding exists: attach it to the asset, attach the asset to the dollars, model the loss as a distribution, and compute the recovered-exposure-per-dollar ranking on top. Read-from, not replace-with, is the deliberate design, because the buyer already owns the detection layer and does not want another scanner.
The asset-and-value mapping is where the work is real, and it is worth saying plainly that the model is only as good as that mapping. If you tell the system every repository is equally critical, you will get a ranking no better than CVSS, because you have thrown away the one variable that made it better. The payoff comes from doing the unglamorous part once: tag your services with the revenue they carry, the data classes they hold, and the obligations they sit under, then keep that current as the architecture changes. That tagging is reusable far beyond vulnerability ranking; it is the same business-context graph that makes incident prioritization, audit scoping, and board reporting coherent. Findings ranking is just the first thing that gets sharper once the context exists.
For the AppSec leader, the practical shift is to stop shipping the board a count of open criticals and start shipping a ranked plan that says: here are the findings that carry the most exposed loss, here is the dollar band each one represents with its confidence, here is what each fix costs, and here is the order that recovers the most EBITDA per dollar of engineering time. That is a defensible artifact in a budget conversation, because it speaks the language of capital allocation rather than the language of severity. And it changes the question your CFO asks from 'why do you have so many criticals' to 'are we funding the fixes that buy down the most exposure,' which is a far better question for a security program to be answering.
Severity scoring earned its place and keeps it; the argument here is not against CVSS but against stopping at it. CVSS ranks vulnerabilities. Businesses have to rank decisions, and a decision is a vulnerability joined to an asset joined to the money that asset protects, all of it carried through a model that is honest about its own uncertainty. Do that join, price it as a distribution, and sort by EBITDA recovered per dollar, and the backlog stops being a wall of red severity badges and becomes a prioritized investment plan. The 9.8 on the asset no one cares about waits. The 6 on the path that pays the bills goes first. That ordering is not a downgrade of security rigor. It is what rigor looks like once you let the business into the math.