Financial Impact Engine: Security in Numbers the Business Understands

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 with a deliberately simple formula, based on three variables: the analysis type, the severity, and the branch the finding lives on.

Hours times rate: the development cost

For each combination of analysis type (SAST and IaC, SCA, secrets) and severity, the model defines an average number of remediation hours and an hourly rate. Their product is the development cost; multiplied by the branch factor, it becomes the production cost:

dev_cost  = average_hours × hourly_rate
prod_cost = dev_cost × multiplier      (default: 10)

These are the default values:

Type	Severity	Hours × rate	Dev cost	Prod cost (×10)
SAST / IaC	CRITICAL	1 h × €80	€80	€800
SAST / IaC	HIGH	1 h × €60	€60	€600
SAST / IaC	MEDIUM / LOW	1 h × €40	€40	€400
SCA	CRITICAL	2 h × €80	€160	€1,600
SCA	HIGH	1.5 h × €60	€90	€900
SCA	MEDIUM / LOW	1 h × €40	€40	€400
Secrets	CRITICAL	0.5 h × €80	€40	€400
Secrets	HIGH	0.5 h × €60	€30	€300
Secrets	MEDIUM / LOW	0.5 h × €40	€20	€200

Hours, rates, and the multiplier are configurable per organization: the defaults are a starting point, and the sensible move is to tune them to what fixing things actually costs your team. With this configuration, the maximum per finding is €1,600 (a critical SCA finding in production).

The logic behind the table is engineering hours. An SCA finding takes longer than a SAST one because it requires updating the dependency, running regression tests, and deploying in a coordinated way. A secret, on the other hand, is estimated at half an hour: the time it takes to rotate it. It’s worth being clear about the scope: the model estimates engineering hours, not the cost of an incident. It doesn’t include forensic review, notifications, or reputational damage.

The production branch multiplier

The most important variable in the model is which branch the finding lives on. On main, master, or any branch whose name starts with release, the production cost is calculated with a 10× multiplier (the default value). An active finding on one of those branches counts as debt at its full production cost.

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. Gerion models that operational difference with the multiplier, which is an estimate, not a measurement.

If the finding is on any other branch, only its development cost counts as debt, and its production cost is recorded separately as pipeline risk: what it would cost if it reached production unfixed.

# The same CRITICAL SCA finding (2 h × €80 = €160 development cost)

jsonwebtoken@8.5.1
  branch: feature/new-auth-flow
  debt: €160
  pipeline risk: €160 × 10 = €1,600

jsonwebtoken@8.5.1
  branch: main
  debt: €160 × 10 = €1,600

The finding is exactly the same in both cases. The difference reflects the context: how much it will actually cost to resolve it in the situation it’s in right now.

Mitigated: the production cost avoided

When a finding stops appearing in a later scan, Gerion considers it mitigated. Its production cost moves from debt to realized savings: the production cost avoided. That’s the number that turns “we closed findings” into euros.

Severity: which row of the table applies

The model doesn’t apply the CVSS score as an adjustment factor. The finding’s severity (CRITICAL, HIGH, MEDIUM, or LOW) selects the row of the table, and the hours and rate come from there. Severity still matters; it just isn’t the variable that decides whether a finding is urgent — that’s decided by the combination of type, severity, and branch.

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 and those with the highest severity. The prioritization discussion becomes more concrete — “this critical SCA finding is €1,600 of debt on main, that other one is €160 on 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 and reproducible.

What the dashboards show

The Financial Impact Engine directly powers the metrics in Gerion’s Executive and Governance dashboards, designed to communicate security status to non-technical audiences without losing precision.

Security Debt — the sum of the debt of all active findings (their production cost or their development cost depending on the branch, as seen above) across all connected repositories. Not a finding count — a figure in euros. 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 tracking and investment justification.

Savings Realized — the realized savings accumulated over the year: the sum of the production cost avoided on mitigated findings. It’s the progress metric that transforms “we closed 6 critical SCA findings” into “we avoided €9,600 in production cost” (6 × €1,600). The difference between the two formulations isn’t cosmetic — one lets you justify to the board the pace of work and the effort invested in security.

Security Grade — an A to F grade per repository, in the Governance dashboard. It’s the single-letter metric useful for quick comparisons across repositories — 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.