In conversations with security, platform, and cloud leadership, a pattern repeats: someone opens the dashboard and the diagnosis is immediate. The volume of CVEs is high enough to become a bottleneck, consume engineering cycles, and pressure compliance deadlines. "I am responsible for this number." "I have compliance to meet." "I need to prove the ROI."

The paradox is that, even when everyone agrees on the magnitude of the problem, it does not always become a proportional priority. In technology, almost everything competes for agenda and budget. And since the cost of vulnerability management is spread across teams and remediation routines, it rarely becomes a single, defensible number.

Without this baseline, remediation becomes a recurring urgency, but rarely a structural decision.

Starting from this scenario, this post covers three points:

• Show why this cost is "invisible," but real and recurring;

• Explain why supply chain risk needs to be included in ROI calculations;

• Present how the Quor calculator materializes cost and risk without becoming a "black box."

Why this cost is invisible and so difficult to justify

This cost does not reside in a single place. It crosses teams, tools, and delivery cycles.

When someone asks "how much does vulnerability management (CVEs) cost?", the answer almost never comes ready. Not because the cost does not exist, but because it is distributed.

It appears in small blocks throughout the cycle. Over time, it becomes routine and, therefore, does not gain traction when it comes to budget.

In practice, the account appears as concrete losses:

• Diverted engineering hours: screening, investigation, correction, rebuild, testing, and validation.

• Planning breaks: peaks of urgency, war rooms, emergency changes, task forces, and off-hours work to meet deadlines.

• Manual governance for compliance: evidence, spreadsheets, audits, and justifications that do not scale.

• Displaced strategic capacity: platform, SRE/DevOps, and security move from strategic initiatives to support remediation and governance of change.

Without a measurement model, the debate remains asymmetric: prevention becomes an explicit cost, while the reactive effort remains embedded in the operation, eroding predictability and increasing operational risk.

Why supply chain risk needs to be included in ROI calculations

If the ROI conversation stays only on "hours saved in vulnerability remediation," it only measures the direct remediation cost. What often gets left out is exposure: the period during which the organization continues to operate with known vulnerabilities while trying to reduce the vulnerability backlog (CVEs).

The supply chain comes into play here for two reasons. First, because third parties are already a material factor in the incident landscape. The Verizon DBIR 2025 reports third-party involvement in 30% of the incidents/breaches analyzed.

Second, in the supply chain, especially in open-source dependencies, the time to have a fix available and usable does not depend solely on your team. It depends on the ecosystem (maintainers, releases, and update distribution).

This rhythm does not always match the urgency of operations. In dependencies, Sonatype reports historically average times in the range of 200 - 250 days to remediate critical vulnerabilities and cites cases in 2024 exceeding 500 days.

In terms of decision-making, this changes what ROI needs to capture. A consistent ROI in prevention needs to reflect two vectors:

• Recovered capacity: less rework and fewer interruptions to reduce the backlog.

• Reduced exposure: less dependence on long correction windows in the ecosystem and lower risk arising from the chain.

How the calculator materializes cost and risk without becoming a black box

To enable this conversation without relying on narratives, the Quor calculator was designed to produce a consistent and comparable baseline with simple operational inputs and explicit assumptions.

To prevent it from becoming "a project to measure the project," it follows three criteria:

• Use inputs that the operation responds to quickly, without disproportionate effort required for data gathering;

• Separate direct cost from exposure, avoiding distortion in the ROI discussion;

• Maintain explicit and parameterizable assumptions, adjustable to context (volume, cost-per-hour, industry criticality, and third-party dependence).

With this, the calculator presents the ROI discussion in two blocks, exactly as they appear in the interface: Remediation and Risk.

First, it makes visible the operational cost absorbed by the operation to correct critical/high CVEs.

Then, it translates the exposure associated with the software supply chain into a financial order of magnitude.

1) Remediation: direct cost absorbed in manual corrections (engineering)

In this tab, the logic is simple and auditable, to give visibility to the cost that the operation already absorbs daily:

• Total of critical/high CVEs
  = number of images in production × average CVEs per image

• Total hours for remediation
  = total CVEs × hours per CVE

• Total cost for remediation
  = total hours × cost-per-hour

