Security-Vulnerability Rework Cost: CVE Remediation Math

Updated July 2026. Sources: IBM Cost of a Data Breach 2025; Snyk State of Open Source Security 2024; Veracode State of Software Security 2024.

The per-CVE labour cost

A useful working number for a representative US team: at a $200,000 fully-loaded engineer cost ($96 per hour), 25 hours of labour per critical CVE works out to $2,400 per CVE, before counting cross-team coordination, security-team review, deploy labour, and any post-incident communication. The full delivered cost of a critical-CVE remediation runs $5,000 to $12,000 in labour alone for most teams.

Multiply by the number of critical CVEs a typical mid-sized organisation handles per year (Snyk and Veracode data place this at 15 to 40 critical CVEs per 100 engineers per year for organisations with mature dependency-scanning, and 60 to 120 per 100 engineers for organisations without it). The result is typically $75K to $1.4M per 100 engineers per year purely in critical-CVE remediation labour, which is before counting the high-severity and medium-severity tiers.

The IBM breach-cost arithmetic

When a vulnerability is exploited rather than caught, the cost arithmetic changes shape. The IBM Cost of a Data Breach 2025 report (the canonical industry reference, published annually since 2005, and marking two decades of the study) places the global average breach cost at $4.44M (down 9% year on year, the first fall in five years), the US average at a record $10.22M, and the average cost per compromised PII record at $160. The figures cover four major cost categories: detection and escalation, notification, post-breach response, and lost business.

The engineering team's rework cost (the time to fix the underlying vulnerability and clean up affected systems) is typically 5 to 15% of the total breach cost. The remainder is dominated by notification, legal, and lost-business costs, which fall on functions outside engineering. This is a useful framing when arguing for security investment: even if engineering only carries 5 to 15% of the visible breach cost, the engineering remediation is the gate that determines whether the rest of the cost is incurred.

IBM's 2025 report also confirms a finding that has been stable across several editions, even as the lifecycle shortens: the average time to identify a breach is 181 days, and the average time to contain it is 60 days, for a 241-day total breach lifecycle (a nine-year low). Breaches with a lifecycle over 200 days average $5.01M versus $3.87M for those resolved faster, roughly a $1.14M premium. Organisations using security AI and automation extensively cut the lifecycle by about 80 days and saved close to $1.9M on average. The detection-speed differential is the single largest controllable cost factor in the report, and it maps directly to investment in observability, SIEM tooling, and threat hunting capacity. The incident cost calculator sister site covers the broader detection-speed economics.

Why security rework is uniquely expensive

Security defects sit on the steepest part of the Boehm cost-of-change curve, for three reasons that compound each other.

First, security fixes often require coordination across multiple services that share the vulnerable dependency or pattern. A Log4Shell-class vulnerability in a widely-used library may need patching across dozens of services with different deployment cadences, different ownership, and different acceptance test discipline. The coordination cost dominates the per-service fix cost on these events.

Second, the fix must be tested under the assumption that an attacker may already know about the vulnerability. This raises the confidence bar for the deploy: a normal feature deploy might tolerate a 1 in 1000 chance of regression; a security fix in a high-traffic path needs higher confidence than that because the cost of regression is higher than the cost of waiting another hour. The verification work is therefore disproportionately heavy relative to the code change.

Third, regulated industries layer audit, disclosure, and breach-notification requirements on top of the technical fix. PCI-DSS, HIPAA, SOC 2, and FedRAMP each have their own remediation SLAs and documentation requirements. The compliance work around a regulated-industry CVE often equals or exceeds the technical work. The regulatory-compliance rework page covers this in more detail.

The shift-left security investment

Snyk's State of Open Source Security 2024 and the Veracode State of Software Security 2024 both report consistent findings: teams with pre-merge SAST (static analysis) and dependency scanning fix vulnerabilities at roughly 4 to 8 times lower per-CVE cost than teams that find vulnerabilities post-merge or in production.

The investment shape for a representative organisation is: $50K to $200K per year in tooling (Snyk, Dependabot, Semgrep, Sonatype, or comparable), plus 1 to 2% of engineering capacity in triage. The avoided rework typically lands at 5 to 15% of total engineering capacity for organisations starting from a low-maturity baseline. The investment usually pays back in 6 to 18 months on first deployment.

One important caveat: shift-left security tooling generates noise. Most teams find that 30 to 50% of initial findings are false positives or non-exploitable in their context. The triage discipline (a clear process for accepting, deferring, or fixing each finding within a defined window) is the difference between shift-left tooling that pays back and shift-left tooling that becomes alert fatigue. The poor-testing root-cause page covers the broader appraisal-discipline question; the security-specific application is the same principle.

Sources

• IBM and Ponemon Institute. Cost of a Data Breach Report 2025 (20th-anniversary edition, published August 2025). ibm.com/reports/data-breach.
• Snyk. State of Open Source Security 2024.
• Veracode. State of Software Security 2024.
• OWASP. OWASP Top 10 2021 and ongoing methodology documents.
• PCI-DSS, HIPAA Security Rule, SOC 2 and FedRAMP remediation requirements.

Frequently asked questions