There’s a conversation that happens in nearly every engineering team with some security maturity. The security team presents results from the latest scan cycle: 47 critical findings, 183 highs, 291 mediums. The engineering team asks what to fix first. A discussion begins about CVSS scores, about which dependencies are most critical, about what has a known public exploit. Forty minutes later there’s a rough consensus. Nobody is entirely sure it’s the right one.
The problem isn’t lack of information — it’s that the information is in the wrong format. Engineers reason in terms of technical debt and opportunity cost. Managers reason in terms of deadlines and resources. Executives reason in terms of money. CVSS is a pure security language. It doesn’t translate into any of those other languages.
The structural problem with CVSS
CVSS (Common Vulnerability Scoring System) is a useful tool for what it does: assign a technical severity score to a vulnerability on a 0–10 scale, based on characteristics like attack vector, exploitation complexity, privileges required, and potential impact. It’s an industry standard. Most vulnerability databases use it. Many scanning tools report it as their primary metric.
The problem is that CVSS measures the vulnerability in the abstract — not in the context of your specific codebase. A CVSS 9.8 CVE in a logging dependency only used in an internal debugging service has a completely different risk profile than the same CVE in an authentication dependency processing user sessions in production. CVSS treats them identically.
There’s a less obvious problem too: CVSS doesn’t speak in money. And security prioritization decisions are, ultimately, resource allocation decisions. Deciding what gets fixed in the next sprint is deciding what doesn’t. Without a cost estimate, that decision is made on intuition — and intuition in security has a known bias toward what seems severe rather than what actually is.
How the financial impact model works
Gerion’s Financial Impact Engine calculates the estimated remediation cost of each finding from three variables that reflect the real context of that finding in your codebase.
Finding type and base cost
Each vulnerability category has a base cost range derived from industry benchmarks — primarily the IBM Cost of a Data Breach Report, the Verizon DBIR, and real incident remediation cost data. That range reflects the cost of complete remediation: engineering time, deployment coordination, credential rotation when applicable, and forensic review when there’s an exposure window.
An exposed credential in production has a high base cost because remediation means identifying every service that uses it, coordinating a live-environment rotation without causing downtime, reviewing access logs to understand what happened during the exposure window, and potentially notifying customers if personal data was accessed. A CVE in a production dependency has a moderate base cost because it requires a dependency update, regression testing, and coordinated deployment — more complex than a normal update but without the forensic component. An IaC misconfiguration in a feature branch has a low base cost because it can be fixed in the normal development cycle before it ever reaches production.
The production branch multiplier
The most important variable in the model is which branch the finding lives on. A finding on main, master, release/*, or hotfix/* receives a 10× cost multiplier. The same finding on any other branch gets a 1× multiplier.
The logic behind the multiplier is concrete. A finding on a feature branch doesn’t exist in production yet — it can be fixed in the normal development cycle, with whatever time is needed, without coordination pressures. A finding on main is in the production environment right now. Remediating it requires an urgent patch, a maintenance window, possibly a declared incident. The cost of that operational difference is historically around an order of magnitude.
# Example with the same CVE in two contexts
CVE-2022-23529 in jsonwebtoken@8.5.1 branch: feature/new-auth-flow base cost: $1,600 × multiplier 1× = $1,600
CVE-2022-23529 in jsonwebtoken@8.5.1 branch: main base cost: $1,600 × multiplier 10× = $16,000That CVE is exactly the same in both cases. The cost difference reflects the context difference — how much it will actually cost to resolve it in the situation it’s in right now.
Severity as a secondary factor
Within each finding category, CVSS score remains relevant — not as the primary metric, but as an adjustment factor within the base cost range. A CVE scoring 9.8 with a known public exploit falls at the high end of its category’s range. A CVE scoring 6.5 with no public exploit falls at the low end. Severity still matters; it just isn’t the variable that determines whether a finding is urgent — that’s decided by the combination of type and branch context.
How it changes work prioritization
The most immediate change the financial cost model produces in teams isn’t technical — it’s in the quality of prioritization conversations.
With pure CVSS, the priority list is dominated by highest-scoring findings regardless of context. The team spends time evaluating critical CVEs in internal developer tooling dependencies — findings that will never reach production and whose remediation has minimal real security impact. Meanwhile, a medium-score CVE in the production authentication dependency appears on page two of the list.
With the financial cost model, the top of the list contains the findings with the highest estimated cost: those in production branches, in active repositories, in components with the highest impact if exploited. The prioritization discussion becomes more concrete — “this finding represents $20,000 of production exposure, that one represents $900 in a feature branch” — and easier to communicate outside the technical team.
A team of four engineers with capacity for a two-week security sprint isn’t going to fix 230 findings. They’ll fix the 15–20 that represent the highest accumulated cost. The Financial Impact Engine makes that selection objective, reproducible, and auditable.
What the executive dashboard shows
The Financial Impact Engine directly powers the metrics in Gerion’s executive dashboard, designed to communicate security status to non-technical audiences without losing precision.
Security Debt — the sum of estimated costs for all open findings across all connected repositories. Not a finding count — a figure in dollars. The number that answers the question an executive asks: “how much are we exposed to right now in financial terms?” Counterintuitively, a concrete debt number — even an estimate — is more actionable than “we have 47 criticals.” It allows period comparisons, trend measurement, and investment justification.
Savings Realized / Fix Rate — the sum of estimated costs for findings closed in the selected period (week, sprint, quarter). It’s the progress metric that transforms “we closed 23 findings this sprint” into “we reduced security debt by $74,000 this sprint.” The difference between the two formulations isn’t cosmetic — one allows sprint comparisons, justifies work pace to the board, and demonstrates ROI on security investments.
Security Health Grade — a composite score combining the current debt level, the rate of finding closure (Fix Rate), and the distribution of findings by criticality and branch. It’s the single-figure metric useful for quick comparisons across repositories or across periods — not as a substitute for detailed analysis, but as a first-level indicator of where to look next.
Security debt as a business metric
The analogy between security and technical debt is more precise than it might seem. Technical debt is accumulated work that will eventually need to be done — the more it piles up, the more expensive it becomes because surrounding code continues evolving and makes remediation harder. Security debt works the same way, with an additional variable: the cost can materialize abruptly through an incident, rather than gradually through reduced development velocity.
Measuring security debt in financial terms — instead of finding counts or CVSS scores — allows it to be integrated into the engineering planning conversations where technical debt is already being discussed. It’s not a separate dashboard for the security team. It’s a platform health metric that any engineering manager can read in the same context as code quality metrics, test coverage, or deployment velocity.
That integration is the goal: security not as a conversation that happens in parallel to engineering, but as part of the same language teams use to reason about the state of their systems.