The calculator also shows useful derived metrics for internal discussions, such as average cost per CVE and average cost per image, which help pinpoint where the weight of the problem lies.

Figure 1 - Remediation Tab: CVEs → hours → cost.

Based on hours per CVE and cost per hour, the calculator estimates the direct cost absorbed by the operation to manually remediate critical/high vulnerabilities in production, a baseline that tends to be distributed among teams.

Note: “hours per CVE” does not just involve applying a patch. In real operation, a large part of the effort is around the correction: screening, rebuild, testing, validation, rollout, and, mainly, change management (windows, approvals, rollback plans, and evidence).

2) Risk: translating exposure into a financial order of magnitude

In the Risks tab, the calculator follows a classic risk management logic: annual expected loss (ALE – Annualized Loss Expectancy). We use this model as a base and keep the assumptions explicit and parameterizable.

The adaptation here is to adjust the model to better reflect the reality of software operations: adjust the impact to business sector (criticality/regulation) and isolate the portion attributable to the software supply chain, so that the number represents the exposure associated with software supply chain, rather than a "generic risk."

Figure 2 - Estimated Risk (adjusted ALE): benchmark (impact) × sector × probability × supply chain portion

With the operational cost visible and the exposure translated into an order of magnitude, the decision no longer solely depends on perception.

The next step is to apply these two dimensions to the baseline scenario and show how the calculation behaves under conservative assumptions.

<CTA_CALCULATOR>

Scenario (financial sector): remediation baseline and impact on the first redeploy

This scenario was extracted from a proof of concept in a real environment.

The goal is to materialize the remediation baseline with simple operational inputs and connect this baseline to the observed effect of the first redeploy with equivalent container images from Quor.

Assumptions (operational inputs)

• 1,000 critical and high CVEs in production

• 4 h per CVE (operational average including screening, rebuild, testing, validation, and change management)

• R$ 150/h (average cost-per-hour)

Operational remediation baseline (reactive model)

• Total hours: 1,000 × 4 h = 4,000 h

• Direct cost: 4,000 h × R$ 150/h = R$ 600,000

Operational reading: 4,000 hours equate to approximately 25 FTE-months (assuming 160 h/month). This cost rarely appears as a budget; it appears as capacity diverted from backlog, roadmap, and structural improvements to support remediation.

Financial reading for decision-making

In the analyzed scenario, after replacing the images with Quor equivalents and executing the first redeploy, we observed a 93% reduction in critical and high CVEs already in the initial cycle.

Financial summary of the scenario:

• Assumptions: 1,000 CVEs | 4 h/CVE | R$ 150/h

• Operational baseline: R$ 600,000

• Reduction (1st redeploy): 93%

• Estimated avoided cost: R$ 558,000

• Expected annual loss associated with supply chain (adjusted ALE): R$ 3,895,265

• Business Value (order of magnitude): R$ 4,453,265

ROI reading: in this scenario, for every R$ 1 invested in prevention, ~R$ 7 are avoided in manual corrections (order of magnitude based on this baseline and the observed effect).

<NOTA_DE_RIGOR>

Conclusion: measuring does not solve the problem, but raises the quality of the decision

Measurement does not eliminate CVEs. What it eliminates is ambiguity. As long as CVE Management is treated as a diffuse issue, the organization continues to pay with rework and interruptions without managing to justify a structural investment.

When you put the cost on paper, you can discuss prevention based on what the operation actually experiences: hours, change management, validation, evidence, and prioritization.

This elevates the quality of the decision because it removes the debate from the realm of perception and places it in a logic of trade-offs: what continues to be absorbed by the reactive mode and what can be returned to the strategic agenda.

The calculator exists to facilitate this conversation quickly: transforming a diffuse problem into numbers that can be reviewed, compared, and defended internally, without relying on narratives or "sense of risk."

In the end, the rationale is this: account for the cost of keeping the current cycle running. And clarify the capacity that returns to the operation when this operational tax decreases.

References

• IBM. Cost of a Data Breach Report 2024. 2024.

• Verizon. 2025 Data Breach Investigations Report (DBIR). 2025.

• SecurityScorecard. Global Third-Party Risk Report (press release). 2024.

• Venminder. State of Third-Party Risk Management Survey (2025) highlights. 2025.